@Ashok, I have now tried multiple times to reproduce with 20MHz channel-width, and I can confirm that I cannot make the problem happen. So 20MHz is also a work-around.
It is a very strange bug indeed, that seems to require multiple components to all line up: 5GHz DFS, auto-rf, open-security, and channel widths > 20. My hunch is that this is some sort of timing/deadlock situation, where when a 40MHz DFS channel is selected, the AP has to complete radar detect both for the main carrier as well as the second HT carrier, and somehow the security config of the VAP gets stuck in a bad state, or isn’t properly initialized completely, because things either aren’t happening in the right order or DFS channel select takes longer than some other subsystem is expecting it to.
(I have not yet tried 80MHz.)
For now, I am working around the issue by simply using ‘channel-list prefer-non-dfs’. This is actually the default on 5GHz out-of-the-box. I don’t remember setting this to all-channels, and I suspect that though non-DFS might be the default in the actual AP firmware, all-channels might be the default in cnMaestro.
Thanks @nathana for confirming.
We are working on this issue in our lab and will try to fix the issue ASAP.
Yes, the default value of Channel-list in cnMaestro(all-channels) and AP(non-dfs) both are different.
@Ashok so is the changing range to 20 the official fix atm or is there an update resolving this? just wanting an official yay or nay here so i can take this back and be like here is an approved solution.
We have found the root cause of the issue and fix will be available in the upcoming release.
@Network_Support_Spec The other workarounds that you can use until official fix comes (if you need wider than 20MHz channels on 5GHz) is to either use static 5GHz channels instead of auto-channel, or to set 5GHz radio channel-mode to “prefer-non-dfs”.
was just wondering what was the Root cause so we can refrence this and is there a ETA on the firmware update/what will it be called? version ect.
Will that EPSK fix make it into this release too?
@Springs The firmware branch in question that is being discussed is 4.x. If I had to guess, the release will likely be versioned as 4.2.4.
Your EPSK VLAN bug as I understand it is in the 6.x firmware branch. The bug being discussed here (where open-security WLANs stop working on 5GHz when the radio decides to switch channels and picks a DFS channel) doesn’t exist in the 6.x branch as far as I’ve been able to tell, so I suppose upgrading to 6.x would be one other possible work-around to those suffering from this issue, assuming there isn’t some other feature that they happen to be relying on that is buggy in 6.x (out of the frying pan, into the fire).
Of course, 4.x is not applicable to XV-series (WiFi 6) hardware, only to older e-series (WiFi 5) hardware, and my understanding is also that you are working with XV hardware. I believe XV-series shipped with 6.x firmware on day 1. Recently it was ported to the older e-series stuff, though I have avoided deploying it in production since I have not had too much time to extensively test the 6.x releases made for e4xx/5xx.
has the new firmware been rolled out yet?
Some DHCP clients get a 0.0.0.0 address on XV2 2T0 Outdoor WiFi 6
this topic has been solved. Pls can you tell me the solution or the new firmware to fix this.
I have still the Problem. The JPGs are from 5.2.23 Sunday yesterday.
Running only 2,4Ghz in a Hotel Outdoor with german Telekom Router for Internet and DHCP. Wifi AP in Bridge Mode. The Router is the Telekom Speedport Pro Plus with does the DHCP for all 4 Outdoor Wifi AP.
Produkt from Sagemcom France
After reboot the AP it works about 1 week, then starts again IP0000. I went from FW 6.4.2-r10 to the recommended FW 22.214.171.124-r1. It feels to got better, but still, after about 1 week starts again.
fing.exe Tool DHCP Check shows “no address”
Please upgrade devices to 6.5.1-r11.
- Multiple issues related to 0.0.0.0 IP address has been fixed.
Please upgrade couple of APs and share your observation, if you still face issue.
Thank you for the fast response and the Hint.
2 of 4 Update from FW FW 126.96.36.199-r1 to FW 6.5.1-r11.
I will check the next week if the IP0000 are gone away with the new Firmware.
How to debug “best practice” ?
Do you have any Hint how to debug in deep this problem with Wireshark, any Tools or some good mobile handy apps with connect / de-connect every 5 min with wireshark Recording on the mobile phone to see, what is going wrong. Maybe this way i can give you better information to find the problem or maybe to find a problem with the DHCP or the LAN connection to the Wifi AP.
I am having this issue and it is really frustrating, Cambium support are taking time to reply so I will try here, E500 on firmware 4.2.3-r2. Only able to see 188.8.131.52r7 but cannot install as it keeps skipping. I have lost a lot of time on this and the client is not happy. I am disappointed that Cambium has let this develop and will not buy an item until I see it fixed as it can lose me clients. The work arounds are not able to be applied as it will not sync with them. Is there any update on when this will be fixed. I also cannot see where you are able to disable DFS on the GUI.
Any update on fix? Any viable workarounds. I need this fixed ASAP. Thanks
Two of several workarounds mentioned are
1 - Change the Channel Width to 20 MHz for the 5 GHz radio.
2 - Change the Candidates Channel list for the 5 GHz radio to prefer non-DFS channels.
I am including screenshots of cnMaestro and the Web GUI where you can change these values.
I have tried the above and still getting 0.0.0.0 - any others ideas?
I was assuming the issue you are encountering was that clients associate and work for a while then at some point lose their IP address and then show 0.0.0.0. If they are associating and never are able to obtain an IP address and so show 0.0.0.0 then that is another problem. Maybe you can provide more detail on how the clients are associating and ending up with 0.0.0.0.
The clients try to associate with the AP but it never achieved it. The system just gives them a 0.0.0.0 address. You can see the device from cnmaestro so it has associated but has not handed out an IP address
You may see the problem if a client is trying to connect with a low RSSI and the Client is connected/disconnected within a few seconds and in this case the AP is not able to provide proper IP to the client due to lots of packet errors.
Please send the tech support to me at firstname.lastname@example.org . Let me analyze the problem.
I ripped them all out and put in Ruckus - just got fed up, support was too slow and asked questions that were originally answered or were totally irrelevant. Thanks for coming back. But this is a really good client of mine and we could net be putting up with the issue. For your info I was standing within 3 metres of the device when it happened to me
Please send the support ticket ID and let me analyze the issue.