Friday, October 11, 2019

Ruckus mishandling DFS

We are a municipal ISP, offering fixed wireless connectiviy

We use Ruckus AP's and Mikrotik transceivers on the customers houses.

About a week ago we started hearing disconnect complaints.

Looking at the AP logs I could see radar moves followed by deauth.

Could see matching logs on the customer's equipment.

So as a test I disabled DFS channels on the AP's where customers were complaining.

This did not resolve the issue.

We had recently rejiggered our radius implementation, one of the key changes being non pays were not authenticated where previously they we put in a black-hole vlan. Knowing how dreadful Mikrotiks handling of deauths is in AP mode (we use hAP's for in home wifi), we had a strong suspicion they were behaving similarly in client mode now that we had deauths being sent by the APs.

So yesterday for a test we reauth'd everyone. No more loose deauth frames.

Still the issue persists.

Doing another deep dive in Ruckus/Mikrotik logs today I found DFS update followed by deauthing all clients on the AP and matching "lost connection, received deauth" on the Mikrotik.

This is on AP's that only use Uni-band 1 and 3, so obviously there is no frequency move.

Anyone seen similar behavior? How did you solve it? Any idea why it would start now?

For full disclosure the AP's now talk directly to freeradius, rather then proxying through SmartZone. That really doesn't look related however.



No comments:

Post a Comment