Fair enough. We don’t manually input the DNS into the radios to give us the flexibility of control over the SM’s DNS without having to mass edit in the future. Albeit we haven’t changed DNS server IP in several years, but in the off chance something needs to be put up temporarily, we’d like to be prepared.
I did notice changing a couple of SM’s to DNS Proxy enabled worked out well for the customers affected. It didn’t seem to be everyone but we had several. Disabled appears to be the default method when upgrading the firmware but I hadn’t been through enough SM’s prior to the rollback (where in I checked this particular setting) to confirm. It was still pretty unsettling to see the decrease in modulation. Considering that the total throughput available on the AP is based on the modulation rate of the SM’s (we aspire to at least maintain a minimum of 8x/4x per SM), it’s disappointing to see the behavior of the radios as they were after the upgrade. We had a few SM’s that went from 8x/4x to 8x/2x, even a couple of 8x/6x that dropped lower. -Tim PS – OT, I hope everyone had a happy turkey-day and has hopefully avoided a good chunk of the BF shenanigans From: Af [mailto:[email protected]] On Behalf Of Bill Prince via Af Sent: Wednesday, November 26, 2014 6:35 PM To: [email protected] Subject: Re: [AFMUG] Cambium 450 13.2 issues We do similar and are not seeing any issues on 13.2. When our SMs are in NAT mode, they get the DNS servers from their DHCP server, and propagate the DNS server addresses to their clients. I have not seen one instance of this not working; and we have quite a few on 13.2 now. Likewise, we also upgraded the SMs first, then the APs. Works as advertised. -- bp <part {dash} 15 {at} SkylineBroadbandService {dot} com> On 11/26/2014 4:57 PM, Ken Hohhof via Af wrote: It’s a choice you make, do you want the SM to hand its own address out via DHCP and act as the DNS server, or do you want the SM to hand out your DNS server IP addresses via DHCP? We do the latter, and manually enter those DNS server addresses into the SM. Most of our residential customers have their own WiFi router behind the SM, this way it gets handed our DNS server addresses and probably acts as a DNS proxy itself. But that is just our preferred way of setting it up. I don’t believe any of this has changed since many FW versions ago on PMP100. The reason I asked was, if you are disabling DNS proxy on the SM, then you are using the same configuration we are and I am surprised that 13.2 broke it for you. If you are enabling DNS proxy, I don’t think we do that anywhere, so I would be unaware if 13.2 broke it. From: Timothy D. McNabb via Af<mailto:[email protected]> Sent: Wednesday, November 26, 2014 6:27 PM To: [email protected]<mailto:[email protected]> Subject: Re: [AFMUG] Cambium 450 13.2 issues It’s set to the default upon flashing, which appears to be disabled. TBH if it is something that should be enabled, then it should have been by default with the release IMHO. -Tim From: Af [mailto:[email protected]] On Behalf Of Ken Hohhof via Af Sent: Wednesday, November 26, 2014 4:18 PM To: [email protected]<mailto:[email protected]> Subject: Re: [AFMUG] Cambium 450 13.2 issues You have DNS Server Proxy enabled or disabled on the SM? From: Timothy D. McNabb via Af<mailto:[email protected]> Sent: Wednesday, November 26, 2014 6:09 PM To: [email protected]<mailto:[email protected]> Subject: [AFMUG] Cambium 450 13.2 issues We’ve seen a few issues with the new 13.2 firmware for the 5.4/5.7 450 equipment. Here is the bucket list – · If an AP is on 13.2, but an SM is on 13.1.3, there is the possibility that the SM cannot update because it is stuck in 8x/1x mode and throughput is significantly decreased. Manually going to the customer site and updating can bring the radio back up · In some cases, SM’s after the update come back online with a better signal but a decreased throughput and modulation rate than what was previously viewed on 13.1.3 · Behind a NAT’d SM, it does not appear that DNS is being properly passed by the SM to a customer’s router. Manually setting the customers router to our DNS servers (instead of relying on the NAT’d IP address) appears to resolve the issue. Manually setting the DNS IP address to the NAT’d SM’s IP does not resolve the issue. We have since rolled back from 13.2 to 13.1.3 which was stable with our particular network configuration. I have no intention of rolling forward to 13.2 again for Cambium testing purposes (sorry guys) however I would be able to answer any specific details to our configuration if it is helpful. Timothy McNabb Network Administrator Velociter Wireless, Inc (209)838-1221 x107
