IdentiFi: 2.4Ghz clients unable to get IP



Show first post

39 replies

Userlevel 2
Hi James, did you try with 10.41.12?
Userlevel 6
I have not, I see "wns0021104 Corrected 2.4GHz rate selection on AP38xx for single 1x1 clients." in the release notes which is interesting, although the symptom I see is the AP can't hear the client, not the other way around. I'll see if I can find some time to give it a try tomorrow.
Userlevel 2
Thanks, working in the Public sector does not afford much time/environment for testing.
Userlevel 6
I tested 10.41.12 and it doesn't fix it. One thing I noticed with a RealCapture from an affected is that it doesn't see any probe requests at all from any client. You can see this yourself by applying the filter "wlan.fc.subtype==4&& wlan.fc.type==0 && !(wlan.ssid == "MyDomain")" in Wireshark.
Userlevel 2
Doesn't look like 10.41.13 has a fix either. Think I'll raise a call with GTAC
Userlevel 6
01729857 is my case number if you want to have GTAC compare.
Userlevel 6
I finally had time to spend debugging this with GTAC, we checked all the 10.41.07 builds and then a developer made me custom builds, rolling in one change at a time. Here's his conclusion:

I found the root cause. The change for wns0020188 caused ATPC to resolve to a TX Power that was just below the threshold that the MU can hear. I loaded back the GA build (10.41.14.0008) and disabled ATPC and set TX Power to 13 and now it works.
So did you have ATPC enabled, and what was the minimum transmit power? I am still going to go back to GTAC with some questions about this, since unless the change is reverted, the bug is still there. Also it doesn't explain why the AP couldn't hear probe requests from the client in the RealCapture. And I wonder if the reason a factory reset worked is if it changed the AP channel and so increased the TX power.
Userlevel 2
Hi James,

We do not have ATPC enabled.

Our WiFi deployment is based on an RTLS survey and as such as per best practice for this, all APs are set to certain power levels.

2.4 is set to 11-13dBm and 5.0 is 16dBm
Userlevel 6
Very interesting. I haven't had time to test this myself (GTAC was remoted in on Friday night) and won't until Wednesday, so it'd be good if you could tell GTAC you're not using ATPC but are seeing the bug.
Userlevel 1
Ian - if you have a Case open with GTAC, can you please share the Case ID? I've been working with James on his issues.
Userlevel 2
01830944, only really referenced this post and the additional fact that we dont use ATPC at this stage.
Userlevel 6
Had another debug session tonight, looks like ATPC is a red herring. Instead, try disabling all the DCS Interference Events in radio 2 advanced settings (we only had Bluetooth enabled, but that was enough to cause the radio to get stuck) and rebooting the AP.
Userlevel 6
Huh, I forgot to update this, it was patched in 10.41.15 and I think 10.51.02.0006, wns0021243. The fix was related to the radio startup order.
Userlevel 2
Thanks James,

I figured we'd try a 10.51. release, 10.51.03 which we haven't encountered any issues. Makes sense now.

Annoyingly we now have issues with multiple 3935s that we're replacing the 38 series with.

New GTAC has been raised for these.

Thanks for the help.
.

Reply