Hotspot MAC exception not working for XBox/PS4/Sonos

Morning!

We provide Internet services for residential highrise buildings. We exclusively use RouterOS’s Hotspot feature with a RADIUS backend to facilitate authentication and access control. With the growing number of devices that don’t have a browser for users to login we’re desperate for a method to support these devices. The natural solution is to implement MAC exceptions. Users can list the MAC addresses of their devices in our customer portal and those devices then are automatically logged in.

The question is, how to effectively implement MAC exceptions in the router. It seems obvious, however:

The most-recommended solution is to use ip-binding’s bypass feature. This works, however has two caveats:

  • rate-limits are not applied to bypass bindings - a manual IP mapping and queue would also need to be created for every device
  • MAC addresses have to be manually added to the router, rather than existing on the RADIUS server

The alternate option is to use a server-profile with login-by=mac enabled. This however only works if the device makes a HTTP request initially before making requests on other ports. A device like a Sonosdoesn’t do this. It only makes requests on non-HTTP ports, therefore never authenticates and never works.

So, what’s the solution? Do I need to be using the router’s API and manually injecting bypass-bindings+queues for every device? Surely there’s a simpler solution.

Hey @Normis,

In summary, Hotspot login-by=mac doesn’t work with XBoxes, PlayStations, Sonos, AppleTV or SmartTVs. We’d really love a fix for this - we’re finding 50% of our customers have these types of devices and it’s causing some real grief.

We also have this problem

  • 1

Depending upon number of hotspots required, I might consider some special development using openwrt/LEDE. Which might even run on certain mikrotiks.
Which MTs are you using ?

We have around 30 sites currently and looking to put on another 20 sites each year. We’re using CCR1009 for the smallest sites, larger CCRs for the larger sites. The latest RouterOS of course. We’d really love a solution based solely on the Mikrotiks, as they’re so near to perfect for the task, except for this bug.

CCR-support on openwrt/LEDE looks unreliable to me, far from production stability. However, you hit an interesting feature. Having developed a lot of different firmware for special purpose hotspots/routers (incl. parental control, social login, access logging, local content distribution etc.) on various hardware, your usage case gave me some new inspiration :slight_smile:

I’m glad to be of help! Headless devices aren’t going away. I can only see them getting more common with IoT.

I only wish Mikrotik would fix that feature.