Driver not loading for the WPET-236ACN(BT) by Sparklan

Hello!

I am having trouble getting the WPET-236ACN(BT) to work.
Background:
Fin 1.1, mPCIE port on the back, but interfaces over USB?
Chipset:
Realtek RTL8822BU-CG
Datasheet:
here

Ultimate purpose? Monitoring mode.

lsusb shows:
Bus 001 Device 005: ID 0bda:b82c Realtek Semiconductor Corp.

iwconfig shows:
nothing relevant

dmesg shows:

Highlights:
[ 366.731232] Bluetooth: hci1: Failed to load rtl_bt/rtl8822b_fw.bin
[ 366.740644] Bluetooth: hci1: rtl: examining hci_ver=07 hci_rev=000b lmp_ver=07 lmp_subver=8822
[ 366.753215] Bluetooth: hci1: rtl: loading rtl_bt/rtl8822b_config.bin
[ 366.761730] bluetooth hci1: Direct firmware load for rtl_bt/rtl8822b_config.bin failed with error -2
[ 366.775018] Bluetooth: Necessary config file rtl_bt/rtl8822b_config.bin not found

Context:

full_log_fin_drivers.log (22.5 KB)

@tacLog, just to clarify, does the WiFi of that mPCIe card work? Driver/firmware files are clearly missing for Bluetooth as you have pointed out. But for WiFi I see the following in the logs:

...
[  366.655084] usb 1-1.2: Product: 802.11ac NIC
[  366.659503] usb 1-1.2: Manufacturer: Realtek
...
[  877.491382] device wlan0 entered promiscuous mode
[  877.544878] device wlan0 left promiscuous mode
[ 1724.972789] device wlan0 entered promiscuous mode
[ 1725.055875] device wlan0 left promiscuous mode

wlan0 is the on board adapter.
So no wifi does not work from the card.

At least best I can tell anyways.

Also the logs are from the host.

-Thomas

Support access granted.

uuid:
908104a18a06ae5e1a3dc13c25e007c7

Anything short of bricking the device is fine. Wipe it, restart it, what every you need. :smile:

Thanks for the clarification @pdcastro
I am actively working on figuring this out myself, but I am way out of my league here.

-Thomas

Update:

Trying to install this package to my primary Alpine container.

@tacLog thank you for granting support access to the device. I think the dmesg output you had shared and the missing ‘.bin’ file are the key to this issue. I am bringing this thread to the attention of our devices team – FYI, there may not be a reply before Monday. I am not sure if we have the ability of adding firmware files through an app container (I’ve found this issue), and it might require a new balenaOS release. But let’s see what the team comes back with.

Hi,

As a test, please try to on your board the following commands and let us know if your wifi starts working:

cd /lib/firmware/
mount -o remount,rw /
mkdir rtl_bt
cd rtl_bt/
wget https://github.com/wkennington/linux-firmware/raw/master/rtl_bt/rtl8822b_config.bin
wget https://github.com/wkennington/linux-firmware/raw/master/rtl_bt/rtl8822b_fw.bin
reboot

Best I can tell this didn’t work.

Though it did get rid of the errors above.

I am reading over the dmesg to try and find any more clues. Will update when I do.

new_dmesg.log (19.8 KB)

The errors around Bluetooth have vanished to be replaced with:

[   10.068602] usbcore: registered new interface driver btusb
[   10.075252] Bluetooth: hci1: rtl: examining hci_ver=07 hci_rev=000b lmp_ver=07 lmp_subver=8822
[   10.085941] Bluetooth: hci1: rtl: loading rtl_bt/rtl8822b_config.bin
[   10.109501] Bluetooth: hci1: rtl: loading rtl_bt/rtl8822b_fw.bin
[   10.202748] Bluetooth: hci1: rom_version status=0 version=2
[   10.210246] Bluetooth: cfg_sz 14, total size 20270

Which by what I understand of the above commands is what we just installed.

I can’t find any major differences between the dmesg of a fin with the adapter and without the adapter other than the text above.

This leads me to believe that somehow the wifi part of the adapter is not loaded or recognized independently of the Bluetooth.

Support access is now granted to a new device:
a49451f78439e9a53876fb5a6172f6ee (has the fix that @spanceac created)

