Raspberry Pi 3 Wifi driver not connecting to dual band Access Points

[prosenjitp]

We have dual-band AP (Unifi UAP-Pro’s). It is advertising same SSID in both the bands
(2.4 GHz and 5 GHz).
Raspberry Pi 3 running 2016-05-31 raspbian-jessie-lite + our application software (that has no modification for WiFi module) is not able to connect to even 2.4 GHz band.
If we turn off 5 GHz for the same SSID (advertising only in 2.4 GHz band) , it is able to connect.

[pelwell]

That's strange, because we have two wireless networks here, both advertising their own SSID across 2.4 and 5G, and my Pi3 will happily connect to both.

Does the SSID appear in the list of networks to connect to? What happens if you (temporarily) use a different SSID on one of the bands?
Also, can you run sudo iw dev wlan0 scan > scan.txt and upload scan.txt somewhere - perhaps a GitHub Gist?

[prosenjitp]

Does the SSID appear in the list of networks to connect to? Yes, If I insert one 2.4 GHz WiFi (e.g. pluggable) dongle on one of the USB slots, it is able to connect to that SSID.

What happens if you (temporarily) use a different SSID on one of the bands? RPi3 connects to the SSID operating in 2.4 GHz.

can you run sudo iw dev wlan0 scan > scan.txt and upload scan.txt somewhere - perhaps a GitHub Gist? https://gist.github.com/prosenjitp/6e59e614013e5f96b6af8257e12cbb1e

[pelwell]

Which SSID are you trying to connect to?

Is that scan with common or distinct SSIDs?

[prosenjitp]

The one that I renamed ABC.
ABC is being advertised on channel 11 in 2.4 GHz range and also in 5 GHz range simultaneously.
This scan is with dual mode.

[pelwell]

I'm not a WLAN expert, but there is nothing obviously wrong there. Here is the scan of one of our working dual-band APs:

BSS xx:xx:xx:xx:xx:xx(on wlan0)
        TSF: 0 usec (0d, 00:00:00)
        freq: 2437
        beacon interval: 100 TUs
        capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
        signal: -60.00 dBm
        last seen: 0 ms ago
        SSID: XXXXXXXXXXXXXX
        Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
        DS Parameter set: channel 6
        ERP: Use_Protection
        Extended supported rates: 24.0 36.0 48.0 54.0
        HT capabilities:
                Capabilities: 0x1ac
                        HT20
                        SM Power Save disabled
                        RX HT20 SGI
                        TX STBC
                        RX STBC 1-stream
                        Max AMSDU length: 3839 bytes
                        No DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 8 usec (0x06)
                HT TX/RX MCS rate indexes supported: 0-23
        HT operation:
                 * primary channel: 6
                 * secondary channel offset: no secondary
                 * STA channel width: 20 MHz

                 * RIFS: 0
                 * HT protection: nonmember
                 * non-GF present: 1
                 * OBSS non-GF present: 0
                 * dual beacon: 0
                 * dual CTS protection: 0
                 * STBC beacon: 0
                 * L-SIG TXOP Prot: 0
                 * PCO active: 0
                 * PCO phase: 0
        Extended capabilities: 6
        WMM:     * Parameter version 1
                 * BE: CW 15-1023, AIFSN 3
                 * BK: CW 15-1023, AIFSN 7
                 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
                 * VO: CW 3-7, AIFSN 2, TXOP 1504 usec
        RSN:     * Version: 1
                 * Group cipher: CCMP
                 * Pairwise ciphers: CCMP
                 * Authentication suites: PSK
                 * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)

Perhaps you could try using different SSIDs again and running another scan, then checking for differences to the previous scan?

[ZachVan]

Try renaming you ssid to [name you want]24 and [name you want]5, if this fixes it its not a issue with the pi its with your router.

[glennbullion]

This does indeed fix the problem. Separating the names of the SSIDs, or turning off 5 GHz completely, will let the Pis connect.

However, all our other devices (laptops, mobiles devices, etc.), connect using our dual band set up just fine. I don't mind changing any settings, just have to figure out what to change.

But, in saying that, still trying to figure out the cause. Even having both bands named the same thing, I wouldn't think the Pi would care about that, since it doesn't support 5 GHz. How come Pis don't work, but everything else does?

