All,
I’ve been experiencing an interesting issue and I want to see if the community is also seeing something similar.
I’ve been in the process of upgrading our Moto SMs, APs and BHs from 8.2.2 to 8.2.4 per the recommendation of a regional Motorola technical manager.
The upgrades have been performed in the newest version of CNUT and the upgrades themselves have been going fine. The problem is what happens after the upgrades. I’m seeing that on some of the APs the IPs that are assigned to the SMs will timeout in the ARP table, causing what looks like a broken connection in Nagios and an SNMP error in CNUT. The IPs refresh in the ARP table after a manual reset of the AP or the SM, but then they timeout once again.
Is there anyone else who is seeing this problem? It is also totally intermittent, so I can’t track down the exact circumstances that make it happen. It does look like an AP with 8.2.4 and SMs that are a mix of 8.2.2 and 8.2.4 cause this issue - but that’s the closest that I have to reproducing this error.
-Mike
Recently posted a trouble ticket with Motorola…
After a phone conversation with support where they informed me that upgrading to 8.2.4 would correct the issue.
My request is as follows…
Having issues with the 900MHz solution
We have upgraded all 900MHz AP’s to v8.2.4
All SM’s are at v8.2.4
SM’s are configured for NAT.
Symptoms are; they loose the ability to access DNS servers on the public
network.
They have the ability to ping the private addresses on the system, yet not
the DNS servers on the public side.
Re-booting the SM corrects the issue for a period of time.
All SM’s are NAT’ed by default, we assign a private address in NAT “Radio
Public Interface Configuration” for management puposes using Prizm/BAM 3.1,
DHCP assigns a private address to the “NAT Public Interface”, the DHCP
Generic Parameters are set as … DHCP Client and DHCP Server to "Enabled"
Setting DNS Server Parameters to “Set Manually” or “Obtain Automatically”
makes no difference.
When setting “DHCP Generic Parameters” DHCP Client too “Disabled” then
assigning a Private address in "NAT Public Network Interface Configuration"
Makes no difference with the issue of loosing its ability to maintain
connection.
However — Assigning a Publicly addressable address in “NAT Public Network
Interface Configuration” does seem to work around the problem.
Note that Public addresses are a commodity here, and I have never had this
kind of issue in the past.
The reply is as follows…
Sir -
This is a known issue. The advised work-around is to turn off NAT. This
issue is being addressed and should be resolved in the next firmware
release.
Thanks,
Motorola Canopy Technical Support
I replied for information pertaining to an ETA for PR purposes, only to be told to watch the Software Download page…
~~~~~~~~~~~
But I have found that assigning a Public IP to “NAT Public Network
Interface Configuration” does seem to work around the problem.
Turning OFF NAT would require me suggesting the client purchase an in house Router… :evil: