WAR 2 Port rebooting

[dastring]

I have been having lots of problems with the WAR 2 Porters rebooting... somewhat randomly as far as I can tell. I'm using them in 802.11g mode. I have been trying to trace the problem but there are so many variables and I don't have the best "testing" environment as my network is "in use."


I was reading an earlier post about WRAPs and CM9s rebooting.

Lonnie, do you believe there is any reason to think that the CM9s are sensitive and maybe the root of my reboot issue? If so, what card would you recommend I try in its place? I only need 2.4 GHz support for my application.


I've pasted the earlier post below:






webwave
Junior Member

Join Date: Jul 2005
Posts: 16
How I fixed my reboot problem.
I had a wrap with a single CM9 radio rebooting every 5 to 15 mins.. I fixed it by changing the link from G to B, and turning off all of the special features.. compression bursting, and fast frame... IN B MODE I turned fast frame and bursting back on.. and it rebooted roughly 2 minutes later.. I turned them back off... and its been up for 2 days.

Here is my conclusion.. By whatever manner.. if you push the CM9, or other type of radio to the point that it gets a certain number of errors within a certain time period... the hardware watchdog will reboot the radio...

Here are somethings that would cause excessive errors to the radio card..

Noisy environments
Poor link quality
Faulty hardware
Noisy channel

It seems to be more prevalent in the CM9 because apparently it tracks all errors that it "hears" in the air. then add YOUR errors on top of it.. this is the way I understand it from reading other posts in this forum..

Hope this helps..

[lonnie]

There is nothing in the driver that says to reboot after X amount of errors. At this time the only cards supported are Atheros based and the CM9 is the only cards we are using. You could try another brand but I am sure they are pretty much identical.

I suspect there is a TCP issue with bad packets. If you can hold on we will have the Linux stuff to replace the current software. We cannot really fix this since we cannot duplicate the issue. Time spent trying to duplicate and fix this is wasted since it takes away from the replacement, which is only 3 to 4 weeks away.