Just bought 2 of these (wish I had seen this thread before). They shipped with the latest firmware already on them, so must be a very recent manufacture. I am having the exact same problems as above. It seems to be almost exactly 24 hours for me and the access point stops passing traffic. At first the latency goes very high (2200ms - 3800ms) right before it stops passing traffic. You can still ping the access point from the 802.11 side for a while, but nothing from the wired side, it just goes braindead. Once I was able to get the management interface up over the wireless while it was in this state and rebooted from the management side. It did not solve the issue, I had to unpower it and restart it (PoE Powered). I have only configured one of them due to these issues. I think they are going back. Here is how the access point arrived (yes, I just rebooted again for the 8th time).
|Local MAC Address:||00:13:60:FF:AF:F0|
|System Up Time:||0 hour:34 min:35 sec|
Mine are still working perfectly after the firmware upgrade! Remember, mine are in BRIDGE mode and are not being used as AP's.
|Local MAC Address:||00:22:6B:E8:39:98|
|System Up Time:||15 Day, 20 hour:34 min:55 sec|
I finally broke down and did the update. As Bhummel I am running in bridged mode and up for 5 days so far with no outages. Usually does its thing over the weekend or Monday but nothing today. I will post if it goes out again. Good Luck.
Hi all, I found this thread from searching for WAP4410N overheat in Google as I thought that might be the problem with my WAP4410N device(s) that keep dropping out for no known reason after 3-4 hours (but sometimes as high as 12) of operation. I have tried all the configurations known to man using 1 and two devices as AP / client, AP / WDS repeater, WDS bridges, etc., but the end result is still the same. I have tried WEP, WPA, WPA2 (the only security option I have not contemplated is none, which I refuse to even try). My topology consists of two wired networks, bridged using the wireless. In an ideal world the second device would also act as an AP to extend the wireless range but I am currently running one 4410 as an AP and a D-link wireless client in my latest attempt to resolve the problem.
I have a backup storage device at one end of the topology and the main servers and main storage at the other end - when the backup runs and the throughput increases (increased load on the wireless network); BANG, the 4410 just stops responding. All the lights are still on but they are steady (not flashing), which is not surprising as there is no traffic going through the device.
I have recently relocated the 4410 (as much as possible) to move it away from the servers, which are a heat source, and to attempt to determine if it is an overheating problem. I will report back on this when I can.
I am not a wireless novice having implemented networks large and small but this one has got me stumped. CISCO, I need help!!!
You should have read the whole thread.
Just upgrade your firmware. Then write back in 4 days and let us know if it fixed your problem. Firmware 220.127.116.11 fixed mine and I had the EXACT same problem. I have been up for 17 days now.
|Local MAC Address:||00:22:6B:E8:39:98|
|System Up Time:||17 Day, 18 hour:13 min:12 sec|
Thanks, I did read the whole thread and if you looked at my post you would see that the unit shipped with the 18.104.22.168 firmware already on it. I am running in AP mode as was pointed out earlier. Those that have had success to this point are running in Bridge mode.
Try re-flashing with the 22.214.171.124 firmware on Cisco's site. I wouldn't put it past them to have multiple versions with the same firmware Rev #.
The software here absolutely fixed my problems and mine were identical to yours.
Funny I thought the same thing after posting. We will see, now i just have to get the teacher to leave the freakn laptop on.
Testing one here in our office the connection was dropped. Just reflashed the fw ill let you knwo what happens
I was thinking the same thing as well.
Someone posted flashing instructions that included a soft or hardware reset along with it. In the interest of consistency, recommend following the same procedure.
So it appears the bridging problem is solved but not the AP problem. I take it you are only using the devices as APs?
Still no word from a Cisco representative. I guess theyr'e not watching the thread any longer.
Since this was (is?) my thread, I thought Id chime in here....
Yes Im still here and am having the issue. I cant make the problem occur at will but I now can get it to happen within a few hours. Ive been quiet for a while now because Ive been working with Cisco outside of the forum and it was getting tedious posting "it failed again" to the thread. They dont have a resolution (yet) but I do believe they are making good progress.
For the 2.x firmware, Im fairly certain that there really is only that 1 release we all now have.
Well, all my Cisco WAP4410N's are working great now. So I am outta here!
See you next time when Cisco screws up something else.
That is good news, and, thank you for the update.
I don't understand why someone from Cisco couldn't post that.
Could you please post a weekly update? Hopefully the next update will be that it's fixed and then we just have to wait for the official release. If we can't depend on the vendor at least we can depend on the community.
As mentioned before, Ive been working with Cisco outside of this forum on the problem and its time for another update:
Last Ive heard, they are working on a true fix but for now I have a workaround for my specific environment. Specifically, I have the WAP4410N access point and a SGE2000P Linksys switch (126.96.36.199 firmware). The supplied recommendation was to turn off autogenotiation entirely. Not leaving well enough alone, I found that if I set the switch to autonegotiate to *only* 1000F the problem still occurs but it isnt nearly as bad as normal. When set to autonegotiate at *only* 100F I have not been able to cause the problem to occur.
Please remember that YMMV but on your switch, If your having the problem, try turning off auto negotiate and hardcode the port to 100F. Unfortunately, I dont have any suggestions for unmanaged switches
hope this helps
Can I ask everyone Has anyone checked your power supply? I'm talking about the good old commercial power form your local power company or being delivered via POE.
I have one of these installed in my Home Office and had the 'hanging' problem very frequently till I confirmed we were having Power fluctuations/blinks. I switch mine to be directly connected to a small UPS about 3 months ago and haven't had one hang since.
It appears that these units are extremely sensitive to power fluctuations.
Hi all, I thought that I would share my findings with you in regards to this issue. In my case it appears that the unit was overheating - since moving it away from sources of heat it has been operating very well as a WDS AP (not just a bridge). I still get the occasional drop out but the network resumes almost immediately whereas before once it dropped out it stayed that way until the unit was rebooted.
I have informed Cisco of my findings and also let them know that this isn't the first time I have come across a Linksys device that it particularly susceptible to heat.
Hope that this gives you something extra to play with in your troubleshooting!!
I appear to have the same problem that you have been having. I set the AP's port on the switch to 10GF instead of auto-negotiate. I thought this would fix the problem given the behavior I've been seeing in the unit and the solution I've been using up until this point.
AP loses connection to LAN. Clients can still connect to AP, but cannot communicate with the LAN. Network clients connected to the LAN via ethernet on other parts of the network cannot connect to AP's management interface on LAN. Switch indicates that the AP's LAN port is down.
SOLUTION (WORK AROUND)
AP does not need to be power cycled. Unplug the LAN cable and then plug it back in. AP is able to communicate with LAN again immediately. This solution works consistently.
It appears that /something/ in the AP brings the switch's port down so that the switch thinks that nothing is connected. Unplugging the AP's ethernet cable and plugging it back in breaks whatever loop the AP's software is trapped in.
I'm connected to a GS724T smart switch over cat5e. Our old AP points did not have this problem.
I'd be happy to work with Cisco, too, if they need another Guinea Pig. Hope this helps.