I have a strange behavior with my hotspot login.
Some users (I think only windows) login with mac cookie before getting correct ip from dhcp server.
Hotspot config have none in pools (users and server profiles).
Arp hotpot interface is reply only. And arp is added from dhcp server.
1 simultaneous mac is allowed.
Here is the log
07:24:56 hotspot,info,debug d5mqzxf6 (169.254.143.229): trying to log in by mac-cookie
07:24:56 hotspot,info,debug d5mqzxf6 (169.254.143.229): login failed: simultaneous session limit reached
07:25:04 dhcp,info dhcp1 assigned 192.168.18.56 to XX:XX:XX:XX:XX:XX
07:25:16 hotspot,info,debug d5mqzxf6 (192.168.18.30): trying to log in by https
07:25:18 hotspot,info,debug d5mqzxf6 (192.168.18.30): login failed: simultaneous session limit reached
07:25:36 hotspot,info,debug d5mqzxf6 (192.168.18.30): trying to log in by https
07:25:38 hotspot,info,debug d5mqzxf6 (192.168.18.30): login failed: simultaneous session limit reached
07:25:55 hotspot,info,debug d5mqzxf6 (169.254.105.118): logged out: keepalive timeout
07:26:04 hotspot,info,debug d5mqzxf6 (192.168.18.30): trying to log in by https
07:26:05 hotspot,account,info,debug d5mqzxf6 (192.168.18.30): logged in
After idle timeout session with wrong ip is deleted and user can login.
Weird behavior..
I tried block 169.254.0.0/16 in hotspot ip binding but no success.
Not sure if it’s a new thing with windows users. didn’t remember to have already see that with my actual settings.
No there is plenty of free ip in the pool.
In the log I can see that it connect with wrong IP then it start dhcp dialog and just after it obtain the correct IP address.
I try to block 169.254.0.0/16 in the raw firewall. i’ll see next time.
sorry my capture log was not good.
this one is more clear :
08:31:51 hotspot,info,debug d5oy3ace (169.254.14.91): trying to log in by mac-cookie
08:31:51 hotspot,account,info,debug d5oy3ace (169.254.14.91): logged in
08:31:59 dhcp,info dhcp1 assigned 192.168.17.132 to XX:XX:XX:XX:XX:XX
08:33:51 hotspot,info,debug d5oy3ace (192.168.17.132): trying to log in by https
08:33:53 hotspot,info,debug d5oy3ace (192.168.17.132): login failed: simultaneous session limit reached
08:33:55 hotspot,info,debug d5oy3ace (192.168.17.132): trying to log in by https
08:33:57 hotspot,info,debug d5oy3ace (192.168.17.132): login failed: invalid password
08:33:58 hotspot,info,debug d5oy3ace (169.254.14.91): logged out: keepalive timeout
08:35:05 hotspot,info,debug d5oy3ace (192.168.17.132): trying to log in by https
08:35:05 hotspot,account,info,debug d5oy3ace (192.168.17.132): logged in
Once user connected it didn’t cause trouble for the day.
Stange that it can use 169.254 ip address with pool set to none in hotspot conf.
I’m thinking at what changed since last time in this setup.
I have proxy arp enabled on my wifi APs but I have it since few years.
This time I activated some acl rules on my Cambium APs to clean the air.
To prevent un-authorized rogue DHCP server from the wireless clients.
Unwanted DHCP client packets from wired network side.
Drop L2 broadcast packets.
Drop multicast packets.
Drop ARP discovery packets from one SSID to another SSID interface.
And drop mdns , and IPv6 trafic.
Not sure why only some windows stations are affected the first time the log in the day.
Semi-random idea, would setting ip-binding to something like:
/ ip hotspot ip-binding
add address=169.254.1.0-169.254.254.255 type=blocked
effectively prevent the APIPA addresses from logging in (via mac-cookie)?
Though the “fault” is most probably in the client that attempts to login before having a “proper” DHCP address (or wait for a timeout), it is good to know that RouterOS can deal with that.