nelson05
03-29-2006, 04:00 PM
After evaluating the recently added WEP support and having good luck in the lab we went for this weekend and put our first WAR into production as an AP.
We have a very basic setup at the moment where only one out of the four CM9s is being used with the other three waiting to connect to other WARs to feed our backhauls at 5.x. The card is configured to hide its SSID, InterBSS Relay is Off, Short Preamble is On, SuperA/G is on, and Operating Mode is 802.11g only. The BSS channel is set to 2412, Transmit Rate to 24, Link Distance to 6.00 miles, Tx Power Override is default, and cloaking is off. WEP is enabled using two 104-bit keys, Shared Authentication and Key 1 chosen as the default. The interface is also running the dhcp-autoauth service. We were originally running mesh in the lab and left it enabled to prepare for the other links, but disabled it when we started having problems. The only other services running are ntp and syslog which I only enabled for troubleshooting purposes.
All wireless clients are WRAP boards running StarOS V2 with CM9s with the lowest signal around -76.
The AP is completely routed and connection tracking is disabled with the WAR fed by a a 10/100 switch that connects to our existing Proxim backhaul. A remote monitoring board that I can't say enough good things about is also connected to the switch (I think these guys have been mentioned on this forum before, but checkout www.bndcom.com (http://www.bndcom.com) and their Remote Monitoring System Version 2- a lifesaver). A Cisco AP is also in the mix. The WAR is fed by a 4A 12 to 24 V DC to DC converter. I've also tried running it with an inverter and the 800 mA 24V AC to DC adapter Valemount originally shipped with the board.
Now that I've written a book about our configuration, I'll get to what actually happened. The conversion went extremely well and performance was great- we moved 61 clients in stages off of our Cisco AP to the WAR. All links appeared to be stable with no packet loss. Along the way, we ran into a couple of serious issues that would have been major problems if we didn't have the Remote Monitoring board I mentioned above. After switching about ten clients over and entering their client names in the description field on the client display list, we went to save our changes. The SSH screen showed the BUSY indicator in the corner and then the interface seemed to freeze. We noticed our ping to one of the associated clients had stopped. The WAR had basically become inaccessible from the Wireless or Ethernet interfaces. The only way to restore connectivity was to power cycle the board, which we accomplished using the RMS board referenced above.
Once the board was accessible, we started entering the descriptions again, held our breath, and then saved changes. This time the busy indicator appeared and then went away as expected and the WAR was ready for more. Thinking we had run into a fluke, we converted a few more clients, hit save and the system responded as expected. We continued to add clients, saving every five or so and then ran into the same problem where the WAR completely locked and the only way to recover was to power cycle. The same pattern or lack thereof was observed as we kept converting clients (with fingers crossed) to the WAR. Sometimes the save would process with no problems multiple times in a row and other times it would freeze on two consecutive saves or the first time after a reboot. We encountered the same issue over multiple days with this morning being our most recent encounter with the crash. As long as I don't save changes, the WAR is stable, throughput is good, and everyone's happy. I haven't noticed a lockup when simply activating changes... is there something going on behind the scenes when a save is initiated?
One last thing... after power cycling the board, I've had it freeze a couple of times if I go in too quickly via SSH after it reboots. I'll get the logon prompt and enter it and the password, only to have the WAR immediately lock and stop responding to pings. If I wait a bit (a couple of minutes) after the restart, I can logon. I'm guessing the system is being bombarded with re-associations and DHCP requests though it still seems that it shouldn't lockup entirely. The syslog doesn't offer any clues.
Things are working now though I'm not saving changes if I can help it.
We have a very basic setup at the moment where only one out of the four CM9s is being used with the other three waiting to connect to other WARs to feed our backhauls at 5.x. The card is configured to hide its SSID, InterBSS Relay is Off, Short Preamble is On, SuperA/G is on, and Operating Mode is 802.11g only. The BSS channel is set to 2412, Transmit Rate to 24, Link Distance to 6.00 miles, Tx Power Override is default, and cloaking is off. WEP is enabled using two 104-bit keys, Shared Authentication and Key 1 chosen as the default. The interface is also running the dhcp-autoauth service. We were originally running mesh in the lab and left it enabled to prepare for the other links, but disabled it when we started having problems. The only other services running are ntp and syslog which I only enabled for troubleshooting purposes.
All wireless clients are WRAP boards running StarOS V2 with CM9s with the lowest signal around -76.
The AP is completely routed and connection tracking is disabled with the WAR fed by a a 10/100 switch that connects to our existing Proxim backhaul. A remote monitoring board that I can't say enough good things about is also connected to the switch (I think these guys have been mentioned on this forum before, but checkout www.bndcom.com (http://www.bndcom.com) and their Remote Monitoring System Version 2- a lifesaver). A Cisco AP is also in the mix. The WAR is fed by a 4A 12 to 24 V DC to DC converter. I've also tried running it with an inverter and the 800 mA 24V AC to DC adapter Valemount originally shipped with the board.
Now that I've written a book about our configuration, I'll get to what actually happened. The conversion went extremely well and performance was great- we moved 61 clients in stages off of our Cisco AP to the WAR. All links appeared to be stable with no packet loss. Along the way, we ran into a couple of serious issues that would have been major problems if we didn't have the Remote Monitoring board I mentioned above. After switching about ten clients over and entering their client names in the description field on the client display list, we went to save our changes. The SSH screen showed the BUSY indicator in the corner and then the interface seemed to freeze. We noticed our ping to one of the associated clients had stopped. The WAR had basically become inaccessible from the Wireless or Ethernet interfaces. The only way to restore connectivity was to power cycle the board, which we accomplished using the RMS board referenced above.
Once the board was accessible, we started entering the descriptions again, held our breath, and then saved changes. This time the busy indicator appeared and then went away as expected and the WAR was ready for more. Thinking we had run into a fluke, we converted a few more clients, hit save and the system responded as expected. We continued to add clients, saving every five or so and then ran into the same problem where the WAR completely locked and the only way to recover was to power cycle. The same pattern or lack thereof was observed as we kept converting clients (with fingers crossed) to the WAR. Sometimes the save would process with no problems multiple times in a row and other times it would freeze on two consecutive saves or the first time after a reboot. We encountered the same issue over multiple days with this morning being our most recent encounter with the crash. As long as I don't save changes, the WAR is stable, throughput is good, and everyone's happy. I haven't noticed a lockup when simply activating changes... is there something going on behind the scenes when a save is initiated?
One last thing... after power cycling the board, I've had it freeze a couple of times if I go in too quickly via SSH after it reboots. I'll get the logon prompt and enter it and the password, only to have the WAR immediately lock and stop responding to pings. If I wait a bit (a couple of minutes) after the restart, I can logon. I'm guessing the system is being bombarded with re-associations and DHCP requests though it still seems that it shouldn't lockup entirely. The syslog doesn't offer any clues.
Things are working now though I'm not saving changes if I can help it.