we have setup two wireless bridge BR350 to link two sites, which distance is about 7KM. The configuration is very simple, one side is Root bridge and the other side is non-root bridge w/o Clients, no WEP implemented, the speed here has been fixed to 1Mbps. Initial firmware of both bridges is 12.00T, the bridges loss association after every 18min, the error message on the root bridge shows that "Deauthentication from [SlaveNode] 00409652014e, reason "not authenticated" ".
We have upgraded the firmware to the latest 12.01T, the problem is still happening and every 30-40 minutes, there is a loss association. after around 2 minutes, it authenticated and associated again.
Since you have upgraded to the latest version of firmware the problem could be RF interference. Make sure you have clear line of sight between the two sites. You should check your antennas alignment and their connections to make sure they are tight. Make sure that there is nothing close to the antennas that would generate Electro Magnetic Interference (EMI) such as generators or AC units. http://www.cisco.com/warp/public/102/wlan/rf-problems.shtml#impair
Through the link test in the Bridge web interface, we found that the signal strength is only 1%, any due to IDA Singapore policy we only can set bridge power to 1mW. Is it the normal signal strength display or we need align antennas? If the alignment of the antennas is required, can you recommend some tools to use, since the two site is quite far away (7KM) and in between is the sea?
We had a very similar problem which seem to have been resolved when we made the following change. Note the external antenna on each bridge is connected to the Primary / Right antenna connector.
In the Bridge Radio Hardware menu we set both the Receive Antenna and Transmit Antenna to RIGHT. The problem has not returned since the change was made.
I'm seeing a similar problem. I have signal strength from 20-40%, but every 17 to 18 minutes the 350 bridges dissociate and deatuthenticate and then reassociate and authenticate.
Did you find a solution?
SOmeo told me to upgrade to version 12.02T but we have still the same problem. please let me know if you find any solution in your side?
We also have had this problem with the 350 series. We noticed the symptoms after 12.0 and thru to 12.02. This has affected both the bridges and AP's. This seems to have started after the firmware upgrade to equipment in the field (350 series), prior to the upgrade we did not experience this particular problem. We attemted to raise the Beacon from 100 to 2000 as suggested but this made the problem worse.
We look forward to some more "constructive" suggestions as to how to fix this as we have over 100 units deployed. If not you'll see more of these units on ebay.
There is a firmware issue that should be fixed in the next release beta testing is being done now
try setting the non root to non root with clients this often works you may want to use mac address filters to stop other clients associating to your AP
If the latest firmware has not resolved the issue you may want to try this.
If you go to radio -> hardware , beacon timeout interval is 100 , Make it 2000 or higher and
see how it goes .
Try hardcoding to bandwidth to 1meg bandwidth and see what happens .
Here is other trobleshooting steps
1. Try changing the Data Rates from Basic to YES, except for 1.0 Mbps.
2. Try reducing the Transmit Power of the Bridge.
3. Reverse the Role of the Bridges in the network.
4. Change the settings in the Setup -> Associations -> Advanced to 0
i.e 0 here means Infinite.
5. Try changing the Radio Frequency Channel .
6. try loading latest image and default config .
7. Perform the carrier busy test and observe it carefully, try a different
channel ( this will help to reduce CRC due to interference).
8.Reduced the fragment size on the bridges to half of the value.
9. If all the above possibility won't work re-config it to the factory
default setting and upload the new firmware .
Go to Radio -> Hardware change beacon timeout from 100 to 4000 .
If performance is slow, most of the time it means that the link is not
healthy, check antenna alignment , sometimes they have strong winds in the
area and they push the antenna out of alignment , ask if there was any
storms in the area lately it may have water inside the cable and it is
working on short, ask him how well shielded are the connectors on the
antenna. Check for CRC errors and duplicated packets it usually confirms
issues described above.
We have managed to stabilize the bridge links, by setting the role to non root bridge w/clients as suggested. However, we are seeing the same problem with the Access Points and have not been able to find a settings solution.
Is it possible that the injection amps may be causing this problem (grasping at straws), we noted that a downgrade from a 1 watt to a 500 mw injection amp seems to have corrected the problem at one location.
Note: the 1 watt amp tested fine, is not defective and was put in service elsewhere without any problems.
The use of amplifers is NOT supported by Cisco
It should also be noted that by adding amplifers you are now responsible for compliance and certification to local laws. The FCC certification on the AP or Bridge is no longer valid as you have modified the system.
If the signal is too strong it is just as bad as being too weak. The best way to visualise this is to think of a loud speaker playing music
If you stand next to the speaker at a rock concert then it is very loud but next to impossible to work out the lyrics of the song
If you stand back from the speaker then it is much easier to understand the lyrics ( well at least for some bands )
Standing to close to the speaker is the same as having too much gain in your WLAN system you can receive the signal but as it is too strong then it distorts increasing your error rate and causing an unreliable link
I agree, however amplification is used in order to correct for cable loss on tower infrastructure, further, it has not been an issue for 4800, 340 series equipment as well as other vendor equipment.
We do believe that we have found the problem. During our amp downgrade we also swapped out the yellow Cat 5 cable and the problem was corrected. We have used the cat 5 cables which shipped with the Cisco 350's instead of manufacturing and testing our own. We have since then swapped out the cables at other locations and this has corrected the problems.
if you need the batch number on these cables let me know.