Used to quite happily restrict kids time using MAC address of the iDevices
After upgrade to iOS14, it simply does not work, as the private address changes every 12 hours.
So different MAC, different IP from DHCP

Is there any other way to do restrictions?
Or deny obtaining IP if NOT REAL MAC is used? (none of the private addresses are real MAC as seen in MAC Address Lookup )
Which forces the user back to using Real MAC only (turn off Private bit)

Otherwise one could use (last resort) Hostname, but I cannot see how it could be used in Firewall Rule

sebus

Simply disable the option?
I have a iOS device that updated to 14.x some days ago and started using this random MAC-address.
Go into setting of the phone, to the Wireless settings and disable "Private Network" and done...

Easy if the iOS devices are under your own control.

Please read carefully, if one tries Time Restrictions then definitely not on a device that one controls physically...

So I used this and firewall rule that does use src-address-list= (where the list contains FDQN)

That should work... I hope

Even if it does, it is very much "poor's man" solution, because it relies on IP being obtained from DHCP (so DNS gets updated)
Change to static & the whole lot is no longer valid. At which point it is cat & mouse chase...

Apple again made life more difficult.

sebus

Please read carefully, if one tries Time Restrictions then definitely not on a device that one controls physically...

I read : Used to quite happily restrict kids time using MAC address of the iDevices

So ... you have nothing to say about idevices of your KIDS ? Strange world we live in then.
Perhaps my interpretation is wrong, and you mean something else with "restrict kids time"

We do live in strange world indeed...

We do live in strange world indeed...

The "kids control" feature on Mikrotik only uses MAC-addresses for identification (and then the IP is retrieved from the ARP-table using the MAC you provided).
There seems, as far as the Wiki is up-to-date, no way to use other criteria.
So yeah ... then you are out of luck with a Mikrotik product.

Alternative is create a separate Wireless SSID for kids and control the SSID. Simply disable it on certain times.
Depends on the wireless infra you have offcourse, but that may also be a route.

I don't have any iOS device to test it, but quick search suggests that these random MAC addresses should correctly set the local bit. If you include bridge in your config (you could use one as "wrapper" for wlan interface, if you don't already have some), then bridge filters have option for matching source MAC address with mask. I never used it myself, but it looks like it could be used to block all "fake" addresses.

I don't have any iOS device to test it, but quick search suggests that these random MAC addresses should correctly set the local bit. If you include bridge in your config (you could use one as "wrapper" for wlan interface, if you don't already have some), then bridge filters have option for matching source MAC address with mask. I never used it myself, but it looks like it could be used to block all "fake" addresses.

I've checked my logs here at home and this is a practical example. Matching will be tough like this...

Effective MAC >> 7C:01:91:3E:43:16
"Pseudo" MAC >> 46:CE:92:77:C1:6B

You can't pair them together, but:

https://en.wikipedia.org/wiki/File:MAC-48_Address.svg

7C:01:91:3E:43:16 - 7C = 01111100 => real
46:CE:92:77:C1:6B - 46 = 01000110 => random

I guess what @Sob had in mind with "local bit" is bit denoting locally administered address which is second-to-LSB in most significant octet of MAC address. If MAC address is represented as series of HEX digits (like xY:xx:xx:xx:xx:xx), then it's octet Y carrying this bit. If the bit is set, then digit Y will be any of the following: 2, 3, 6, 7, A, B, E, F

[edit] @Sob can post faster than me :-)

Sure, I could make yet another SSID (already have 5, but not using Mikrotik for that) and control that.

Pseudo MAC is really Random and unless there is something that can be build into RouterOS that does the check, I see no easy way that the fact could be used for "bridge filters matching source MAC address with mask"

edit:

So would we could go with mask(s) in /interface bridge filter
or just
Anyway, could not make the bridge filters with mask to show any traffic

add action=drop chain=forward in-bridge=bridge in-interface=ether2-master src-mac-address=06:00:00:00:00:00/FF:00:00:00:00:00

https://www.blackmanticore.com/fc5c95c7 ... 539852f8fb
Like private IP address ranges (defined in RFC 1918), there are also private MAC address ranges. These are called Locally Administered Address Ranges which are never used by devices or other vendors. MAC addresses in these ranges can be safely used, assuming they are unique within your network:

x2-xx-xx-xx-xx-xx
x6-xx-xx-xx-xx-xx
xA-xx-xx-xx-xx-xx
xE-xx-xx-xx-xx-xx

By the way : Android One and the latest Windows 10 are doing exactly the same now !!! https://wifinowglobal.com/news-and-blog ... i-feature/

Kids are supposed to be technical savvy, at least that is what we want to achieve with Coderdojo and other Technics Academy. They learn to re-mix code and share workarounds. Unless you lock the smartphone with some control software (as in a company) like "Parental Control" they will 'manage' their smartphone from 9 year-old onwards.

What we have here is disruptive for many businesses and portal managers. The users suffer as well (MAC cookie for the portal to avoid repeated logon).

My connection authentications have been set up using WPA2-EAP/Enterprise/802.11x/RADIUS. The user is identified on whatever MAC without reentering credentials. But it is very hard to find a software that links that authentication to a portal. (And Fortinet's RSSO is out of scope with a Mikrotik only network.)

I don't know where you have the bridge, if wlan interface is part of it (in that case in-interface=ether2-master would be wrong) or if it's separate device. When everything else is correct, src-mac-address=06:00:00:00:00:00/FF:00:00:00:00:00 would match 06-61-61-12-db-43, but if you want to have it universal, then src-mac-address=02:00:00:00:00:00/03:00:00:00:00:00 should do the trick (again, when everything else is right, port, bridge, ..).

WLAN is provided by hardwired Zyxel boxes, so in-interface=ether2-master is correct

But as you see in my post, I was trying on hardwired box with MAC 06-61-61-12-db-43 & no activity shows on bridge filters and device not being stopped

Try input chain, this is traffic coming to router to be routed.

One way to solve this problem is to use Static-only for the DHCP server. In this case, if users change their MAC address they will not be able to obtain an IP address. This will force them to disable the option in iOS settings. Also this will not work for all users, because some of them will set their IP manually just to try what will happen.

One way to solve this problem is to use Static-only for the DHCP server. In this case, if users change their MAC address they will not be able to obtain an IP address. This will force them to disable the option in iOS settings. Also this will not work for all users, because some of them will set their IP manually just to try what will happen.

You should use wireless access list instead and authenticate only users with known MAC-addresses.
Or even better: put all known MAC's to LAN vlan (that have internet access etc.), and all unknown MAC's to some kind of Guest vlan where they don't get any address or get a temporary one - to be able to add them quickly to access list if needed.

Come on, we talking kids mobile access control evening hours. Not going silly with creating a solution that is borderline on enterprise...

My solution in post #3 is working "fine"

What makes access list an "enterprise solution" and why being "enterprise solution" is a "bad thing" in the first place?

Bridge filter works for me:
It's a router where LAN is bridge and ether3 is one of its ports where the device is connected to.

Thanks, I can get data show in statistics, but still device can be accessed and access resources itself

Keep trying, it works reliably here, device doesn't even get IP address, because all packets are immediatelly dropped.

It only seems to indeed work when device boots, if device is already connected when filter is activated, it does not get stopped (count goes up, but that's it)

If count goes up and the action is drop, but it's not actually dropping packets, then it's not right. Almost like a bug, but I wouldn't be too quick saying that it's definitely that, maybe it's something else in config, but I don't know what.

I could not say either, but definitely what I see happening

Since the second-least-significant bit of the first octet indicates it is private, I started denying private mac address access to my WiFi networks in capsman with an access-list deny rule. I wish I could give them an error that tells them that private Wi-Fi addresses are not allowed.