NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
WNDAP350's are constantly rebooting
WNDAP350 significant problems
I have 5 of these on various network segments over a large geographical area. All are using different wiring, different network switches, nothing in common with any of them except one thing. All are experiencing exactly the same problem.
Log excerpt
Mar 21 11:41:51 hostapd: Network Integrality: Ping Failed
Mar 21 11:41:51 hostapd: Network Integrality: Host: 10.110.255.254 is down.Bringing down all the vaps
Mar 21 11:41:51 kernel: brtrunk: port 2(wifi0vap0) entering disabled state
Mar 21 11:41:51 hostapd: wifi0vap0: STA 00:1b:63:cc:f5:40 IEEE 802.11: disassociated
Mar 21 11:41:51 hostapd: wifi0vap0: STA 00:26:4a:c1:51:26 IEEE 802.11: disassociated
Here is what I've learned:
When there are no associations at all (over a weekend for example) there are no problems; pings are always successful.
After there are a couple (two or so) associations then the above occurs maybe about once every 4 hours. You start getting more associations then the “Ping Failed” occurs more frequently. On one where there are about 30 associations the failure occurs about every 20 minutes, sometimes more frequently.
I am aware that these 350s ping their respective default gateways. Examination of the router's respective logs show the routers are working flawlessly. Indeed, everyone “wired” on the various network segments are not having any problems. Each 350 has it's own Gig/sec connection. Measured network traffic is rarely over 3% of available capacity.
So, in the 350's firmware, is it waiting a shorter and shorter amount of time for a ping return as the number of associations increase? Therefore, it is timing out waiting for the return when if it would wait just a little longer it would be satisfied?
I've got to solve this problem before I can deploy anymore 350s. I'm not replacing anymore WAP54G's which are working just fine.
Thanks for any help here.
Bob
I have 5 of these on various network segments over a large geographical area. All are using different wiring, different network switches, nothing in common with any of them except one thing. All are experiencing exactly the same problem.
Log excerpt
Mar 21 11:41:51 hostapd: Network Integrality: Ping Failed
Mar 21 11:41:51 hostapd: Network Integrality: Host: 10.110.255.254 is down.Bringing down all the vaps
Mar 21 11:41:51 kernel: brtrunk: port 2(wifi0vap0) entering disabled state
Mar 21 11:41:51 hostapd: wifi0vap0: STA 00:1b:63:cc:f5:40 IEEE 802.11: disassociated
Mar 21 11:41:51 hostapd: wifi0vap0: STA 00:26:4a:c1:51:26 IEEE 802.11: disassociated
Here is what I've learned:
When there are no associations at all (over a weekend for example) there are no problems; pings are always successful.
After there are a couple (two or so) associations then the above occurs maybe about once every 4 hours. You start getting more associations then the “Ping Failed” occurs more frequently. On one where there are about 30 associations the failure occurs about every 20 minutes, sometimes more frequently.
I am aware that these 350s ping their respective default gateways. Examination of the router's respective logs show the routers are working flawlessly. Indeed, everyone “wired” on the various network segments are not having any problems. Each 350 has it's own Gig/sec connection. Measured network traffic is rarely over 3% of available capacity.
So, in the 350's firmware, is it waiting a shorter and shorter amount of time for a ping return as the number of associations increase? Therefore, it is timing out waiting for the return when if it would wait just a little longer it would be satisfied?
I've got to solve this problem before I can deploy anymore 350s. I'm not replacing anymore WAP54G's which are working just fine.
Thanks for any help here.
Bob
45 Replies
- This morning I replaced one of the WNDAP350s with a Cisco Aironet 3500. Been watching it all day. 36 connections and it's been working great.
So, right now my WAP54G's are working fine, the 3500 is working fine, and the Netgear 350's are periodically turning off their radios because they think they're not connected to a network.
Hmmmm.... I wonder where the problem lies? - hi,
Sorry i think i can't help you; just to say we have many WNDAP350 (firmware 2.0.9) and we never had your issue.
They work great (with bugs :D but nothing serious)
Did you call the support ?
Hope you'll find the way out ;) - Yea... I'm running the latest firmware also.
I just replace another one with an Apple Airport. The Airport has been working flawlessly all day.
So now..
All the Linsys's have always been working well.
The Aironet has been working flawlessly.
The Apple Airport has been working without problems all day.
Just the 350's are periodically deciding they are not wired to the network and then turning of their radios. And, the higher number of associations, the more frequently they decide they don't have a wired connection.
I appreciate you relaying your experience with them.
Not contacted support yet. Wanted to make sure of the facts before I talked to Level 1/2 support.
Bob - Since we have our WNDAP350 we had never need to reboot or something like that until we have upgraded firmwares ;).
We use lot of SSID and 2,4ghz/5ghz together.They are wired to a Netgear GSM7224v2. Jumbo disabled for AP. We also have 1 old Cisco Aironet 1131AG. All work flawlessly.
Did you try Wireshark to see what's going on ? A reset factory ? With another switch ?
;) - I should point out that I believed my 350's were working fine. The users never really reported any problems other then usual “sometime slow printing” or, “my Email client required I re-authenticate to the Email server”; things that could be solved by updating out of date drivers or stop wandering between cells, etc. Most all users attributed their problems to old operating systems, not enough memory, or this is just the way the laptops run. It's the OS; just reboot and everything worked fine.
When looking at the 350's logs I would see nothing wrong. At that time I didn't really pay attention to the fact that the logs only kept about 10 minutes of data.
The way I found out that these units had problems is from my network management software. It checks to see if all the units on my network are alive by pinging them every 10 seconds. I usually do not check it's logs because I see everything in the green all the time. However, one day I did check the logs and saw that the 350's were frequently not there then reappearing in about 30 seconds or so. When looking at the 350 logs I didn't see anything because the problem had already scrolled out of the buffer. It was a cat-and-mouse game for several days until I caught a 350 going dark. I immediately checked it's log and found the “ping failure”. I saved the log. After doing a lot more legwork I picked up on the fact that the problem was more severe as the number of associations increased. And, the problem was only associated with the 350's.
So, like I said, I hadn't been made aware from my users that there were any kind of problems that I could associate with anything other then normal under provisioned hardware for the kind of heavy duty apps. they were trying to use.
It's quite possible others have this problem and never know it.
Just some thoughts.
Bob - It's not a switch issue. These 350's are on different parts of the network with different switches and different routers. They are pinging their default gateway (all different) and for no apparent reason deciding they are not wired to the network. They turn off their radios. In about 30 seconds (give or take) they successfully ping their gateway and turn everything back on. Users who are browsing the Internet never know it's happening. Users who are connected to file servers never know the wireless went down and then came back up because they are reconnected to their resources in the background. Yes, I did a wireshark capture. The default gateways are replying. The 350's are just ignoring them. Since the problem is worse when the 350 has more associations I'm guessing it's a timing issue. I don't see jumbo frames being a factor with the 350 pinging and listening for a reply.
- hummm i see...
Do you have enabled "detecting rogue AP" ?
Do not use that, it's a sh.... :eek:
We use HostMonitor here to check our network. I have added ping test every 10s for our 350 AP. Let's see if your issue occurs here too. :confused:
You have talked about the AP log (buffer log, 10min, etc...) but here, the system log has never worked ! Nothing appears in the window ! We called the support and they said that this window shows only important events like reboot, modify settings...but for us : nothing ! :D
Fortunately we use kiwi syslog server and we can see all events coming from 350 APs. ;)
Maybe you can post here a print screen from your system log ? - There's a 350 log excerpt in my first post. Ping fails, the 350 disassociates everybody, then turns off it's radios. Sort time later the ping is successful and turns everything back on. With everyone disassociated it appears it now has time to actually hear the echo reply.
overlook237 wrote: hummm i see...
Do you have enabled "detecting rogue AP" ?
Do not use that, it's a sh.... :eek:
We use HostMonitor here to check our network. I have added ping test every 10s for our 350 AP. Let's see if your issue occurs here too. :confused:
You have talked about the AP log (buffer log, 10min, etc...) but here, the system log has never worked ! Nothing appears in the window ! We called the support and they said that this window shows only important events like reboot, modify settings...but for us : nothing ! :D
Fortunately we use kiwi syslog server and we can see all events coming from 350 APs. ;)
Maybe you can post here a print screen from your system log ?
And another note, all my 350 logs are showing everything, associations, disassociation, encryption key exchanges, etc., etc. That's why I had to work so hard to capture the moment the ping failed. The buffer is so small.- Yes, rogue is on. Problems? I'll turn it off on some to see if it makes a difference.
