We found an ARP incongruence when MT run a lot of DHCP+hotspot requests.
Randomly some clients can’t see hotspot login page.
We have some clients in hotspot wallen garden ip (bypass with only mac address in rules).
After some weeks of debug here the results:
when clients can’t see login page
these clients have correct ip, subnetmask, gateway,.. from dhcp
these clients can’t ping or view any network hosts
these clients are in ARP table with correct bind (MAC address - IP address)
BUT:
same ip addresses appears in hotspot > host but with binding of wallen garden clients MAC
To correct this bug (?) we do a script that loop though APR table and remove incorrect MAC from hostpost host table.
Do you have any wireless bridges / extenders in your network?
If so, and if they’re not using WDS, then they’re doing a kind of “nat” on the MAC addresses, which is probably what you’re seeing.
Even though it looks very similar, wifi is NOT ethernet, and NOT actually bridgeable in its native form. WDS creates a sub-connection which bridges the real MAC addresses across the WiFi network.
If your AP is a Mikrotik and you have WDS enabled and configured to be dynamic, using the hotspot bridge, then every AP which connects to it to do bridging should result in a wdsX interface being created dynamically on your bridge.
Another clue is that several of your entries will have the same MAC address. If so, then that same MAC address is probably a wireless bridge.
Yes. It’s wireless network with so many APs in WDS with bridge mode. But these APs don’t do L2 nat but station/CPE at customer end does L2 nat. And there are multiple entries with same mac as there are multiple customers to single CPE which is in bridge mode with L2 nat. There is no fix time as to when the hotspot will hang. Also don’t know why it’s hanging.
Had script running in early morning to disable and enable hotspot but this method disconnects all users and they have to re-login. This cannot be permanent solution.
Observed one thing. When hotspot hangs, can’t get new entries in hosts. If the entry already exists in hosts, then users can login and surf. Ultimate solution we try is disable hotspot and enable it again. It flushes all entries in hosts and active users.
incongruenceHealt
:local hosts [/ip hotspot ip-binding find bypassed]
:foreach h1 in=$hosts do={
:local mac [/ip hotspot ip-binding get $h1 mac-address]
:local comment [/ip hotspot ip-binding get $h1 comment]
:log info (" MAC: ".$mac." - ".$comment)
:local dhcps [/ip dhcp-server lease find mac-address=$mac]
:foreach m1 in=$dhcps do={
:local server [/ip dhcp-server lease get $m1 server]
:log info (" server: ".$server)
:if ($server = "wifi") do {
:log info ("MAKE STATIC: ".$mac)
/ip dhcp-server lease comment $m1 comment=$comment
/ip dhcp-server lease make-static $m1
}
}
}
But IMHO this isn’t a good solution. It’s like a reboot or a disable/enable operation.
I’m using Unifi Ubiquiti: about 40 APs with 500-800 users connected. I have the same scenario in 4 campus. I cannot disable and re-enable hotspot because every time users must reauthenticate.
I have made some detailed tests. Two clear and repetables points:
Problem appears only with mikrotik and unifi (in my scenario)
The problem seems users that have a bypass on hotspot. Sometimes dhcp server lease an ip address to these and try to set the same address to an hotspot host. Without bypass hosts there are no problems.