Thanks for sharing the new findings, @tacLog. Is at least Bluetooth working, then? I see two bluetooth devices:

root@a49451f:~# hcitool dev
Devices:
	hci1	00:0E:8E:8D:0B:00
	hci0	AC:3F:A4:DA:47:39

(Where hci0 is the Fin’s built-in BT, and hci1 is the mPCIe BT device – deduced by MAC address similarity with the previous Fin device you had shared with us.)

For WiFi, it may now be a matter of the kernel missing a driver for the RTL8822BU chipset. I’ve found this git repo where someone wrote a driver:

8822BU for Linux - Driver for 802.11ac USB Adapter with RTL8822BU chipset
Only STA/Monitor Mode is supported, no AP.

And we have this sample repo that shows how to build a kernel module and load it (insmod) using an app container. Perhaps you’d like to try: :slight_smile:

We don’t normally advise loading WiFi modules through app containers when the module is required for the device to connect to the internet, because if for any reason the app container failed to start (say, an app bug) and the device was rebooted, this could render the device unreachable. However, in your case, it sounds like the additional WiFi card is for monitoring purposes and not required to connect the device to the internet, in which case it might be OK.

We’ll see also if @spanceac has something to add / other suggestions.

@pdcastro

Only STA/Monitor Mode is supported, no AP.

That perfectly fine!

Also, your right in our case this would be completely fine. I will work on this further this afternoon.
Thank you for your help! I hope this works!
-Thomas

Update @pdcastro,

I have been working on this for a week. Sadly I think that is a valuable week wasted. I am not experienced with installing modules into kernels and this was a trying process for me.

The repo you linked only supports kernel versions 4.7 forward. Unless I am wrong the current kernel in Balena OS is 4.14.98.

I contacted the manufacturer and was provided a driver. I can’t talk about it much, but this looks really similar. After some modifications, I managed to get the driver to build.

The modifications were to create a new setting in the make file that passed through the tmp path the Linux headers were put in during the build. This allowed the make file to load its required environment set and it worked. I finally built a module. Then when I tried to use insmod it continuously failed with the message:

insmod: ERROR: could not insert module cant_share_propritiary_nda_stuff_raspberrypi3_2.29.0+rev1.prod/module_name.ko: Invalid module format

This was very frustrating. dmesg, which I now know is where to look for error messages with insmod shows hundreds of:

module_name is a replacement for something I probably can’t share.

[ 90.805662] module_name: disagrees about version of symbol skb_pull
[ 90.811625] module_name: Unknown symbol skb_pull (err -22)
[ 90.818561] module_name: disagrees about version of symbol netif_napi_del
[ 90.825050] module_name: Unknown symbol netif_napi_del (err -22)

Here is the rest:
dmesg.log (7.0 KB)

It seems to complain about the version a lot. I have no idea what it is talking about and I really don’t have more time to put into this.

I am just putting this here so anyone that finds this in the future can not go down this path.

Right now I am trying to find a mPCI card that supports monitor and has drivers out of the box.

Thanks for everyone that helped with this. I wish I could share more to give back the community.

-Thomas

Hey @tacLog, how did you build the module? Based on the example project here:

with modifying your target OS versions for the arguments of build.sh in the Dockerfile? Or something else? The complaints seem to be because of kernel and module mismatch, and that would possibly explain the issues.

It’s too bad that the driver is not open source, though, as it makes it much more difficult for us to help as well. Hope there will be better cards that works better!

@imrehg

Yeah, that was the only way I could get it to work. The modifications I made were really simple:

In build.sh inside the get_and_build() function I changed the make command from:
make -C “$tmp_path” M="$PWD" modules
to
make all TEMP_PATH1="$tmp_path"

The make -C command was located in the make file of the module and it needed to load tons of things in well over 1000 lines of if statements.

Another change I made was inside the proprietary code, but it involved defining balena (in my case just a raspberry pi compute module in the fin) as a sub-architecture that was under arch/arm, and to use TEMP_PATH as the location of the headers. There were some warning during the build, but frustratingly I can’t talk about that.

I am going to try the open source version today if I have time, but I have to work on other needs first.

-Thomas

Thanks for the feedback! I wonder why the changes were needed for the build.sh, but would have to look deeper into that, and without the example module that gives the issues it’s harder. Please keep us posted!