JP, you can also edit the WLAN profile in MC9090 and set it to CAM mode. This will help you identify whether the the client goes to sleep in between handshake messages and disconnects from the network due to that.

JP, You need to custom your datarate to make it works. I met this issue with a lot of customers (from WING4.x to WING5.2). I have set my daterates like that : 1,2 BASIC 5 to 24 SUPPORTED Let me know. Matt

Hi all, from my observations in the past, I have recognized that we are sending the 4-Way Handshake packets (EAPOL) always with the highest available datarate. I was not able to see any rate scaling in all my WLAN traces. Due to the fact that a mobile device could be not close enough to decode all the 54 MBit/s packets, the 4-Way Handshake will fail all the time, which ends up in no connectivity to the server. Disabling the higher datarates like Matthieu is doing it or using 802.11b data rates only will help to get the EAPOL through the WLAN. From my point of view, this is only a workaround and we should use the same data rate the broadcasts are using for the 4-Way Handshake packets. With the broadcast-tx-speed parameter in WiNG we are able to control the data rate then. Best regards, Angelo

All Please see attached a document from Engineering with WING 4.x best practices. This should summarize most of the recommendations/workarounds given in this thread and add few more. One command which is not there, but it should be useful with our Motorola equipment only is the smart-scan command (allows faster connection, eliminates wasteful scanning and preserves battery life and RF bandwidth)
Specifies a list of channels for Motorola clients to do smart-scan

Syntax

smart-scan-channels [|add |

remove ]

 

Parameters

 

A comma-separated list of channels

add Add one or more channels to existing channel list

remove Remove one or more channels from existing channel list

 

Example

RFS7000(config-wireless)#smart-scan-channels add 1,6,11 Hope this helps.

Execute the CLI command: no firewall stateful-packet-inspection l2 (the last part of the command is L2 lower case) I have found that layer 2 stateful firewall inspection causes Telnet & SSH clients to sometimes loose packets and thus "lock up" due to some of the clients sending packets out of stateful order.  I had similar issues and this resolved them.

Jack, Thanks for the tip ref the firewall, however we gave this a go but still the same the fact that running data rates at .11b only and the problem is not seen however when running with b/g rates the problem is still there. I think a wireless trace is in order. Anyone knows what the dot11i handshake timeout and retry is on old V2.1.2? maybe I can match it this way. JP