+1! My methodology as well. Upgraded one sector to 5.5.10 and all was well. Next, did whole tower, then started getting weird lag & speed issues. Downgraded to 5.5.8 - issues went away. Tried other towers - same thing. Strange!
On Tue, Oct 28, 2014 at 12:13 PM, Justin Wilson <[email protected]> wrote: > Here is my take on upgrades. Everyone has their own little philosophy but > here is my SOP. > > 1.Wait a version unless you have a specific need. By waiting a version > you can read the change logs and see what things were fixed in the previous > version. This gives you a lot of insight as what to expect when you upgrade > to that version. Changelogs aren't end all but give an idea. > > 2.The more your devices do, the more they can have problems. I am a huge > fan of modular components. My Access Points are just dumb bridges. They > don't do routing, they don't do NAT, they just do wireless stuff. Routers > are separated into different functions. This is a huge deal. Just about > everything out there is *nix based. This means these different functions > are services running. A service can have a bug and cause crashes, memory > leaks, all kinds of things. The more stuff you layer the more things can go > wrong. > > 3.If you are talking wireless and you are ready to pull the trigger on an > upgrade do a whole sector at once. Don't mix and match on an AP. Upgrade > the AP and all the clients. A major reason a company needs a good > management tool. I want to mass upgrade all the clients on a single ap and > get the AP and all the clients at the same level. Mixing and matching can > cause issues. > > Justin > -- > Justin Wilson <[email protected]> > http://www.mtin.net <http://www.mtin.net/blog> > Managed Services - xISP Solutions - Data Centers > http://www.thebrotherswisp.com > Podcast about xISP topics > http://www.midwest-ix.com > Peering - Transit - Internet Exchange > > > From: Steve Barnes <[email protected]> > Reply-To: Ubiquiti Users Group <[email protected]> > Date: Tuesday, October 28, 2014 at 10:17 AM > To: Ubiquiti Users Group <[email protected]> > > Subject: Re: [Ubnt_users] PSA: Ubnt XM v5.5.10 major bug -- recommend > using v5.5.8 -- STA scan-list empty, cannot connect to AP > > +1 We have upgraded 750 CPE's and AP's and have had no issue. Actually > helped other issues. > > > > *Steven Barnes* > > GM > > PCSWIN.com > > Howard LLC. > > > > *From:* [email protected] [mailto:[email protected] > <[email protected]>] *On Behalf Of *Daniel Peoples > *Sent:* Tuesday, October 28, 2014 9:56 AM > *To:* Ubiquiti Users Group > *Subject:* Re: [Ubnt_users] PSA: Ubnt XM v5.5.10 major bug -- recommend > using v5.5.8 -- STA scan-list empty, cannot connect to AP > > > > I have 5.5.10 running on both xm and xw and have had absolutely no ill > affects. In both CPE and tower to tower backhauls with beams, bridges, and > rockets. Moving from 5.5.4 and 5.5.8 to 5.5.10 I have never had an issue. > Ofcourse, I always reboot prior to firmware update, then after firmware > update. Cover your bases and no truckrolls shall befall you. > > > *Daniel Peoples* > Resonance Broadband > > *Resonancebroadband.com* <http://Resonancebroadband.com> > 918-429-3620 > > > > On Tue, Oct 28, 2014 at 8:15 AM, Josh Luthman <[email protected]> > wrote: > > Looks like the command can't handle so many frequencies, 5.5.10 exceeded > the size. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Oct 28, 2014 9:05 AM, "Matt Hoppes" <[email protected]> wrote: > > You know there were no changes made to XM v5.5.10 other than adding new > frequencies, right? > > On 10/27/14, 8:57 PM, Colin Zwiebel wrote: > > We are having serious problems with v5.5.10 with 5GHz XM hardware and > > have decided this firmware is not production ready. We using *v5.5.10 > > only for links that require UNII-1* frequencies and avoiding in all > > other situations. There is some sort of a bug with scanning for > > available networks, so if your area has few networks, you might observe > > different behavior. > > > > > http://community.ubnt.com/t5/Installation-Troubleshooting/v5-5-10-major-bug-no-SSIDs-in-scan-print-scanning-info-buffer/m-p/1072997#U1072997 > > > > *AirOS v5.5.10 is not production ready!* > > > > Ubiquiti, it appears you have a major bug and need to revoke the > > release, remove from website, until you get this fixed. > > > > > > > > We have now had 3 clients -- 2 Nanobridges and 1 Rocket M5 -- disconnect > > from their AP with the same behavior: NO SSIDs appear in scan list. > > Downgrade to v5.5.8, no changes to config, radio once against sees SSID > > and connects perfectly. > > > > > > > > *Workaround: Frequency Scan List* > > > > I cannot fully confirm this, but it appears, v5.5.10 plus frequency scan > > list has this problem less. It also might be that this pares down the > > amount of data coming from the atheros driver (by not scanning all > > frequencies), and scan list doesn't actually fix the issue, just reduces > > the scan data to something that doesn't break the radio. > > > > > > > > > > > > *iwlist ath0 scan -- print_scanning_info: buffer too large(65535) for > > realocating* > > > > In our most recent incident, I was able to SSH into the failed v5.5.10 > STA > > > > XM.v5.5.10# iwlist ath0 scan > > print_scanning_info: buffer too large(65535) for realocating > > > > XM.v5.5.10# wlanconfig ath0 list scan > > ioctl[unknown???]: Argument list too long > > wlanconfig: unable to get scan results > > > > > > > > We are running now with a frequency scan list (cannot downgrade this > > radio) and both iwlist and wlanconfig commands are working properly. > > > > > > > > More details: > > > > APs: Problem happens with both Nanostation M5 APs and PowerBridge-M5 APs > > > > - Seen with AP on v5.5.10 > > > > - Seen with AP on v5.5.8 > > > > STAs: Problem observed with NB-22-M5 and Rocket-M5 > > > > DFS: Problem observed on both DFS and non-DFS frequencies (5805) > > > > > > > > Most recent incident, Rocket was working fine for a few days, suddenly > > died. It rebooted in the process (only 2min uptime when I got to > > it). Let sit 10min, rebooted, made no difference, gave buffer too larger > > error no matter how many reboots. Only enabling scan list patched it. > > > > > > > > Colin > > netBlazr <http://netblazr.com/> - free your broadband! > > > > > > The wireless telegraph is not difficult to understand. The ordinary > > telegraph is like a very long cat. You pull the tail in New York, and it > > meows in Los Angeles. The wireless is the same, only without the cat. > > > > > > _______________________________________________ > > Ubnt_users mailing list > > [email protected] > > http://lists.wispa.org/mailman/listinfo/ubnt_users > > > _______________________________________________ > Ubnt_users mailing list > [email protected] > http://lists.wispa.org/mailman/listinfo/ubnt_users > > > _______________________________________________ > Ubnt_users mailing list > [email protected] > http://lists.wispa.org/mailman/listinfo/ubnt_users > > > _______________________________________________ Ubnt_users mailing list > [email protected] http://lists.wispa.org/mailman/listinfo/ubnt_users > > _______________________________________________ > Ubnt_users mailing list > [email protected] > http://lists.wispa.org/mailman/listinfo/ubnt_users > > -- -RickG KyWiFi
_______________________________________________ Ubnt_users mailing list [email protected] http://lists.wispa.org/mailman/listinfo/ubnt_users
