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

Reply via email to