01-03-2003 08:30 PM - edited 07-04-2021 08:25 AM
I have a 350 to 350 bridge W/ a 2 mile run and they work well <10ms Response.when a good bit of data is passing it does the de-Authentication and then a couple of minutes later it re-authenticates and re-associates and it will be fine both bridges can be seen on either side from the Hard wire lan so i know that interface is solid the Antennaes have been checked out and appear to be pointed correctly and secure otherwise the antennae would not pass data at all! I am at a loss as to where to go from here... Any ideas?
Also on the client i get this message (Lost Authentication with Parent)
Solved! Go to Solution.
01-04-2003 09:31 AM
Do you run any authentication algorithams like LEAP, or WEP etc..? WEP key timeouts force to re-authentication so check in that area and increase the timeout. Also load 12.0T on all the bridges moving forward.
01-04-2003 09:31 AM
Do you run any authentication algorithams like LEAP, or WEP etc..? WEP key timeouts force to re-authentication so check in that area and increase the timeout. Also load 12.0T on all the bridges moving forward.
01-05-2003 07:50 PM
Does this occur only when the traffic load increases ? If it will stay stable at low traffic load then only occurs at hight traffic loads then it could be a problem with radio congestion.
The classic sign of congestion on the radio network is Retries and Max packet retries counters and Discards are increasing These can be seen on the root radio port page
Max Retry PacketsThe number of times request to send (RTS) reached the maximum retry number. Click Set Properties to display the Root Radio Hardware page, where you can set the maximum RTS value
Total RetriesThe total number of retries that occurred through the radio port
If you have a high number of CRC errors that often indicates interference then this can also case congestion on the radio interface as the bridge tries to transmit but detects the interference and holds off the packet (a retry)
If you see Max retries incrementing and no or very few CRC errors then try setting the etherenet port and and the switch port to 10M half duplex ( radio port is 11M Half duplex so this means very little buffering should be needed by the bridge) and use the switch and or router to control the traffic rate via QoS
If you see these error messages with no or very little traffic then I would suspect an RF link problem
01-07-2003 06:26 PM
I upgraded the firmware to 12.01t on both Bridges the root first and as soon as i did that it got better. Then I did the non root bridge and as soon as i did that the Radio link is solid. It has not dropped at all. However it does deauthenticate and within 1 sec reauthenticates. Seems odd you never see a loss of comms but the log shows these errors. Thanks guys it works great now.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: