Software Version : CANOPY 7.1.4 Apr 26 2005 11:07:45 BH-DES
Software Boot Version : CANOPYBOOT 3.0
FPGA Version : 051104
FPGA Features : Single, 40MHz ExtBus, DES, Type0
Frequency Band : 5.2GHz
Hardware Platform : 8
Hardware Minor Revision : 0
This is my first attempt to use canopy gear. I have found the web interface works after a power up, but if I leave it alone for a while, it becomes inaccessable. At first it says web page found, but nothing happens, then on subsequent tries it says can’t be reached.
The units continue to pass data, and can be pinged and telneted into. If they are rebooted from telnet, the web interface becomes available again for a little while.
The units are on public IPs if that makes any difference.
Any ideas?
Yes, there is a open issue for the HTTP lockup. The current work around is to set your IP to a private, non Internet routable address. An example would be 10.0.0.1.
Is it possible to do anything other than reboot the unit from the telnet interface to bring the http interface back on line?
I gather this is not something that is going to be fixed soon right? I’m trying to figure out of these will be suitable for my system, and not having public access for remote management would require more complex solutions I’m not sure I’m up for.
I understand that giving your infrastructure a routable address is easier however you open yourself up to every curious eye on the Internet. I would suggest that your infrastructure be on a private network. Could you possibly set up VPN access to get into your devices remotely? (I am not referring to just Canopy when I say infrastructure)
See my post about the web interface in the “Suggestion” section of this forum.
Thank you for the reply “canopy_support”. I realize there is nothing you can do but relay the facts, but reorganizing my system to allow for this would cost countless hours and many thousands of dollars. I guess I’ll have to haul these off the towers and return them. Certianly dissapointing for all involved, me in particular. My need is immediate. If there was a way to bring the units http interface back up short of rebooting the units, that would be an acceptable workaround.
Corky
Another possible solution can be filter any packet from OUTSIDE your network destination you canopy device. Probably same as using private IP
Well remember to weigh the countless hours of chasing a potential hacker snooping passwords when you log in and out of your equipment. A lot can be done to protect your environment for little investment. I wouldn’t suggest putting your infrastructure out on the net accessible by anyone.
I assume you understand that as soon as your equipment responds to a ping sweep it will be tagged as a potential target.
It may seem like it makes your life easier to assign it a real address but I don’t think it out weights the risk in the long run. Just my 2 cents.
What are you trying to use Canopy for? As an ISP bringing internet to households? Or maybe to provide needed throughput for equipment monitoring in the field? Or one of 1000 other possibilites? Its possible that Canopy is not the right product for the job you are trying to perform. But remember that if wireless security is an issue and its a high throuput link, wep can be broken very easily. For information on how to test the security of your wep key check out: http://www.tomsnetworking.com/Sections-article118.php.
Having nearly 500 units in the field, and growing daily, as an ISP it is very important that the access page for each and ever Canopy SM/AP/BH is not public accessable. The units are very easy to compromise using brute force password crackers on, especially since there will be multiple target units and the safe assumption is that every unit will have the same password. If you were ever compromised that few thousand dollars and time to redesign now would look like pennies by comparison.
Also, there are a very limited number of alternatives to the Canopy product that are not a supped up 802.11x product. And of those alternatives, I have yet to see one that comes close to the robustness, quality of link, and value of the Canopy product. Eventhough the Canopy has problems with http interface lockups, HWS issues, and rereg’s, there are available work arounds.
I am not trying to be a fanboi of the canopy, just stating what I have experienced. In addition to the Canopy we have dlink, netgear, cisco, senao, and raylink(well we did until the last unit died recently) products in place also. Most suit their need much better than Canopy.
Please describe for us your network and your requirements for remote management, both the physical layout and the IP addressing structure. There may be some relatively simple – while maybe not ideal – solutions to your dilemma.
I agree with you that it’s frustrating the problem hasn’t been fixed. But I also agree with Motorola that, if possible, the management of a network’s infrastructure should be hidden from the general public.
(As Tevya says, in turn, to two men in disagreement: “You are correct”, and “You are also correct.” Any alert readers out there who know the retort and response that follow?)
wpeople wrote: Another possible solution can be filter any packet from OUTSIDE your network destination you canopy device. Probably same as using private IP
Great idea, it has been working flawlessly for me. I have the Canopy equipment all on public IPs but set an ACL in the router so that only spesfic subnets (the one's we control) can connect to the equipment.
We have had over 2 months of uptime on the Moto gear w/o a single web interface lockout.
mattmann72 wrote: http://www.tomsnetworking.com/Sections-article118.php.
A very interesting read, thanks! :)