Using rtl88au module to connect to 5Gz wifi network on Raspberry Pi 3 Model B

Product support
,
1

Hi there,

For our project we need to connect to a 5-Ghz band wifi network. Currently we are trying to use the USB RealTek adapter with the following driver:
https://github.com/Grawp/rtl8812au_rtl8821au

At first we had problems compiling the driver but was able to get the module to compile and load it into the kernel thanks to the post here. Now we are having trouble getting the pi to actually connect to the network when the application starts. I was able to connect after ssh-ing into the container and using wpa_supplicant to set up the network. We were also able to get it working on boot with a regular old raspbian image (not through resin).

Our current strategy has been to add edit the /etc/network/interfaces file to reference a wpa_supplicant config file, but we haven’t had any luck with that. Have also tried editing the NetworkManager config file on the resin-boot partition but have not been successful.

I think that ideally coping the module to /lib/modules/$(uname -r)/kernel/drivers/net/wireless might fix this, but that location is not writable from the container

Any suggestions would be great!

Thanks
-nick

2

Hey @nickd, my first suggestion, which perhaps isn’t applicable, would be to use one of the supported 5Ghz, I know @curcuz has used this 5 GHz Dual Band USB WiFi Adapter in production on resin.io

It seems really strange that wpa_supplicant would work, but NetworkManager wouldnt. Could you set up a resinOS-2.0.0+rev3.dev image and ssh into the hostOS using ssh root@<device_IP> and see what the networkmanager logs (journalctl -u NetworkManager -f) show after you modprobe the module from within your container.

Paste the logs here and we can see if there is anything useful there.

3

Thanks for the quick response @shaunmulligan. I setup a device with resinOS-2.0.0+rev3.dev and our container, but I am not able to ssh to the host OS (I see connection refused) Do I need to do something to start sshd on the host OS? Apologies if this is in the docs, I will check there as well.

4

@nickd , sorry, i left off the port number. you need to do ssh root@<device_IP> -p22222 .

Alternatively if you have the resin cli installed and are you able to run sudo resin local scan and have it detect your device? if it can find your device on the local network, you will be able to do sudo resin local ssh --host and then interactively select your device. This will drop you into the hostOS. There is no need to start the ssh daemon at all. As long as your device is properly connected to the network,

5

Perfect thanks. Here are the logs:

Apr 28 19:20:27 8fc3f23 NetworkManager[776]: <info>  [1493407227.4100] (wlan0): using nl80211 for WiFi device control
Apr 28 19:20:27 8fc3f23 NetworkManager[776]: <info>  [1493407227.4106] device (wlan0): driver supports Access Point (AP) mode
Apr 28 19:20:27 8fc3f23 NetworkManager[776]: <info>  [1493407227.4201] manager: (wlan0): new 802.11 WiFi device (/org/freedesktop/NetworkManager/Devices/10)
Apr 28 19:20:28 8fc3f23 NetworkManager[776]: <info>  [1493407228.3455] device (wlan0): state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Apr 28 19:20:28 8fc3f23 NetworkManager[776]: <info>  [1493407228.9368] device (wlan0): set-hw-addr: set MAC address to FE:05:73:B0:9B:AE (scanning)
Apr 28 19:20:28 8fc3f23 NetworkManager[776]: <info>  [1493407228.9642] rfkill6: found WiFi radio killswitch (at /sys/devices/platform/soc/3f300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/ieee80211/phy6/rfkill6) (driver brcmfmac_sdio)
Apr 28 19:20:29 8fc3f23 NetworkManager[776]: <info>  [1493407229.0425] sup-iface[0x161e0e8,wlan0]: supports 5 scan SSIDs
Apr 28 19:20:29 8fc3f23 NetworkManager[776]: <info>  [1493407229.0498] device (wlan0): supplicant interface state: starting -> ready
Apr 28 19:20:29 8fc3f23 NetworkManager[776]: <info>  [1493407229.0503] device (wlan0): state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42]
Apr 28 19:20:29 8fc3f23 NetworkManager[776]: <info>  [1493407229.5780] device (wlan0): supplicant interface state: ready -> inactive
Apr 28 19:20:44 8fc3f23 NetworkManager[776]: <info>  [1493407244.0917] device (wlan1): supplicant interface state: inactive -> associated
Apr 28 19:20:44 8fc3f23 NetworkManager[776]: <warn>  [1493407244.0920] sup-iface[0x15c7130,wlan1]: connection disconnected (reason -3)
Apr 28 19:20:44 8fc3f23 NetworkManager[776]: <info>  [1493407244.0924] device (wlan1): supplicant interface state: associated -> disconnected
Apr 28 19:20:44 8fc3f23 NetworkManager[776]: <info>  [1493407244.1878] device (wlan1): supplicant interface state: disconnected -> inactive
Apr 28 19:20:44 8fc3f23 NetworkManager[776]: <info>  [1493407244.2060] device (wlan1): set-hw-addr: set MAC address to 0A:3C:FE:50:95:B7 (scanning)
Apr 28 19:20:44 8fc3f23 NetworkManager[776]: <info>  [1493407244.2176] device (wlan1): supplicant interface state: inactive -> disabled
Apr 28 19:20:44 8fc3f23 NetworkManager[776]: <info>  [1493407244.5569] device (wlan1): supplicant interface state: disabled -> inactive
Apr 28 19:21:16 8fc3f23 NetworkManager[776]: <info>  [1493407276.2387] device (wlan1): supplicant interface state: inactive -> associated
Apr 28 19:21:16 8fc3f23 NetworkManager[776]: <warn>  [1493407276.2390] sup-iface[0x15c7130,wlan1]: connection disconnected (reason -3)
Apr 28 19:21:16 8fc3f23 NetworkManager[776]: <info>  [1493407276.2396] device (wlan1): supplicant interface state: associated -> disconnected
Apr 28 19:21:16 8fc3f23 NetworkManager[776]: <info>  [1493407276.3155] device (wlan1): supplicant interface state: disconnected -> inactive

