Thanks to all for looking at this one, it's a doozy! I think a few folks in the forum are seeing the same thing, from my searching, but I think this is a bit more data to assist in tracking it down.

Six total units in my network:

Primary AP - RB 433 - ROS 3.13 - 8602 Engenuis Radio
WDS AP1 and AP2 - RB 433 - ROS 3.13 - 8602 Engenius Radios
Client nodes 1,2,3 - Engenius EOC 3220+ external bridges

Using WPA/WPA2 encryption, every node gets to talking to the primary AP just fine. All the equipment signs on with WPA2, excepting one misconfigured bridge currently still on WPA. Most of the time, all runs well. However, if I remove the WPA compatibility from my security profile on the Primary AP, the WDS APs both show a problem that requires a soft reboot of the primary AP. Neither WDS AP will sign back on for more than just a second, showing up in the registration table, posting the Radio Name, but then, the Primary AP will log "unicast key exchange timeout" for the WDS APs and log them off the Registration Table. Client radios log right back on, no worries, and stay on the whole time. Rinse, repeat, ad nauseum. When I reboot just the Primary AP, the WDS APs will sign back on, and all will be well again. I've tried disabling the radio instead of a reboot, changing encryption, etc, no avail. Only a soft reboot of only the Primary AP clears out whatever memory and gets back on the road. I have duplicated this 4 times this morning, ensuring this was the exact stimulus/symptom.

What gives? Ideas on where I can provide more data to track this down? It's a BIG problem, as I use WPA2 for encrypting backhaul networks, and I cannot leave these links open. Any assistance would be GREATLY appreciated.

Thank you!

Taylor

I too am having this problem. When WPA2 encryption is enabled WDS does not work. I get the same "unicast key exchange timeout" error message on both WDS nodes.

if you are using connect-list for WDS then you should also specify in the connect list rule which security profile to use.

Not currently using connect list.

It does work for me, except after a disconnect due to reconfigure of WPA settings or -meybe- signal loss. Since yesterday, I have ensured NTP connectivity and verified all clock settings. Overnight, no disconnects and certainly no disconnect/reconnect loops with the unicast key issue. However, I am fairly sure I could create one by altering then returning the WPA settings to existing state. I would like to provide more debugging info if possible before I create that condition again. Ideas?

Thanks for any help!

Taylor

if you are using connect-list for WDS then you should also specify in the connect list rule which security profile to use.

Yes I have tried with and without a connect list. When I tried with a connect list I specified the security profile.

It has happened again. I have lost the WDS node repeater. I am going to try rebooting just that repeater via power cycle.

It is strange that the bridges on this network do not have the same problem, only the MT WDS repeater. I really wish I could provide more debugging output, this problem is of great concern. I am looking to roll out hundreds of these units, outdoors and indoors. I have the funds to use multiple radios, perhaps using nstream for my backhauls, but that would be extremely inefficient.

Please help me resolve this problem if possible. I am at your disposal for information.

Thanks!

Taylor