We recently invested in the acess point demo system. Everything has been setup for about a month and seems to be working nicely, however the access point has shown some signs of a problem.
About every 2 - 3 weeks, the access point goes into a zombie state and can no longer load up the administrator webpage by going to the IP address.
The entire network continues to operate though, just that webpage seems to be non-functional.
Has anyone else observed this problem?
-Nathan Books
Snare Systems
www.snaresystems.com
Oh yeah, it is a known bug that Moto has been promising a fix for since we bought canopynearly a year ago. It does seem to be worse with public ip’s.
The only way to get back in is telnet to the unit. the name is root then the password then reset.
I have 10 ap’s and can’t get into any of them most days.
I too noticed this same problem but only when I gave our access points public IPs. I noticed that the access points would actually reboot themselves every few hours or so. As soon as I put them back to Net-192 non-routable addresses, everything was fine. But again, the whole network remained functional during these periods.
i had the same problem, and it was not only APs, but ALL canopy units with a public IP. since changing our entire system to private IPs i have not seen the problem at all. i was told that the Canopy team is aware of the problem and working to fix it, but with private IPs it’s not really an issue, and, honestly, private IPs is your best idea for a network configuration.
I have several APs that while passing traffic are nonresponsive to http/telnet/ping/snmp requests. They are all in the 10.0.x.x IP address range. Rebooting them sometimes corrects the issue and some times they just start responding… other times not.
May it will get better in 6.1
I used to have that problem all the time. It seems a few things helped me out. I did what the above have done, have the modules set to non-routable IP addresses. Also made sure they are all running up to date firmware. But another thing I had a canopy tech tell me is to set the Bridge Entry Timeout to greater than default. In fact, I set all mine to the max, 1440. I know that you are supposed to set that higher than what your router is set, and I think Cisco routers are defaulted at 30 min timeout, I could be wrong. Since doing all of these things, I have no problem getting into any of my gear.
I have to agree with the posters who have switched over to private IP’s. The biggest problems we had were when we left some units with default IP’s. Once we got everything switched over to our private network IP addressing, we have had MUCH less problems with this.
same problem here…
Never been able to get canopy to admit to it, that there is a problem in their OS.
They kept pointing at our network, check this check that. I know my network is JUST FINE!
I gave up and told them that they will soon discover there is a problem with their software when other customers call in, I hung up.
ghull wrote: I used to have that problem all the time. It seems a few things helped me out. I did what the above have done, have the modules set to non-routable IP addresses. Also made sure they are all running up to date firmware. But another thing I had a canopy tech tell me is to set the Bridge Entry Timeout to greater than default. In fact, I set all mine to the max, 1440. I know that you are supposed to set that higher than what your router is set, and I think Cisco routers are defaulted at 30 min timeout, I could be wrong. Since doing all of these things, I have no problem getting into any of my gear.
Our network is all AES stuff with the exception of two SM units. It's these two DES units that keep losing HTTP access. After setting the Bridge Timeout to 1440, no more issues. It's been almost a month since I made that change and all is well.
AS a precaution, I went ahead and set all of my AES units to 1440 as well.
Dan
I to had this problem with the canopy, we have fixed this issue and no longer get lock up’s or the http stop responding. I had created a script in our firewall rule to block all access to the ap’s except trusted ip address’s And to this date have not been locked out of the interface. It has been alot to magage but it beats haaveing to reset the unit from telnet all the time.