Hi all,
I have come accross strange error of some Lenovo product providing to the device partly random mac address (in details desribed here: https://forums.lenovo.com/t5/Lenovo-Sma ... 850?page=1 ) that makes impossible to provide static IP address to device through DHCP.
The mac address is being randomized partly which means that mac address of device looks like this: AB:CD:EF:GH:IJ:KL where AB:CD:EF is always "00:08:22" and KL is always "FB". For example: 00:08:22:24:7F:FB.

Since I noticed this device is playing such a tricks I have merged couple fo those mac address with static ip addresses as in screenshot. Can someooen help me conquer this f*** device?
I can not limit pool to 1 addresses since there are many devices using DHCP on a daily basis.
Nor I can make fixed IP address in the device itself since it is google assistant device where you cannot change any network details.

Any help appeciated!

Hi, if you don't have any other Lenovo device in your home network you could try MAC address NAT. For example you can provide "Src. MAC Address" 00:08:22:00:00:00 with "Src. MAC mask" FF:FF:FF:00:00:00 and map it to any of the MAC addresses you have static lease set up (Action tab, choose src-nat option). This feature is in Bridge/NAT.

"Wildcarding" only 4th and 5th octet while preserving first 3 and the last one would require DHCP lease-script.

I am not aware if other solution for your case exists on MikroTik platform.

Maybe you can use vendor class matcher? see https://wiki.mikrotik.com/wiki/Manual:I ... or_Classes
Or you can deal with this device in an direct way: create it's own virtual AP that serves just a single IP address.

thanks @che and @r00t I will try both options.

This is a 'similar' problem with changing MAC addresses. Maybe the MAC/"mask" principle can be used somewhere for DHCP as well for this Lenovo case.

viewtopic.php?f=2&t=168682

The vendor class matcher that allows you to use specific 1-address addresslist for specific device class is probably most elegant solution that doesn't require mangling of all traffic.
It will work as long as you have just one device with unique vendor class name on the network. Usually this is phone model number or device name, so for home use it's fine.

Only thing I really don't like is you can't see the vendor class in lease details. WHY? Why I have to enable debug log for DHCP just to be able to see it? It should be visible along the other client values...

iPhones are doing the same thing with a recent update. At least on the iPhone you can turn it off for a specific WiFi connection. If the Lenova has the same option, you could set up a rate limit so that if someone is not using one of your DHCP reservation IP addresses, they get limited to slow speed (like dial up speed). When they come to you to complain, tell them to defect the random MAC setting on your network, and their problem will go away.

This is a 'similar' problem with changing MAC addresses. Maybe the MAC/"mask" principle can be used somewhere for DHCP as well for this Lenovo case.

viewtopic.php?f=2&t=168682

No, because in that case there is no fixed part of the changing MAC address (except the two lower bits of the high byte being 10 all the time).
The remainder of the MAC address is completely random so it cannot be matched in any way.

Fortunately, most of the vendors end up with a scheme where the MAC address is randomized but not changing after the first connection to a network.
"a network" is then usually identified as "the same SSID". in earlier attempts it was sometimes done by the MAC address of the AP or the BSSID, but of course that wreaks havoc with roaming on a network with multiple APs.

Now, that solution of course defeats the original purpose of this random MAC: to prevent that users can be tracked between APs.
But we often see that in computing: there is some problem, someone devises a solution, the solution turns out to have problems, is then modified to avoid those problems, but the final solution, despite not having many problems of its own, does not solve the problem it all started with. Yet we end up with that "solution" being permanent part of our systems.