We have been using the Motorola 5.7 Backhauls for over two years now, however, we have had issues with lossing the ability to log into the units via web interface. We have upgraded the radios and tried all versions of the newer firmware. I see in the manual that Motorola recognizes the problem but does not have a fix for it. They recommend telneting to the unit and resetting it. This does work, however, it takes allot of customers down when we do this. Has anyone else had this problem, and if so, have they figured out what we are doing wrong to cause this problem. This effects all 90 of the backhauls that we have deployed.
We have the same problem, and haven’t resolved it yet. Our distributor recommends setting a low arp timeout but to me that doesn’t really make sense. We’ve done it and that didn’t fix anything. Even though these units only take 60 seconds to reboot, to me it’s a major bug.
I agree, you would think that motorola would be able to figure out this problem
since it has been going on for the last two years. I’m not knocking motorola however, they put allot of hipe into their radios but don’t fix the problems that would keep people coming back to buy their equipment. Makes you wonder if they know what they are doing.
I took the certification class in Reno last year and asked when this would be fixed to the Engineer who was teaching the class, Mike Diliberto. He would only say that they are working on the problem.
I emailed the tech department two months ago and they said they are working on it. MOTOROLA, IF YOU ARE READING THIS, WE ARE TIRED OF WAITING!!! We have some high profile clients like Paypal who want answers immediately when there is a problem. I don’t like having to reboot the unit just to look inside via the web interface, it takes the entire network down for at least 45 seconds.
I think the problem lies in how the unit wants to log in. You have no options on setting the user name only the password. It appears that sometimes the unit gets confused as to whether you are logging in read mode or write mode.
We have tried down grading firmware with no avail and also changing the low arp timeout. STILL NOTHING! Maybe Motorola should give us all credit or lower the unit prices since they are selling defective units. Bad PR kills!
We’ve been experiencing the same problems here. When you are working on several different units, it can become terrifically time-consuming and frustrating when you are forced to keep rebooting everything even after the radio has supposedly already rebooted. :x
I couldn’t agree more. I’ve contacted Motorola a number of times regarding this issue. Their only solution is to put the radios in a private IP space. The solution is complety unacceptable since we are monitoring from our NOC and the devices need to be routable from the public space. We’ve gone back and forth with Motorola and at this point there is no ETA on a solution. Again this is UNACCEPTABLE!!!
:x
Well I have been working on one home for 3 hours, most of that time is spent TRYING TO GET INTO THE DAM RADIOS. IT NEEDS TO BE FIXED NOW!!!
What are the exact setups/layouts of your network, including all BH’s, AP’s, SM’s, and NOC equipment. I had a similar problem, not with any of the Canopy radios, but with customer routers and I was able to fix it.
In fact, i think the problem is not solved with private ip space, 'cos i firewalled the units, so inly the monitoring PC and my proxy can access it. I think until they cannot solve the problem, we have to have a command in telnet interface, where we can restart the http server (like killall/httpd)
i think it does cost about few minutes to the programmer, and than we can access the unit at least.
I asked if they had such command a while ago. That answer was no.
I agree that such a command is needed until Motorola fixes the bug. We can avoid resetting the entire radio if we had a way of resetting the http deamon.
dellis14 wrote: :x
Well I have been working on one home for 3 hours, most of that time is spent TRYING TO GET INTO THE DAM RADIOS. IT NEEDS TO BE FIXED NOW!!!!!!!!!!
I spent at least 6 hours one day on an install, and I bet 2 hours of that time was taken up by this problem.
I feel your pain.
Considering we are going to be purchasing quite soon, this issue really concerns me!
Sure would be nice if Motorola would address this!
We have found similar problems and rebooting the radio doesn’t always fix it. We only use private ip’s so the answer about the public ip’s is bogus.
I has happened with all units, no just 5.7 backhaul. Very frustrating 
We too had this problem in the beginning with the units. we have seemed to fix the problem. What we did to fix the problem is that so many outside virus’s and things were trying to infect the web interface. One we started to block some of the common ones our lockup problem has gone away.
This may not help some of you but just trying to help out.
Here is what we think is going on.
The ARP timeout on the router is longer than the ARP timeout on the radio. The radios time out and drop off the network.
On Sunday we are going to change the timeout on the router to 500 minutes and all the radios will stay at 1000 minutes. If our theory is right, the router will time out and issue and ARP request. The radios will reply and re-update the router ARP table.
If it does not work then I’ll try to think up another theory. This has really been a hair puller. Frankly I am very surprised that Motorola has allowed this to continue for two years.
For what it’s worth, usually if we can web into the AP, we can select the radio LUID web into it that way. Doesn’t always work though. Sometimes the whole network is hosed and I have to start at my Master BH, reset it, then telnet to the BH slave, reset it, then the AP, etc, etc.
We are a pretty smart bunch O Geeks, we ought to be able to get this resolved fellas.
Jerry Richardson
airCloud Communications
Jerry Richardson wrote: Here is what we think is going on.
The ARP timeout on the router is longer than the ARP timeout on the radio. The radios time out and drop off the network.
That does not quite make sence to me. If it is an ARP issue then no traffic would get routed to the radio, not just web/80. My AP is currently not allowing me to web into it, yet it is passing traffic to the SMs. I can ping it, I can telnet into it, and my SNMP polls are returning valad data.
If the issue were routing/ARP table related then (IMHO) no traffic would be routed to the radio.
It seems to me that this is a problem with the webserver daemon running in the radio. It appears that the radios are running some kind of (heavily modified) Unix kernel. Its a shame that the shell does not have more functionallity...
/usr/init.d/httpd restart
Wouldn't that be nice....
Interesting that you can telnet and ping. Generally we have to telenet tot he AP, then telnet to the SU and restart it that way.
we are so desperate we are trying anything and everything - no success yet.
Jerry
:roll: One thing I have found out about this issue. It began occurring as soon as I started using a “display only” password. Prior to setting this password I did not have the problem. I hope this helps someone figure out the source of the issue.
Also, as someone mentioned above, It would be very helpful if Motorola could provide us with the information needed to restart the http process, or maybe the password process.
How does one list the processes that are running in order to effectively use the kill command? What command would then restart the process? Can someone help us with this information? We cannot continue to aggravate our customers with resets.
Thanks.
This is quite amusing and very concerning at the same time. I have just finished setting up a tower site that has taken me months to get approved and going. All I have to do is finish setting up the units, guess what… I now have this exact problem. It away from my internal network and I need to do either of two things:
1. Set the units with public IP addy’s but then I have the problem that you all are speaking about. motorola has informed me that its because of viruses attacking the web interface, which to me sounded rediculus. But this is looking more and more like the situation that is most unattractive.
2. Is to set them to private IP’s and set up routes between the two routers, which I have no problem doing, but that has not worked either. Now I read and hear that my ARP timeouts are not configured properly!
This simple process of setting up another site separate from my network has turned into a friggin nightmare. And if I cant do it I gurantee my until now impressed opinion of Canopy is about to change. Finding out this is a two year old problem that no one from motorola is addressing makles me quite concerned. Even a well addressed post in here would suffice.
You have had input from what seems to be the techy’s in the business here is an opinion from a business perspective. This needs to be fixed, if it not then Ill tell you right now you will lose business and fast. This has cost me a few thousand dollars already and if I have to redesign my network how I think I have to I will be quite upset.
Are you sure it was wise to start these forums? 
It would be nice if Motorola posted a response or an update to this subject. We need to get some feedback to this issue. I was very dissapointed that the bug fix was not in the latest release.
I am ready to start entertaining another vendor due to this.
Along the same lines I believe there should be a command in the telnet interface to control every feature that is controllable by the web interface. This would allow for easy scripting of system wide changes.
I have had similar issues with the backhauls before and AP’s that sit behind SM’s.
Our BH’s and AP’s are all private IP’s. Everytime I have seen this issue I have been able to telnet to the device (which appears to reset the arp entry) and then access the web interface. I have not been required to reset the device.
I would like to keep up DNS entries for all devices, which may be a fix for this. But we currently use windows DNS servers and I cannot script that to keep those up to date and doing it by hand seems pointless.