[solved] DHCP on a bridge using STP. Was: RB2011UiAS-2HnD "received disassoc: sending station leaving (8)"

Ape · Tue Jul 14, 2015 10:27 am

Hi,

I'm running a RB2011UiAS-2HnD for a year now (running ROS 6.29.1 and the wireless-fp package).
This morning, I suddenly got problems regarding the clients connecting to wifi.

I can't connect WiFi devices to the AP anymore. The log shows

07:15:51 wireless,info 84:63:D6:B4:46:CC@wlan1: connected
07:16:11 wireless,info 84:63:D6:B4:46:CC@wlan1: disconnected, received disassoc: sending station leaving (8)
07:21:25 wireless,info 84:63:D6:B4:46:CC@wlan1: connected
07:21:45 wireless,info 84:63:D6:B4:46:CC@wlan1: disconnected, received disassoc: sending station leaving (8)
07:23:46 wireless,info 84:63:D6:B4:46:CC@wlan1: connected
07:24:06 wireless,info 84:63:D6:B4:46:CC@wlan1: disconnected, received disassoc: sending station leaving (8)

for almost every connection attempt.
Sometimes, after many retries, a device can connect. So far I tried a Windows Phone, an Android Tablet and a Windows 7 Laptop.

A thing I noticed is: As far as a client connected successfully, other clients may connect without problems. It seems that this issue somehow affects the "first" connecting client.

I do understand, that the log message tells, the client device is disassociating from the AP - but for no apparent reason. Yesterday it worked just fine, now it suddenly does not.

Here is my config:

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa-psk,wpa2-psk eap-methods="" \
    management-protection=allowed mode=dynamic-keys name=WPA/WPA2 \
    supplicant-identity="" wpa-pre-shared-key=hellfire wpa2-pre-shared-key=\
    NotSoSecret!
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=5 band=2ghz-b/g/n country=\
    germany disabled=no distance=indoors frequency-mode=regulatory-domain \
    l2mtu=1600 mode=ap-bridge security-profile=WPA/WPA2 ssid=Z8 \
    wireless-protocol=802.11

I already read http://wiki.mikrotik.com/wiki/Manual:Wi ... CREASON.3E but could not find any helpful answer.

Found this thread too: http://forum.mikrotik.com/viewtopic.php?t=85033. But as there is no solution described I thought I'll give it another try.

I really appreciate any input on this. My guess is a hardware malfunction / defect. (Update: Hardware defect in my brain, see my last post).

Please share your thoughts with me.
Thanks a lot!

Ape

Update:

What I tried so far:

- reset the device to factory default, importing the config -> no change
- cold reboot (disconnecting the power plug for ~5 minutes) -> no change
- disabled WPA/WPA2 authentication -> no change
- added devices to access list -> no change
- reset the wifi config, re-configured it manually from scratch -> no change
- disabled chain0, then chain1 -> no change
- disabled wlan0 interfave, re-enabled -> no change
- changed frequency and SSID -> no change
- changed mode from B/G/N to B or G -> no change
- used the old wireless package instead of wireless-fp -> nb change

Tue Jul 14, 2015 6:35 pm

Enable wireless debug logs. Clear network profile from clients devices and create a new one. Use aes instead tkip if you don't. Switch the wlan to station mode, connect it to other Ap and check the signal levels. Is the wlan in bridge with dhcp server? Sometimes mobiles disconnect when do not get ip address...

Ape · Tue Jul 14, 2015 7:37 pm

Hi jarda,

thank you for your input.
I forgot about wireless debug logging - noob error.

Yes, I do run a DHCP server on the bridge-interface, which bridges wlan0, ether1 and ether6. Thanks for the hint. This could be the explanation why the clients do the disassociaten by themselves. Next question is: what's wrong with the DHCP.

I'll keep you updated and thanks again!

Ape

Ape · Wed Jul 15, 2015 12:36 am

Hi,

I solved my issue.

In our server room, there is a sign on the rack "Thinking helps" and ideed it does!

My issue is not related to WiFi or DHCP but to STP!

I have to share this:

I configured a bridge "loopback". I configuren ports ether1, ether6 and wlan1 as slaves of this bridge. I also configured this bridge to do STP and this is where my issue started. The DHCP server acts on the bridge "loopback".

Consider following scenario:

No WiFi device is associated with the AP running on wlan1. So the bridge port wlan1 is "down". The first WiFi device associating with the AP brings the wlan1 in the "running" state, triggering the STP algorithm on the bridge "loopback". As this takes some time, the WiFi device does not get an IP and therefore is disassociating from the AP.

I mentioned, that the issue occurs for the "first" WiFi device which tries to associate. And indeed, when there was a successful association, the bridge port wlan1 becomes running, the STP algorithm spans the tree and all "following" WiFi devices associate with the AP and are getting an IP address from the DHCP server immediately.

Conclusion: Don't configure STP on the bridge used to bridge the ethernet interfaces to the wlan interface, as there might be WiFi devices which don't wait as long as STP takes to span the tree for a DHCP lease.

jarda, again thank you very much. You made me think this through!

Ape

Wed Jul 15, 2015 8:45 am

Glad I could point you in the right direction. Very nice finding! It is better not to have stp on when there is no risk of loops. I use different path cost values on bridge interfaces together with RSTP where loops are intentional to get some kind of "dynamic routing" on L2. Using administrative mac on each bridge could also prevent some headaches. Is your result better with RSTP than with stp?

Ape · Wed Jul 15, 2015 9:11 pm

Hi,

i just tried using RSTP and it's working fine.

As the "R" in RSTP stands for "rapid", I think the time it takes to achieve loop free connection is short enough so the WiFi device gets an IP before it sends the disassociation.

Ape

Thu Jul 16, 2015 8:56 am

Good. Enjoy the RSTP!