Interaction between some clients / Band-Steering / MR 32 bug

[skendric]

I believe that I'm seeing the following behavior.  Can anyone else confirm this?  Or poke holes in my story?

- Some Clients seem to be able to dodge the "Dual-band operation with Band-Steering" option we have enabled, selecting 2.4GHz (perhaps because signal strength is stronger) over 5GHz
- MR32s (v26.8.2) have a bug in them such that sometimes they quit forwarding DHCP (and possibly other IP protocols)
- Thus, clients which are able to dodge Band-Steering, which then connect at 2.4GHz, and which associate to an MR32 which is experiencing this bug ... don't enjoy the experience

Sometimes this bug clears up on its own; and rebooting the MR32 clears the bug for a 'while' (sometimes for just a few minutes)

--sk

[cmr]

@skendric band steering is exactly that, it tries to get the client to use the 5GHz band, but ultimately the client makes the decision.  With regard to the DHCP bug you mention, we have quite a number of MR32s and haven't seen this.  What is your DHCP server for those APs?

[PhilipDAth · Accepted solution]

I have observed the DHCP issue on MR32s as well.  And only on that model.  Seems to affect very specific WiFi chipsets.  I have a customer with maybe 5,000 WiFi client devices, and it affects about 10 of those clients (notably those 10 are the cheapest 2.4Ghz Android tablet money can buy).

We did packet captures for support showing the DHCP packet being received on the WiFi side of the MR32 but never leaving the LAN side of the MR32 (SSID operating in bridge mode).  The packet goes missing inside of the MR32.

In my client's case, the Android tablets were supplied as part of a managed service, and they were forced to use them.  Luckily they were only used in a small area, so we upgraded the APs to MR36s and that solved the issue.

[skendric]

I have a flock of ~150 MR32 & MR33 contained in a single building.  I have documented the issue with (3) clients:

- OS X laptop

- NetAlly EtherScope NG

- NetAlly AirCheck2

I have anecdotal evidence of other clients being affected as well, but no pcaps to support these claims

I have built up a library of simultaneous pcaps captured in the air next to the Client, at the WiFi side of the MR32, and at the Wired side of the MR32 ... showing what you report, i.e. that the DHCP frame gets dropped at the MR32.  We have also tried statically assigning an IP address to the Client; at that point, we see ICMP Echos also dropped at the MR32 ... which suggests to us that when the MR32 has entered this state, it drops all WiFi-side IP frames

We have tried and failed to replicate the problem as follows:

(a) At 5GHz with the MR32

(b) At 2.4GHz with the MR33

OK, so your experience suggests a more narrow fingerprint than mine.  But useful to me to know that at least one other customer has seen a variation on this issue -- thank you

--sk