[glennbullion]

Another note. Plugging in an external USB adapter into the Pi also fixes the problem.

I may have it working, more to follow soon. Still, doesn't make sense to me.

[glennbullion]

It seems we've found the issue. Here are the exact details:

Using Unifi UAP-Pro access points, with both bands (2.4 and 5) broadcasting the same SSID, with the Band Steering feature turned on, a Raspberry Pi 3 will not connect to the access point reliably.

Band Steering is a feature in the UAP-Pro that "nudges" clients more toward the less congested 5Ghz band. It works fine on our other devices, laptops, phones, etc. But apparently the internal Wifi adapter of the Raspberry Pi 3 doesn't like this. Plugging in an external adapter worked fine, but the internal, no luck.

Turned off this feature, waited for the access points to provision, and slowly the Pi units started to connect, and have been connected ever since.

I can notify Unifi of this issue, but ultimately the problem seems to be something with the internal adapter of the Pi 3.

[jamesjryan]

Thanks @glennbullion

I have the same configuration - a UniFi AP-AC-LR broadcasting 2.4ghz and 5ghz over the same SSID.

The Pi was unable to connect with band steering on "STEER TO 5G" or "BALANCED" settings.

Turning off band steering immediately made the Rapsberry Pi 3 able to connect.

[pelwell]

Thank you - this is a timely nudge, as this week we've been refitted with UniFi Pro APs. They've had the band steering feature disabled, but we could enable it for specific tests.

[pelwell]

Testing done - with the same SSID on 2.4G and 5G, and "STEER TO 5G" selected on a UniFi AP Pro, my Pi3 running with a recent 4.4 kernel connects without any difficulty.

I'll see what the Broadcom/Cypress engineers say.

[glennbullion]

Ah, the recent kernel fixes this issue? I may enable band steering again to test. This is good to hear.

[pelwell]

No, I'd be surprised if it makes any difference, but we should rule it out.

[ppal-prophecy]

@pelwel, can you specify the kernel version you are using in your Pi 3 ?

[pelwell]

Linux version 4.4.26-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #915 SMP Thu Oct 20 17:08:44 BST 2016

That's what you get if you run sudo rpi-update 849dc3a5c3e381991eba31adecd00553a32cb0f8.

[pelwell]

@glennbullion Cypress would like to know the product ID and firmware version of your UniFI AP. For example, ours are:

Model   UniFi AP-AC-Pro
Version 3.4.19.3477

From what you wrote earlier I think your model is AP-AC-LR, but which firmware?

[glennbullion]

We're using Unifi AP-Pro's, and the firmware version is: 3.3.20.4019

Side note, we did update our Pis to the latest version, and re-enabled Band Steering, and the Pis seem to be connecting okay.

[pelwell]

Side note, we did update our Pis to the latest version, and re-enabled Band Steering, and the Pis seem to be connecting okay.

That's not a side note - that's a bold, triple-underlined bullet point.

Can I ask that anybody with the same problem updates to the latest Raspbian release, which as of today is dated 2016-09-23 ?

[jamesjryan]

I will be updating in the next week or so, will re enable band steering and
report back when I do.

On Tue, 15 Nov 2016, 12:24 AM Phil Elwell notifications@github.com wrote:

Side note, we did update our Pis to the latest version, and re-enabled
Band Steering, and the Pis seem to be connecting okay.

That's not a side note - that's a bold, triple-underlined bullet point.

Can I ask that anybody with the same problem updates to the latest
Raspbian release, which as of today is dated 2016-09-23 ?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1542 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMKkbijhFsW-CFdamCSeHekplroKQuKlks5q-GB_gaJpZM4I-RIR
.

[pelwell]

That would be good. It would be helpful if you can make a note of what the current firmware is before updating, so we can bisect.

[Ruffio]

@jamesjryan how did the test go?

[jamesjryan]

@Ruffio I haven't done the update on the Pi and unfortunately is currently not a priority. Please don't hold your breath. If I do get it out in the future I'll check firmware version before blowing everything away.

[JamesH65]

Closing this issue as questions answered/issue resolved.