Not to say this isn't an issue, but are you even able to use those frequencies if there are that many APs around?
> On Nov 3, 2014, at 5:46 PM, Colin Zwiebel <[email protected]> wrote: > > This is correct. I titled the thread wrong, instead of "Major Bug in v5.5.10" > should have been "Major Bug in all v5.5." Any Ubnt STA that sees more than > 200 networks is unable to connect to anything. > > If we limit our scan list to only 28% of 5GHz frequencies (5160-5280) and we > still run into the buffer to large(65535) for realocating issue. This means > UNII-1 is very hard for us to use. > > I am also concerned that one day the cable goons will flip the switch, double > the number of BSSIDs they broadcast, we'll be over the 200 limit, and half of > our customers will disconnect. This BSSID issue is really a problem for urban > wisps. > > There was a proposed fix from the Linux community in 2009 > http://osdir.com/ml/linux-wireless/2009-02/msg00202.html > I don't know if it was adopted, but the proposed fix from 2009 was to > truncate the scan instead of choking and failing to scan at all. > > > v5.6 to the rescue... but not yet > AirOS version 5.6 (tested v5.6beta5) also has the issue. No fix quite yet. > > If the patch is simple, I would really like a v5.5 firmware that doesn't have > the buffer to large(65535) I would like to use UNII-1 as soon as possible. It > is true, scan list is a workaround, but we are going the wrong way, making it > more difficult to change frequencies instead of easier. Because of urban > interference issues, I would like change AP frequencies nightly or so, > measure statistics, and thus find low-interference channels (we cannot scan > in real-time and airview done at night does not reflect daytime > interference). As I am forced to make the scan list smaller and smaller, I > have to update scan-lists on all STAs before I can change AP frequency, > making it much harder to change freq nightly. > > > http://community.ubnt.com/t5/Installation-Troubleshooting/v5-5-10-major-bug-no-SSIDs-in-scan-print-scanning-info-buffer/m-p/1077389/highlight/false#M72179 > > > > Colin > netBlazr - 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. > >> On Thu, Oct 30, 2014 at 2:49 PM, Matt Hardy <[email protected]> wrote: >> To follow up on this thread, we found the issue. This wasn't really a new >> bug introduced in v5.5.10, but with the additional frequencies the customer >> was seeing > 100 new APs broadcasting in the UNII-1 band (probably lots of >> indoor APs). There's a limit of 200 APs the radio can pick up when doing a >> scan, if the radio is in an area with > 200 broadcasting SSIDs, it causes >> this issue (on any firmware) and device stops performing as expected. >> >> We'll be increasing the limit in v5.6, but in the meantime there are >> workarounds: scan list, different channel bandwidths, etc. >> >> Thanks, >> Matt >> >>> On Tue, Oct 28, 2014 at 7:52 PM, Phil Curnutt <[email protected]> wrote: >>> Is there a Scan List set? Cut the number of channels it searches down to a >>> minimum. >>> >>> Phil >>> >>>> On Tue, Oct 28, 2014 at 11:30 AM, Matt Hoppes <[email protected]> >>>> wrote: >>>> XW is different.... than XM. >>>> >>>> On 10/28/14, 12:35 PM, Josh Reynolds wrote: >>>> > So they say, yet when XW 5.5.10 was placed on XW Ti hardware, the gear >>>> > went nuts for a full 24 hours before we tried 5.5.6. When it was just as >>>> > bad, I went to 5.5.10rc3... same issues. 5.5.10rc2? Everything went back >>>> > to normal. It wasn't just one piece of hardware either, the same >>>> > symptoms were noticed on 4 different APs. >>>> > >>>> > They can say nothing changed all they want-- something changed, there >>>> > were 3rcs, a final, and now tons of bug reports on 5.5.10. >>>> > >>>> > Josh Reynolds, Chief Information Officer >>>> > SPITwSPOTS, www.spitwspots.com <http://www.spitwspots.com> >>>> > >>>> > On 10/28/2014 05:05 AM, Matt Hoppes 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 >> >> >> _______________________________________________ >> 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
