P10 Lite SMs enabled for NAT and DHCP server can lose calibration data and become inoperable (pg32 of the release notes).
According to the release notes this can exist in any 8.x release and has not been seen with Windows PCs attached. I can confirm that Windows PCs will cause this loss of calibration data.
We had a customer’s SM do this yesterday. Connected PC was an older Gateway running Windows XP. Required a truck roll to fix - I haven’t replaced the SM yet as I was able to make it work again by inserting the default plug, resetting to defaults and reconfiguring. The power levels are definitely useless though. Will be replacing this SM sometime in the next few days.
Just thought I would let you all know that it is yet another thing you may have to watch out for with the 8.x software. This subscriber has been running at least 8.1.5.1 since release (they’ve been installed for over a year) and hadn’t had an issue until now, so I’m inclined to believe it may be more of a likelihood in 8.2.4 as they were only upgraded to that software about 3 weeks ago.
Man, this is a serious bug! We upgraded 88 5.2 lite modules to 8.2.4. Now they are dropping like flies in a RAID factory. In the last week, we have had to replace 13 modules that LOST their power level calibration. This situation has us really stressed, and we don’t know if we should drop to another fw and risk the other major bug that was biting us (dropped ethernet connections).
What would you do?
Does this only affect Lite SMs?
Yappa, Do you have the option of downgrading to 7.3.6?
I have yet to see the issue on any other release other than 8.2.4 - we’ve ran 8.1.5 on everything (including many P10s) for a long, long time and never had any problems like this happen. My advice would be stick with 8.1.5 on P10 lites until they actually fix it.
pcpolo - this bug should only affect lite units. Mine in particular are 2.4GHz lites.
Hello all,
Unfortunately P10s cannot downgrade to 7.3.6 (if it can, I would love to know how)
This bug seems to very specifically meet the criteria described above: Lite series, DHCP and NAT enabled ANY machine, windows based or not. Apparently this is not user serviceable, as my calls to tech support (actually productive this time) resulted in a statement to RMA all affected units. Yikes. Fortunately I had just bought another box of 25 so I had spares to replace these, but that was a rare occurance. I just hope a resolution is found other than: don’t use NAT/DHCP, because I still have over 70 still in operation.
I agree about 8.1.51 being a less problematic release, but we had probs with some users losing Ethernet connectivity. Of course this problem paled in comparison to losing RF functionality.
Indeed - it’s much easier to have the subscriber power cycle their radio to restore connectivity than having to schedule a truck roll to replace the affected unit.
We just upgraded around 80 customer radios last week, and were about to implement NAT / DHCP. Oh well, guess not now. We’ve been running Canopy gear for over three years now, and it seems Motorola software is stuck on a steady downhill slide. They need to get their crap together, or sell off the Canopy portion to someone who can run it properly. We pride ourselves in uptime, and response time to trouble calls.
Yeah - after coming off of inferior gear (smartBridges and Tranzeo) we’ve worked very hard over the last couple years to get our uptime right up there with the DSL and cable providers.
With software issues like this and the new software being shoved down our throats I have to wonder how much longer we’ll be able to keep using Canopy before it becomes an inferior product as well.
I can understand some hardware issues from time to time, but the software is the one thing that makes the Canopy platform work so well. It is the absolute last component of the wireless system that should have any issues. Can you imagine where Qwest or Comcast would be right now if the software on their modems causes issues like this?
Well, it gets worse I’m sorry to say. Now we are seeing P10 900Mhz radios drop out intermittenly with no good reason as to why. One of the radios is roughly a quarter mile away from it’s AP. When we were running P9 gear with 7.3.6 FW there were no issues and our network was rock solid. Once P10 gear starting showing up it’s been getting worse ever since. If it were up to me, I’d unload all the substandard equipment on ebay and switch to another manufacturer. I have no idea how we are supposed to keep our customers happy when we can’t even keep our guys happy with the gear.
This last post seems pretty extreme, is anyone else seeing issues like this?
I haven’t seen anything like described on my 900 gear. Other than NAT issues and the newly experienced loss of calibration issue, my Canopy gear is pretty solid.
I havn’t been having any problems with 900mhz radios.
However I have had 4 p10 5.2 AP’s crash since January (all purchased in Dec.)(not related to 8.2.4).
FWIW I have well over 100 900MHz SM’s (roughly half are P10) in the field and have zero issues w/ 8.2.4. Then again I have NAT disabled.
We are not running NAT or DHCP either. Like I said above…we were planning to deploy it in the near future, but now are having second thoughts.
Most of our problems with Canopy gear stems from NAT related issues. I would certainly recommend that if things are running smoothly, stay away from it until we know they have the problems resolved.
For the region code, has it changed where if you don’t have it set in 8.2.2, then upgrade to 8.2.4, will it be a problem?
I don’t use any modules in frequency bands that require it set so I am not sure on that one.
My $0.02 worth…
I’m running about 300 SMs on 8.2.4 and NOT doing NAT or DHCP, and haven’t had a single problem with any of them.
[soapbox ON]
We are dealing with wireless bridge radios here. These are not designed to be NAT devices or routers. These are not designed to be DHCP servers. Quit expecting this device to be the be-all and end-all solution. Put a (Linksys/DLink/Netgear/yourchoice) device behind the ethernet port of the radio and let that purpose-designed device take care of what happens inside the end-customer network. If you want to assign addresses to those end-customer firewalls/routers/whatever, set up a DHCP server on Linux/BSD/Windows and let that device do what it is designed.
[soapbox OFF]
Yes, that was a little harsh, but again I ask you to remember what type of device you are dealing with and what you are asking it to do. Shame on Canopy for touting those features as a selling point. If you want a reliable network, use equipment that is designed to fill their certain functions, and not all that additional stuff above and beyond their original design.
I completely disagree with you. If the device claims it can do NAT/DHCP than it damn well better be able to do it, otherwise it shouldn’t be advertised as a feature.
My NAT deployments are always simple - one computer behind the radio. I like to give my customer an extra buffer from the internet. If they add more computers to their home network in the future, they purchase a router and we put the radio in bridge mode. I don’t think that is an unreasonable expectation from the Canopy equipment - especially since it worked just fine in 7.3 (granted port forwarding didn’t work - but I’m not using that anyway).
I can appreciate your point of view, but it’s already pretty tough making it as a WISP with the equipment costs we have to take a hit on in order to gain subscribers. I don’t think it’s reasonable to expect me to eat another $30-$50 so that I can have a basic NAT implementation that works.