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

Reply via email to