![]() ![]() For this reason we are also looking into alternatives. The VoIP issue is something that Motorola has built in not being able to handle more than 8 to 10 simultaneous calls per AP. 2 of the BH units have public adresses and it is a matter of hours untill they get blocked (constant 6MB up and 3MB down on a 20MB unit) there is no remote access to the AP´s and BH from remote sites because of the private addressing so it is the local web access that get´s blocked. ![]() we have SNMP enabled (but have also disabled it with no change) the time till we cannot log in is now arround 2 days max for high usage AP´s and BH units and 1 to 2 weeks for low usage units ( not dependant on number of SM it is really related to high or low throughput) it is usually the high usage AP´s and BH that present this problem Here we go again - I do´nt believe it´s going to solve the problem but…: Of course the http interface wouldn’t even be required if the CLI offered more unhidden functionality. Perhaps Motorola should waste some flash space, and use Apache or Tux - known working httpd services. I can generate a few packet logs for analysis. If you’d like some tcpdump output, ask me. It is very obvious to me, that the httpd software in the Canopy unit is failing. Port 80 (http) packets go through, but the connection is FINished before any data is returned. A misconfigured firewall could block, but that effect would remain past rebooting your AP. Its not possible for this symptom to be caused by a network configuration or reachability problem - ping and telnet still functions. In addition, all our AP have always been assigned private 172 addresses, and I have added filtering at our routers so that only our internal management stations have access. Our bridge tables are set at 360 minutes (6 hours), while the ARP ageing at our router is 4 hours (Cisco default). I have tried all the mentioned configurable workarounds. This problem cluster has gotten WORSE since we updated the network 6.1 (software scheduler). The worst cluster of 4 AP requires a daily reboot, and all 4 stop working at different times over the course of the next 24 hours. We need an urgent solution to this problem because everytime we want to add an SM, we need to reset the AP which obviously affects all the rest of the customers in a sector. All units that we use are DES and synchronized via CMM and CMM-Micro´s. We have upgraded all units to 4.23 and Boot 3.0 and fpga 062403. The BH with high traffic loose the capability of being managed within a very short time (less than a day, sometimes less than an hour). We have noticed that this issue usually occurs in AP´s and BH´s that have a high constant traffic load, but for some or other reason this has also happened in AP´s that do not have much traffic at all but it takes a lot longer after a reset for the low traffic AP´s to stop reacting to the WEB administration. The only way to recover is to reset the devices via Telnet …but this causes havoc in the network due to the bridge timeout issues etc etc etc so that we need an urgent solution for this problem. We are having extreme trouble in the administration of our Canopy network due to the fact that without apparent reason the Web page of certain AP´s and BH units just stops reacting.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |