[SOLVED] Pi 4 slow wifi?

I've been having Slow Wifi issues on my RazPi on 2.4Ghz. This is local wifi in a small house. It's slower than anything else in my place atm. Things I've done include

1. Trying an update of the firmware binary brcmfmac43455-sdio.bin to the latest from the git of the kernel firmware. No help.
2. I noticed the firmware txt files were config files, assigning values to labels. There was one for the Rpi-3, one for the Rpi-4, and another for some weird name. The Debian stuff I was using just had brcmfmac43455-sdio.txt. I diffed that with the RazPi-4 one in the kernel git, and they differed. So I copied the RPi-4 file from the kernel git to my firmware dir as brcmfmac-sdio.txt. That may have gotten me a few % increase.
3. Researched the hardware, which was interesting. Cypress start their chip numbers with CY, and Broadcom with BCM. There was a Broadcom manufactured IC BCM43454 & BCM43456; But the only BCM43455 was manufactured by Cypress. The brcmfmac43455 runs the RazPi-4 wifi, but I presume it's an IP core (or a chunk of an ASIC design) in the APU, the BCM2711 SoC. The key factor here is that they're unlikely to have tested the hardware sensitivity in the BCM2711 core like they tested the one in silicon.
4. Researched my local problem. One of the things I tried was 'iwlist wlan0 scan |grep -c Channel' . The RazPi counted 20. As fast as I could get upstairs I tried it on the Laptop, there was 36. With 'iwlist wlan0 scan |grep -A2 Channel,' my Laptop (with an ath9k wifi) was spotting channels at ≥-92dBm, or Quality 17/70. I saw basically nothing below 40/70 on the RazPi, so the sensitivity is low. That means channels it doesn't know about could be interfering with it. That could confuse things.

I'm running out of clever things to do here that yield any information. Has anyone any ideas for me? I seem to have taken it about as far as I can, and although my Pi was bought as a media server, It won't download fast enough to do that.

Hardware's cheap, do you have another one you could try? E.g: https://www.ign.com/articles/best-usb-wifi-adapter &c...

Originally Posted by business_kid I'm running out of clever things to do here that yield any information. Has anyone any ideas for me? I seem to have taken it about as far as I can, and although my Pi was bought as a media server, It won't download fast enough to do that.

We have previously touched upon the reasons why I don't think it's a good idea to use the on-board Raspberry Pi wireless device. Unless your RPi is located approx. 1 metre from your router then in my experience it's less troublesome to use a USB wireless adapter (or stick to using an Ethernet connection when possible). In fact, it would be a good idea, and prudent for you to do that anyway in order to save yourself some time, effort, and headaches.

Originally Posted by jamison20000e Hardware's cheap, do you have another one you could try? E.g: https://www.ign.com/articles/best-usb-wifi-adapter &c...

Excellent, sensible, and logical advice.

I have half a dozen of these USB wireless network adapters laying around for testing and such. They're quite handy for other things than just ARM devices. From my experience with Slackware ARM on the Raspberry Pis, I've found the most reliable and trouble-free choice (and one of the most affordable) is the Ralink RT5370. It's not dual-band or USB3 but that option is always there for users with more ambitious requirements, and bigger wallets, provided that the drivers are available.

I must say I didn't have any trouble with the wifi until recently. There's a couple of people about that have gone over to 5Ghz. Sadly, I'm inclined to agree. It seems a number of the local routers are on 'Autochannel' so 2.4Ghz is unpredictable.

I'm going to mark this solved. The solution is that Broadcom wifi is crap. As a hardware guy, I regard faulty hardware as a last resort diagnosis, but it sadly seems to apply here. I saw one 'Quality' signal at 27/70 (-82dBm) but I immediately scanned again and it wasn't there. That's not good enough.

I'll need a usb 3.0 wifi dongle with 5Ghz, not the cheapo ones. I'll go shopping.

There are a number of additional factors involved besides the chip set and the firmware of your device. Are you using the same channel as the majority of other access points in wireless range? Do you have signal interference due to the physical location of your hardware? How many clients are there on your wireless access point and do you have quality of service (QoS) enabled? What else do you have running on your Pi or on your network? Is anything poorly configured on your router or do you need to update the firmware of your router?

I've said it before, but... I have had great success with the pi 3b as a wireless router using hostapd to serve WiFi to all types of devices on my network. One of our smart tvs is in a room that doesn't have an Ethernet connection and it works well on the wireless connection. I typically have a mix of 14 devices (phones, laptops, tablets, printers, tv, even the sprinkler system) on my connection and do not experience any of what you are reporting.

@business_kid

As per jamison20000e's advice, you should opt for an external adapter. It's not only the HW, but also the weird antenna design that was first tested/implemented on the Pi Zero W boards:
https://magpi.raspberrypi.org/articl...antenna-design
At least on those boards you still got the possibility to solder an antenna connector and use an external antenna:
https://www.raspberrypi.org/forums/v...c.php?t=176249
https://www.briandorey.com/post/rasp...al-antenna-mod

Not sure if you can do that on the Pi 4 board, still, there are successful hacks for Pi 3:
https://hackaday.com/2016/03/18/hack...a-for-more-db/

Then, there's a design flaw in the Pi 4, excessive noise interfering with the 2.4 GHz channels:
https://www.tomshardware.com/news/ra...fi-not-working

And as you've already noticed, there's chaos in the 2.4GHz band, as all the routers are using automatic channel selection algorithms by default and trying to use a non-overlapping channel, of which there are only 3 - 1,6,11 (that's on HT20 (20MHz bandwidth)).
https://en.wikipedia.org/wiki/Wifi_interference#Wi-Fi
https://en.wikipedia.org/wiki/File:N...GHzWLAN-en.svg

... that's only half the story. With the introduction of the 2.4GHz extension 80211.n, 40MHz wide channels "HT40" were allowed/implemented and used (enabled) based on survey and availability. But most of the cheap Chinese Access Points had them enabled by default in their firmware, in an abusive way, occupying (polluting) the 2.4MHz spectrum.
Discussion:
https://forum.openwrt.org/t/40mhz-80...mhz-wide/19547

For properly using the 2.4GHz band you need some good equipment nowadays - HW & antenna. On the other side, the 5GHz band is still OK, wider channels and not that much noise, as most of the "common" routers are not supporting it, but the coverage is lower (50%-75% compared to 2.4GHz).

@mralk: I think the figures speak for themselves

• Mobile phone on wifi away from router 49 Mbps download
• Laptop not badly placed for router - 35-40Mbps d/l
• Razpi 4 well placed from router - ≤7Mbps, dropping badly at crowded times.

I get a 100Mbps connection from Glass fibre coming via dsl to the router at about 60Mbps. The RazPi is well placed vs the other two. The the last thing I want to do is experiment on this. I'm now seeing if I can get a 5Ghz router from my isp, and I have another thread open on the Ralink chips to see what support is like. Instead of using unsupported Realtek stuff, now these usb adapters w/5G all have the Ralink 5370. I can disable the 2.4Ghz AP, put in a 5Ghz AP. I mightn't even need anything for the Pi.

agba, thank you for the well researched post. Thanks for the links. My days of hacking hardware are over, it seems. Phone companies here are inclined to buy, install, and support decent modem/routers. It's interesting what you say on Pi 4 wifi issues. I think the antenna goes up the side of the pcb, but there's still polarisation & one or two other issues to eliminate.

I do not really know if it was valid for RPi4 too, but bluetooth and wifi could not work well together on earlier devices (like RPi3). Also (unfortunately) I bought a nice metal box for my RPi3 which blocked both (bluetooth and wifi). It may also depend on the power supply of PRi. Otherwise buying a good external wifi stick (with a powered usb hub) is probably a quick and reliable solution.

My wife says: "There's no bigger fool than a clever fool." I must confess…

A relevant item of information That wasn't disclosed is that of late, I've been using a Flirc case.They've stuck a black covering covering on the 'heatsink' side, so it looks quite like the rubber side, but I thought I knew the difference. I checked that the Flirc case doesn't affect wifi reception. The guys at Flirc assure folks that it doesn't; but if it's earthed, the signal probably would be affected. Whether the case is in fact earthed depends on imponderables, but for CE approval in Europe it would have to be.

So, despite my limitations, I started messing. Before digital TV, (here in early 2000s) the science of making distant signals into usable TV pictures was very highly developed in Ireland. I know the ropes myself. So starting with 15Mbps d/l on a very quiet and dry afternoon, I got the download up to ~25Mbps by pointing (as I thought) the rubber side of the case directly at the wifi router, and polarising it correctly. Back in the Analogue TV days, they used list the polarization of TV channels, as looking for a vertically polarized signal with a horizontally polarized aerial yields poor results.

Anyhow, to multiply my embarrassment, I turned the case around so the 'metal' pointed at the wifi. I expected it to slow, but I got up to 30Mbps! For this house, 30Mbps is good enough. It's certainly enough to stream hdmi @60Hz.

Originally Posted by mralk3 I've said it before, but... I have had great success with the pi 3b as a wireless router using hostapd to serve WiFi to all types of devices on my network. One of our smart tvs is in a room that doesn't have an Ethernet connection and it works well on the wireless connection. I typically have a mix of 14 devices (phones, laptops, tablets, printers, tv, even the sprinkler system) on my connection and do not experience any of what you are reporting.

Sounds great!

I have a dual-band router (2.4GHz and 5GHz) and I generally only have 2-3 wireless devices connecting to it; iPhone, laptop, tablet. Any devices that are capable of using the 5GHz band I'll connect to it. Otherwise it's the 2.4GHz. I'm not a passionate advocate of wireless Internet technology and much prefer to keep my data confined to Ethernet cables when at all possible.

With the RPi3 the on-board wireless for me is/was very unreliable. I have tried all sorts of tricks and ideas to try and overcome the constant wireless connection drop-outs, etc. including a RPi tin-foil hat (and I'm not joking!). Nothing seems to be 100% successful. The thing that makes the biggest difference on my setup is capping the data transfer speed to approx. 1Mb/s and then it stays connected for longer periods without dropping, but it will always eventually drop-out. The RPi3 on-board wireless also behaves itself a little better if the device is <1 metre from my router but will still lose connection once I start to transfer large amounts of data - only maybe not quite as often. When using a USB wireless network adapter with the RPi3 none of these issues are apparent for me. This is why, whenever I need to use wireless Internet with the RPis, I just plug in a USB wireless network adapter and configure it rather than waste time with the on-board shizzle.

I've recently ordered a RTL8812BU-based wireless network adapter which is USB3, 2.4GHz and 5GHz dual-band, and boasts a 1200Mbps data transfer rate. So I'm interested to use this with Slackware ARM on the RPi4 and play around with it. Only problem I can foresee is that RealTek don't have any Linux drivers available for download on their official site but there seems to be some RTL8812BU support on GitHub for various kernels. I'm pretty confident that Slackware ARM will be accommodating towards this chipset anyway, and if not then I'm damned sure some jiggery-pokery will make it happen.

After my experience, it seems the sensitivity of the 43455 is suspect, and it handles interference poorly.

Any Pi case that isn't metal probably has a big fan in the way. Polarizing the board correctly (parallel to the aerial) always helps. Orienting the aerial to get a good direct path or just trying it different ways is worth a shot. It's trivial to do that sort of thing - less trivial for me since my stroke. My download speed held up pretty well when the crowds came home; but yesterday was a bank holiday here, so I'd expect heavier streaming later in the week.

The 8188BU is not currently supported, but it will get added to the rtlwifi kernel module in time. It seems Realtek never got a programmer accepted to write kernel code, but things are moving somehow now. Neither, for that matter, did Ralink/Mediatek. Things don't seem to be moving there. Their one driver up there is from 2012, and uses a RHEL 2.6.1 kernel as a base. IIRC, there's been a reordering of kernel headers since then, so compiles are going to be messy.

Originally Posted by mralk3 There are a number of additional factors involved besides the chip set and the firmware of your device.

You are SO RIGHT!

The dual-band USB3 wireless network adapter I ordered was delivered yesterday. It came packaged on heat-shrink-front-sealed cardboard with no identifying information - other than "Dual Band USB Adapter" printed at the top and a sticker with "SKU:353118 BXBX-XT-XD made in China" on it. Inside the package there was also a 3" dia software/driver CD titled "RTL19OCT". The eBay seller listed this device as a 'Realtek RTL8812BU' but there wasn't any information which accompanied it to verify what it was. It looks cheap, because it is cheap, but I'm eager to play with it and see if i can get it working with Slackware ARM.

I plugged the device into a USB3 port on my RPi4 [4GB] running Slackware ARM -current and ran 'lsusb':

root@torq:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0bda:b812 Realtek Semiconductor Corp.
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 001 Device 003: [vendor/product] ID '0bda:b812' - that's a start. What does the output of 'lsusb -v -d 0bda:b812' reveal?

root@torq:~# lsusb -v -d 0bda:b812
Bus 001 Device 003: ID 0bda:b812 Realtek Semiconductor Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0bda Realtek Semiconductor Corp.
  idProduct          0xb812
  bcdDevice            2.10
  iManufacturer           1 Realtek
  iProduct                2 USB3.0 802.11ac 1200M Adapter
  iSerial                 3 123456
  bNumConfigurations      1

Hmmm. Nothing more than is already known. ... I wonder if 'lsusb -t' will reveal which driver it uses...

root@torq:~# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 480M

Haha! Not a chance. So, I browsed the accompanying software/driver CD and found that it had Windows, Mac, and Linux support. Things were looking up! The Linux driver dir contains two other dirs; one for 'RTL8811AU' and the other for 'RTL81888192EUS'. Sadly, no sign or mention of the 'RTL8812BU'. Then I hit Google and was able to [95%] determine that the vendor/product ID '0bda:b812' belonged to the "Realtek Semiconductor Corp RTL8812BU" device. At this point I'd love to know where the eBay seller got their information for this adapter because right now I only have the 'lsusb' output to work with.

I plugged the wireless adapter into an Ubuntu laptop. No joy. Then I plugged it into a Raspberry Pi running Raspberry Pi OS (previously called Raspbian). Still no joy. Then I plugged it into a Windows 10 desktop system (listen, I was getting desperate. OK? ) and, BOOM! There it is! "Realtek RTL8812BU device detected" and auto-installed within seconds. I was able to connect to my 5GHz WLAN without any problems and verify that this wireless USB adapter was the 'RTL8812BU', and that it actually worked as expected - albeit in Microsoft Windows.

I spent the next hour or so searching with Google and test-compiling-installing Linux RTL8812/8822 drivers. To cut a long story short I got lucky and found this GitHub repo: https://github.com/cilynx/rtl88x2bu - this maintainer has been very clever by using existing Realtek drivers and learning from what others have done with their wireless devices in order to make drivers work correctly and then superimposing some of it, and his own fixes, into this source. He has several repo's going on and I'd tried the others, all of which failed in various ways. However this repo is a combination of his other repo's and proved to be 100% successful in building, installing, and during operation (after a little tinkering with the Makefile).

root@torq:/tmp# git clone git://github.com/cilynx/rtl88x2bu rtl88x2bu-git
Cloning into 'rtl88x2bu-git'...
remote: Enumerating objects: 194, done.
remote: Counting objects: 100% (194/194), done.
remote: Compressing objects: 100% (170/170), done.
remote: Total 1095 (delta 44), reused 49 (delta 21), pack-reused 901
Receiving objects: 100% (1095/1095), 5.69 MiB | 585.00 KiB/s, done.
Resolving deltas: 100% (437/437), done.
root@torq:/tmp# cd rtl88x2bu-git/
root@torq:/tmp# nano -w Makefile   # disabled I386_PC and enabled ARM_RPI
root@torq:/tmp/rtl88x2bu-git# make -j4
make ARCH=arm CROSS_COMPILE= -C /lib/modules/5.4.58-v7l-arm/build M=/tmp/rtl88x2bu-git  modules
make[1]: *** /lib/modules/5.4.58-v7l-arm/build: No such file or directory.  Stop.
make: *** [Makefile:2284: modules] Error 2

DOH! To build the module(s) I'm going to need the Linux source...

root@torq:/tmp/rtl88x2bu-git# installpkg /tmp/sarpi4-kernel-source-5.4.59-armv7l-1_sp1.txz
Verifying package sarpi4-kernel-source-5.4.59-armv7l-1_sp1.txz.
Installing package sarpi4-kernel-source-5.4.59-armv7l-1_sp1.txz:
Executing install script for sarpi4-kernel-source-5.4.59-armv7l-1_sp1.txz.
Package sarpi4-kernel-source-5.4.59-armv7l-1_sp1.txz installed.
root@torq:/tmp/rtl88x2bu-git# make -j4
make ARCH=arm CROSS_COMPILE= -C /lib/modules/5.4.58-v7l-arm/build M=/tmp/rtl88x2bu-git  modules
make[1]: Entering directory '/usr/src/linux-5.4.59'
...
  Building modules, stage 2.
  MODPOST 1 modules
  CC [M]  /tmp/rtl88x2bu-git/88x2bu.mod.o
  LD [M]  /tmp/rtl88x2bu-git/88x2bu.ko
make[1]: Leaving directory '/usr/src/linux-5.4.59'
root@torq:/tmp/rtl88x2bu-git#

Now to install and load the module(s)...

root@torq:/tmp/rtl88x2bu-git# mkdir -p /lib/modules/5.4.58-v7l-arm/kernel/drivers/net/wireless/realtek/rtl88x2bu
root@torq:/tmp/rtl88x2bu-git# make install DESTDIR=/lib/modules/5.4.58-v7l-arm/kernel/drivers/net/wireless/realtek/rtl88x2bu
install -p -m 644 88x2bu.ko  /lib/modules/5.4.58-v7l-arm/kernel/drivers/net/wireless/
/sbin/depmod -a 5.4.58-v7l-arm
root@torq:/tmp/rtl88x2bu-git# modprobe 88x2bu
root@torq:/tmp/rtl88x2bu-git# iwconfig
lo        no wireless extensions.

wlan1     unassociated  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency=2.412 GHz  Access Point: Not-Associated
          Sensitivity:0/0
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

eth0      no wireless extensions.

root@torq:/tmp/rtl88x2bu-git# ifconfig wlan1 up

OK. So it's been assigned the 'wlan1' interface (I'll change that to 'wlan0' later) and also currently working on the 2GHz wireless band. Now to connect to the 5GHz WLAN using 'nmtui' (NetworkManager's text user interface) because it's quick, easy, and reliable...

root@torq:/tmp/rtl88x2bu-git# nmtui   # created and activated a new connection to the 5G WLAN
root@torq:/tmp/rtl88x2bu-git# ifconfig wlan1
wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.145  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2002:5204:995d:0:ae9f:9466:aa:fc1b  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::949f:98b2:e1c8:c98  prefixlen 64  scopeid 0x20<link>
        ether 1c:bf:ce:f5:06:74  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 2991 (2.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 23  bytes 3374 (3.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@torq:/tmp/rtl88x2bu-git# iwconfig
lo        no wireless extensions.

wlan1     IEEE 802.11an  ESSID:"FATDOG5G"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:5.18 GHz  Access Point: 98:FC:11:70:E3:24
          Bit Rate:144.4 Mb/s   Sensitivity:0/0
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=98/100  Signal level=68/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

eth0      no wireless extensions.

root@torq:/tmp/rtl88x2bu-git# ping -c 4 google.com
PING google.com (172.217.169.14) 56(84) bytes of data.
64 bytes from lhr25s26-in-f14.1e100.net (172.217.169.14): icmp_seq=1 ttl=115 time=23.4 ms
64 bytes from lhr25s26-in-f14.1e100.net (172.217.169.14): icmp_seq=2 ttl=115 time=22.7 ms
64 bytes from lhr25s26-in-f14.1e100.net (172.217.169.14): icmp_seq=3 ttl=115 time=22.9 ms
64 bytes from lhr25s26-in-f14.1e100.net (172.217.169.14): icmp_seq=4 ttl=115 time=23.8 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 22.697/23.188/23.774/0.426 ms
root@torq:/tmp/rtl88x2bu-git# echo 'o' > /proc/sysrq-trigger

It's all working like a charm! Data transfer speeds over the WLAN with this RTL8812BU device are as fast as the Ethernet; which is approx. 33-35Mb/s max. This was all relatively easy, once I had the right drivers and was able to compile them for ARM. I expected there to be a hell of a lot more time and effort involved for a device that was not supported under Linux by the manufacturer, to be honest!

I must admit I'm starting to warm up to wireless networking as a result of this RTL8812BU adapter.

[EDIT] Just to note that if/when I upgrade the kernel-modules I will need to install the rtl88x2bu module again. So I'll be making a Slackware ARM package out of this process to facilitate future deployments.

Originally Posted by mralk3 There are a number of additional factors involved besides the chip set and the firmware of your device.

You are SO RIGHT!

The dual-band USB3 wireless network adapter I ordered was delivered yesterday. It came packaged on heat-shrink-front-sealed cardboard with no identifying information - other than "Dual Band USB Adapter" printed at the top and a sticker with "SKU:353118 BXBX-XT-XD made in China" on it. Inside the package there was also a 3" dia software/driver CD titled "RTL19OCT". The eBay seller listed this device as a 'Realtek RTL8812BU' but there wasn't any information which accompanied it to verify what it was. It looks cheap, because it is cheap, but I'm eager to play with it and see if i can get it working with Slackware ARM.

I plugged the device into a USB3 port on my RPi4 [4GB] running Slackware ARM -current and ran 'lsusb':

root@torq:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0bda:b812 Realtek Semiconductor Corp.
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 001 Device 003: [vendor/product] ID '0bda:b812' - that's a start. What does the output of 'lsusb -v -d 0bda:b812' reveal?

root@torq:~# lsusb -v -d 0bda:b812
Bus 001 Device 003: ID 0bda:b812 Realtek Semiconductor Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0bda Realtek Semiconductor Corp.
  idProduct          0xb812
  bcdDevice            2.10
  iManufacturer           1 Realtek
  iProduct                2 USB3.0 802.11ac 1200M Adapter
  iSerial                 3 123456
  bNumConfigurations      1

Hmmm. Nothing more than is already known. ... I wonder if 'lsusb -t' will reveal which driver it uses...

root@torq:~# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 480M

Haha! Not a chance. So, I browsed the accompanying software/driver CD and found that it had Windows, Mac, and Linux support. Things were looking up! The Linux driver dir contains two other dirs; one for 'RTL8811AU' and the other for 'RTL81888192EUS'. Sadly, no sign or mention of the 'RTL8812BU'. Then I hit Google and was able to [95%] determine that the vendor/product ID '0bda:b812' belonged to the "Realtek Semiconductor Corp RTL8812BU" device. At this point I'd love to know where the eBay seller got their information for this adapter because right now I only have the 'lsusb' output to work with.

I plugged the wireless adapter into an Ubuntu laptop. No joy. Then I plugged it into a Raspberry Pi running Raspberry Pi OS (previously called Raspbian). Still no joy. Then I plugged it into a Windows 10 desktop system (listen, I was getting desperate. OK? ) and, BOOM! There it is! "Realtek RTL8812BU device detected" and auto-installed within seconds. I was able to connect to my 5GHz WLAN without any problems and verify that this wireless USB adapter was the 'RTL8812BU', and that it actually worked as expected - albeit in Microsoft Windows.

I spent the next hour or so searching with Google and test-compiling-installing Linux RTL8812/8822 drivers. To cut a long story short I got lucky and found this GitHub repo: https://github.com/cilynx/rtl88x2bu - this maintainer has been very clever by using existing Realtek drivers and learning from what others have done with their wireless devices in order to make drivers work correctly and then superimposing some of it, and his own fixes, into this source. He has several repo's going on and I'd tried the others, all of which failed in various ways. However this repo is a combination of his other repo's and proved to be 100% successful in building, installing, and during operation (after a little tinkering with the Makefile).

root@torq:~# cd /tmp
root@torq:/tmp# git clone git://github.com/cilynx/rtl88x2bu rtl88x2bu-git
Cloning into 'rtl88x2bu-git'...
remote: Enumerating objects: 194, done.
remote: Counting objects: 100% (194/194), done.
remote: Compressing objects: 100% (170/170), done.
remote: Total 1095 (delta 44), reused 49 (delta 21), pack-reused 901
Receiving objects: 100% (1095/1095), 5.69 MiB | 585.00 KiB/s, done.
Resolving deltas: 100% (437/437), done.
root@torq:/tmp# cd rtl88x2bu-git/
root@torq:/tmp# nano -w Makefile   # disabled I386_PC and enabled ARM_RPI
root@torq:/tmp/rtl88x2bu-git# make -j4
make ARCH=arm CROSS_COMPILE= -C /lib/modules/5.4.59-v7l-arm/build M=/tmp/rtl88x2bu-git  modules
make[1]: *** /lib/modules/5.4.59-v7l-arm/build: No such file or directory.  Stop.
make: *** [Makefile:2284: modules] Error 2

DOH! To build the module(s) I'm going to need the Linux source...

root@torq:/tmp/rtl88x2bu-git# installpkg /tmp/sarpi4-kernel-source-5.4.59-armv7l-1_sp1.txz
Verifying package sarpi4-kernel-source-5.4.59-armv7l-1_sp1.txz.
Installing package sarpi4-kernel-source-5.4.59-armv7l-1_sp1.txz:
Executing install script for sarpi4-kernel-source-5.4.59-armv7l-1_sp1.txz.
Package sarpi4-kernel-source-5.4.59-armv7l-1_sp1.txz installed.
root@torq:/tmp/rtl88x2bu-git# make -j4
make ARCH=arm CROSS_COMPILE= -C /lib/modules/5.4.59-v7l-arm/build M=/tmp/rtl88x2bu-git  modules
make[1]: Entering directory '/usr/src/linux-5.4.59'
...
  Building modules, stage 2.
  MODPOST 1 modules
  CC [M]  /tmp/rtl88x2bu-git/88x2bu.mod.o
  LD [M]  /tmp/rtl88x2bu-git/88x2bu.ko
make[1]: Leaving directory '/usr/src/linux-5.4.59'
root@torq:/tmp/rtl88x2bu-git#

Now to install and load the module(s)...

root@torq:/tmp/rtl88x2bu-git# mkdir -p /lib/modules/5.4.59-v7l-arm/kernel/drivers/net/wireless/realtek/rtl88x2bu
root@torq:/tmp/rtl88x2bu-git# make install DESTDIR=/lib/modules/5.4.59-v7l-arm/kernel/drivers/net/wireless/realtek/rtl88x2bu
install -p -m 644 88x2bu.ko  /lib/modules/5.4.59-v7l-arm/kernel/drivers/net/wireless/
/sbin/depmod -a 5.4.59-v7l-arm
root@torq:/tmp/rtl88x2bu-git# modprobe 88x2bu
root@torq:/tmp/rtl88x2bu-git# iwconfig
lo        no wireless extensions.

wlan1     unassociated  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency=2.412 GHz  Access Point: Not-Associated
          Sensitivity:0/0
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

eth0      no wireless extensions.

root@torq:/tmp/rtl88x2bu-git# ifconfig wlan1 up

OK. So it's been assigned the 'wlan1' interface (I'll change that to 'wlan0' later) and also currently working on the 2GHz wireless band. Now to connect to the 5GHz WLAN using 'nmtui' (NetworkManager's text user interface) because it's quick, easy, and reliable...

root@torq:/tmp/rtl88x2bu-git# nmtui   # created and activated a new connection to the 5GHz WLAN
root@torq:/tmp/rtl88x2bu-git# ifconfig wlan1
wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.145  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2002:5204:995d:0:ae9f:9466:aa:fc1b  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::949f:98b2:e1c8:c98  prefixlen 64  scopeid 0x20<link>
        ether 1c:bf:ce:f5:06:74  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 2991 (2.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 23  bytes 3374 (3.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@torq:/tmp/rtl88x2bu-git# iwconfig
lo        no wireless extensions.

wlan1     IEEE 802.11an  ESSID:"FATDOG5G"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:5.18 GHz  Access Point: 98:FC:11:70:E3:24
          Bit Rate:144.4 Mb/s   Sensitivity:0/0
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=98/100  Signal level=68/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

eth0      no wireless extensions.

root@torq:/tmp/rtl88x2bu-git# ping -c 4 google.com
PING google.com (172.217.169.14) 56(84) bytes of data.
64 bytes from lhr25s26-in-f14.1e100.net (172.217.169.14): icmp_seq=1 ttl=115 time=23.4 ms
64 bytes from lhr25s26-in-f14.1e100.net (172.217.169.14): icmp_seq=2 ttl=115 time=22.7 ms
64 bytes from lhr25s26-in-f14.1e100.net (172.217.169.14): icmp_seq=3 ttl=115 time=22.9 ms
64 bytes from lhr25s26-in-f14.1e100.net (172.217.169.14): icmp_seq=4 ttl=115 time=23.8 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 22.697/23.188/23.774/0.426 ms
root@torq:/tmp/rtl88x2bu-git# echo 'o' > /proc/sysrq-trigger

It's all working like a charm! Data transfer speeds over the WLAN with this RTL8812BU device are as fast as the Ethernet; which is approx. 33-35Mb/s max. This was all relatively easy, once I had the right drivers and was able to compile them for ARM. I expected there to be a hell of a lot more time and effort involved for a device that was not supported under Linux by the manufacturer, to be honest!

I must admit I'm starting to warm up to wireless networking as a result of this RTL8812BU adapter.

[EDIT] I'll be making a Slackware package from this process because if/when I upgrade the kernel-modules the RTL8812BU drivers will need installing again. So to facilitate this process I'll do it with a pkg.

We all get caught by that sort of thing once. In my case, it was only once, because I check info before undertaking an out-of-tree compile. That usually means the manufacturer has no intention of ever updating the firmware. That just might be ok on a wifi adapter, but not much else.

Interesting, too on the lsusb options. I didn't know about some of them. The days are gone when you can always go and read the IC numbers, and trace hardware that way.