8.2 and NAT


Motorola claims the problems have been fixed, alas they are not. I (foolishly) upgraded my entire network to 8.2 last week and have nothing but NAT issues since - namely with customers who are using switches and NAT.

Problems range from “limited to no connectivity” to having been assigned IPs but being unable to access the internet.

Needless to say I’m stressed out and disappointed in Motorola. 7.3.6 NAT worked almost flawlessly, 8.x NAT simply doesn’t work.

I just sent 4 different logs via Technical Support tool in Prizm3 to Canopy support - hopefully they find the problem.

Only solution I’ve found at this point is to disable NAT. I’m considering rolling back to because at least the customers directly connected to the SM with NAT enabled won’t be left without access.

Anyone else ran into this or come across any solutions?

Hi Wifiguy,

I had the exact same issues and I rolled back to 7.3.6

I did get some replies on my thread that suggested that setting the Ethernet to 10 megabits instead of auto helped.

Most of my SMs are set to 10HD and 10FD - should I just be setting it to force 10FD?

When we have ethernet issues, we just set 10FD. Only having one box checked removes autonegotiation from the picture entirely.

I have the same problem with nat on version 8.2!
If you look the arp on the canopy radios, you can view a mac-addresss with 00-00-00-00-00-00 and this mac cannott ping the ethernet of canopy radio!!!
It’s a Very Very BIG PROBLEM!!!

Telnet+> arp -a

IP Address Physical Address iface pend c-time l-time 00-15-fa-9c-8c-31 rf2 N 34775 37666 00-13-20-b7-bd-bc et1 N 27761 0 00-00-00-00-00-00 et1 Y 37647 37647 00-11-11-f1-0e-10 et1 N 14232 0 00-04-23-b8-13-a9 et1 N 2478 0 00-a0-d1-a0-c0-0a et1 N 2072 20479 00-13-20-73-f7-53 et1 N 349 349 1a-00-3e-51-99-a8 rf1 N 172 37110 4c-50-42-41-43-4b lo0 N 172 177 00-13-20-96-24-d9 et1 N 233 0 00-a0-d1-a0-c0-0a et1 N 105 0

IP Address Physical Address iface pend c-time l-time
82.x.x.x 00-15-fa-9c-8c-31 NAT N 233 234

the IP it’s really and i can ping this ip from another pc!

Best regards,

Fabio Marocco

The short story on this is that at the moment if you use 8.2 you CANNOT use the NAT feature. You must handle your own NAT from your Core or else deploy a router at the client.

The SM should always be in Bridge mode.

Otherwise, stick to 7.3.6 which seems to work fine unless you need port forwarding.

Excuse me, but… where are the Motorola’s developer team???
Why this BUG it’s not resolved??
It’s possible to have version 8.2 without this problem?

Best regards…

Like others we got excited about 8.2 but being cautious by nature we only upgraded 3 APs, after much wringing of hands and fervent prayers to the networking gods we discovered that they will not lock if you hard code the ip on the client e.g NAT Private Network Interface Configurationip adress = on the sm
Then set the client ip to and the gateway to since the dhcp server will only lease up to .51 it should not cause a problem, I know its not very clean but it works and saved us having to roll back SMs and APs, and works without having to change away from autonegotiate speed and duplex, hope it helps

it will also resolve if the SM is power cycled by the customer.

Our clients were power cycling their radios 4-5x a day in some cases. I finally gave up and disabled NAT.

It should would be nice if I could find a copy of so I can roll back to that on my newer radios and on the others. The access points seem to be running smoothly, it’s just the SMs with NAT that are having the problems. Even forcing 10FD didn’t solve anything.

Just upgrade 2 cluster of 2.4 AP with 8.2 version.

First cluster is 4 Adv+ 2 non-Adv, consist of around 100+ customer from 736 majority version, and some p10 board. After upgrade the AP’s, suddenly everything seem not stable, first is where 2 non-Adv AP hang. 1 of 4 Adv AP which has 29 customer inside, suddenly showed not calibrated all in Session Page. We are restart and do anything at the AP, and suddenly everything is back to normal again. Today 1 Adv AP is hang again…

Second cluster with 6 non Adv AP, worked fine with 8.2

Any clue what happened? and what should I do?

I confirm wifiguy!


7.3.6 could be better than 8.x?

I am so glad I have not “upgraded”. I don’t need the headache.

Maybe Moto needed some actual POPs with atleast 100SMs on it, something like an actual laboratory.

But knowing this gears are understood to be always outdoor, a big ground with SMs around it could be nice.

Something like a model structure on the real WISP world. In this case they can test their firmwares before posting for Downloads.

I wonder if they even apologize for the headaches they brought.

I am always happy at 7.3.6

Apologize?! HAH! They won’t even acknowledge that there IS a problem.

I sent them some tech support data from their tool in Prizm3, unfortunately it didn’t poll the SM pages correctly. To add to the grief, it’s too late to use the CNUT2.2 version because I’ve already disabled NAT and given up on it.

We’re doing some tentative testing and having good luck. We use NAT on all radios, but we also hardcode all the addresses in the radios before they go out into the field. A select few radios on my biggest POP (just shy of 100 radios) are running 8.2v2 with the AP still on 7.3.6, and my smallest and most stable POP AP and all 12 SMs are running on 8.2v2.

So far (3 days) I can confirm that we are seeing no NAT issues, so maybe it is only in conjunction with DHCP that the problems appear…

I’ll keep you all posted on the NAT performance over time. So far, so good for us.

Just to clarify - by “hardcoding addresses” in the radios, what exactly are you referring to? The RF public address? or do you mean you statically assign the IPs on the computers after installation?

Our only use of DHCP is on the ethernet side of the radio facing the customer. All other addresses are set manually (I had a script for v7, I’m doing them by hand so far in v8).