Some DHCP clients get a 0.0.0.0 address

@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.

2 Likes

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.

@Network_Support_Spec

We have found the root cause of the issue and fix will be available in the upcoming release.

1 Like

@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.