IF delays are not surely not due to cabled infrastructure (which you can simply detect just testing the application using a cabled PC and ClientAccess, for instance), one thing that helped some time ago was -yes, believe it or not!- setting all the APs on the same channel. This way, roams are faster so X-Waits did not show again. Yes, there were of course quite a lot of self-interferences, but this was somehow sorted out limiting power on APs and setting the right sensible speed rates. There are some parameters one can tune on AS400 side, about delays and timings, but unfortunately I can't find the document they were stated on. Maybe on WaveLink's site there still is something about...

Bruce, Why the reboot??? Are the guns losing association to the WLAN or assigned IP address??? Usually, an XWAIT is associated with an IBM (AS/400) type of host emulation (TN5250???) session... Are you sure the delay isn't with the host and that a warm boot merely masks a correction??? As a debug measure, I would confirm that your device is still associated, has an IP address and then use the PING diagnostic tool within Fusion to PING either the default gateway or host IP addresses.... If the PINGs are successful, I would be suspect of the Host and it's available resources.... Good luck.... Efrem Robinson

Bruce, X-waits will occur @ various lengths depending on the extent of delay for either the client sourced data to transmit or for the server sourced ACK to deliver from the AS/400. If using a high-overhead security profile (i.e. a form of WPA) where x-waits occur when users operate in fringe coverage or poor path environments, a delayed re-auth during a new roam, especially while the telnet data frame is waiting for an IP route to transmit, will contribute to these delays, but in my experience, inherent latency or congested T1 over a broadband route to a remote host (assumed to be the case here), would typically be the primary contributor. You'll be hard pressed to eliminate x-waits entirely, but if you ensure the WLAN coverage provides adequate RF signal throughout, roams will complete more efficiently, you'll minimize the length of the x-wait messages & will have narrowed the cause down to the client-server path. A good start for analysis would be to follow Efrem's suggestions and to consider applying the Netlog trace tool in order to review the TCP/telnet exchange flow, looking for patterned delays during server response and delayed telnet exchange based on the affects of the roam/re-auth.