Omada Software Controller_v5.2.4 For Trial (Beta Edition) - Updated on 7 May 2022

Re:Omada Software Controller_v5.2.4 For Trial (Beta Edition)
2022-05-02 18:03:20 - last edited 2022-05-04 14:31:45

On this beta, I experience issues with full-sector DFS feature and in general radio detection seems to be buggy producing probably either false reports or even worse ignore channel change requirement due to device not reporting about it, one of both must be the case leading to think that radio detection is in some way broken. I am not sure if this same behavior can be achieved with other omada versions, but with current beta I experience following issues with DFS:



1. If Full-Sector DFS is enabled, then it overrides "Channel Limit" setting to meet local laws and regulation.
Test case: 2x eap245 root AP, 2x eap225-outdoor root AP, one eap225-outdoor mesh client.

1.1 EAP225-outdoor can not link due to point 1.

Outdoor eap225-outdoor root AP's change their channel to some under 100, resulting in all mesh client AP's not to be able to see them and no link can be seen/chosen (neither auto nor manually).


2. Radio detection is broken and causes network instability.

There are every few minutes some radio station detected, but curiously placing 2 same device very close to each other results always in only one device detecting radio. I did this test by using 2xeap225-outdoor devices which are bound with each other meaning their distance is 1mm or less. Both were connected in 2 different networks with 2 different wans, meaning both were not in one network. Both operated on same channel (some between 100 and 108), but when one device detected radio signal, the other device never detected it which is quite impossible that only one device detects it in 10 of 10 tests. I had not one case where both devices reported about radar connection.

This means that on one side if there is radio signal saying keep the channel free, only one of them does it. This leaves a question if device operates according to local laws. 

How to reproduce steps one and two:
Rebooting all indoor devices (keep outdoor ap's connected, do not reboot) at the same time results in one them reporting about device in a network and sending channel change to all ap's ("Full-Sector DFS"). This is problematic as it overrides channel limit to meet local laws and regulation.


Feature request: mesh client should know which AP to it will link if its actual link is broken, one should be able to define backup link where it will keep the info about DFS change (as backups can change too) and ensure that those 2 root AP do not run on same channel as in correct behavior if radio signal on that channel would be detected mesh client looses connectivity for several minutes. Backup definition should be synced to eap device during provision, then no re-adaption would be required and whole process could be much quicker even under a second instead of 10-30 minutes.




3. After disabling full sector DFS and rebooting, device hangs in isolated state and one has manually to link AP. On first click of "retry", user is asked for a password saying wrongly that crendentials are wrong, just closing this window and reclicking "retry" opens then same window where AP can be chosen and no credentials are asked.


4. WebUI has some issue with chrome based browsers (tested with brave). When one goes with the mouse over "Question/Info" mark which shows then description of that feature, then after unspecific amount of mouseover browser hangs and process has to be killed.


5. Disabling SSID resolves as temp workaround DFS related issues, instead of every 2-3 min changing channel due to radio detection. One has to disable all other SSID's on root AP and client AP (at least those which do send SSID), otherwise outdoor devices are useless as frequency of radar detection happens at least twice during client AP requires up to 10 min to get a state "connected".


6. After around half a day, root AP's which have no clients suddenly seem to have signal power reduction. On reboot 2 root AP's show both in range of -50 to -60dBm, only one is linked and after around 12 hours (thats when I checked, not sure when it happens) if one tries to rescan for AP's then not used one is either not found at all or it shows something like -96dBm. This can only be resolved by rebooting root AP in question.


7. Misleading timestamps in Logs. Despite timezone settings of the controller, logs show GMT0 time instead of the timezone selected.