Note that wlan0 should be the interface that connects to the 5-Ghz network.

6

Hi Nick,

I’ve had a lot of (far too much) experience with that chipset, and can recommend moving away from that particular version of the driver to this one:

It was released into the wild about a month ago, and has a lot of bug-fixes in it.

Strictly speaking, you shouldn’t have to copy the module any where - just insmod it, and because the container is running in privileged mode, it should “just work”. Having said that, because you always insmod after NM has start up, I could imagine that it gets confused, and doesn’t notice that the device is available.

I’d suggest having a look at this library:

Specifically this nifty utility:

Then, you should be able to do something like this:

export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
python n-m activate <connection_name>

Which, as long as your NM config file is correct, should bring the connection up.

1 Like
7

@cmoss Thanks a lot for responding to this, good to have some solidarity :slight_smile:

I just tried this solution and I think its the closet I’ve gotten, but I still can’t seem to bring up this connection. One problem I notice is that even though the module is appearing when I use lsmod, the kernel doesn’t seem to use it when trying to connect to wifi. When I run the command listed above from the python library, it simply returns with no errors or responses of any kind, but the network does not come up.

I have also tried removing the modules for the on-board wifi chip (brcmfmac and brcmutil) while keeping the 8812au module loaded, but then the script complains that there is no “suitable and available device found.”

I can also see with dmesg that the module seems to be loading properly and is visible with lsmod, but again, doesn’t seem like it is being used to talk with the wifi adapter (which also appears to be properly connected using lsusb). See dmesg logs:

[ 2643.132015] RTW: module init start
[ 2643.138076] RTW: rtl8812au v5.1.5_19247.20160830
[ 2643.145305] RTW: build time: Apr 28 2017 21:46:15
[ 2643.153058] usbcore: registered new interface driver rtl8812au
[ 2643.161703] RTW: module init ret=0

Any thoughts? Thanks again for the help

8

Can you look if the cfg80211 kernel module is loaded? This provides the API that NM is using to configure the card, I’ve seen versions of the module where that dependency gets missed.

Also, can you grab this script:

and paste the output from:

DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket python info.py

that will tell us which drivers NM is using.

9

Yes, cfg80211 is loaded, here is the output:

Version:                       1.4.2
Hostname:                      8fc3f23
Can modify:                    False
Networking enabled:            True
Wireless enabled:              True
Wireless hw enabled:           True
Wwan enabled:                  True
Wwan hw enabled:               True
Wimax enabled:                 False
Wimax hw enabled:              False
Overall state:                 connected_global

Permissions
checkpoint-rollback:           yes
enable-disable-network:        yes
enable-disable-statistics:     yes
enable-disable-wifi:           yes
enable-disable-wimax:          yes
enable-disable-wwan:           yes
network-control:               yes
reload:                        yes
settings.modify.global-dns:    yes
settings.modify.hostname:      yes
settings.modify.own:           yes
settings.modify.system:        yes
sleep-wake:                    yes
wifi.share.open:               yes
wifi.share.protected:          yes

Available network devices
Name       State               Driver               Managed?
lo         unmanaged           unknown              False
eth0       activated           smsc95xx             True
docker0    unmanaged           bridge               False
resin-vpn  unmanaged           tun                  False

Available connections
Name                           Type
resin-wifi                     802-11-wireless
resin-sample                   802-11-wireless
Wired connection 1             802-3-ethernet

Active connections
Name                           Type                 Default    Devices
Wired connection 1             802-3-ethernet       True       eth0

Looks like it is not seeing the device/driver

10

What version of NetworkManager is running on your host there? I’ve just seen this bug:

Which I guess could be the issue here…

11

Well not sure what to say here, it just started working. NetworkManager is able to find the device driver now, kind of out of no where. The only change I made was moving the adapter to a different USB port on the pi. Seems strange that that would happen.

This python library has really come in handy though, thanks for directing me to that