I'm improving my home Wi-Fi again. The symptom that provokes this project is, on Zoom or Apple FaceTime, there are two syndromes: Moderately frequently, audio or video stops momentarily, then resumes. Usually only one of them pauses. More rarely and more annoyingly, there can be a total dropout for two to three seconds, after which (usually) the session resumes.
I caught a big dropout in progress: all the stations (including the Zoom participant) were kicked off Wi-Fi (reason was not discovered) and they then reassociated. The small dropouts are obviously individual packets lost, but it's very hard to get objective evidence of this. However, when I ping from my laptop, often ICMP packets aren't delivered and are retransmitted (correctly) but with long latency, and if the same thing were happening to Zoom packets, the late packets would be too far out of order to be displayed. Both Zoom and FaceTime use SRTP/UDP for their payload. Zoom, at least, has two populations of packets of different sizes which I attribute without proof to audio and video.
Before 2019-06-05 I was using a TP-Link TL-QN722N (Atheros ar9271 chipset), which is a good NIC, but its station table has only 8 slots, and my collection of IoT devices outgrew it.
To accomodate more stations and to add 5GHz capability, I searched for a more modern NIC. I got this one:
Advertised speeds (USB-3.0): 300Mbit/s on 2.4GHz, 867Mbit/s on 5GHz. Measured in a review (2019) (which band?): download 213Mbit/s, upload 21Mbit/s. The driver is not in the mainline kernel but is available officially for OpenSuSE Tumbleweed and Leap 15.2 (and other distros), package name rtl8812au-kmp-default.
The Alfa (RTL8812AU) NIC and driver have been reliable and compatible with all my stations, except for the packet dropouts noted above. With its two 5dBi antennas it has a strong signal, -41dBm at about 7 meters, no walls.
I attributed my packet loss issues to possibly buggy firmware, or bugs in the driver, so I looked for a NIC with a different chipset. The one I picked was:
The chipset in the Cudy is only slightly different from the Alfa,
but it uses a different driver and (I'm pretty sure) different firmware.
It did help the packet drop issues a lot, but it was a mess to keep
the driver up to date (see Second Thoughts
below).
After bad driver experiences I looked for a NIC with an in-kernel driver, specifically a Mediatek chipset. The one I found was:
The Terow worked nicely until a gross worm joined the party: the x86_64 host computer crashed repeatedly (no recordable symptoms captured). The crashes stopped as soon as I reverted to the Cudy. This is obviously a driver bug.
It was suggested to me, why don't I do like everyone else does and buy a commercial router appliance? This is discussed more extensively below under Commercial Router Appliance below, but I didn't take that advice.
I took a wild chance, and transplanted the Terow to a Raspberry Pi with
wired Ethernet, already set up with my normal infrastructure and security
improvements. Essentially I made a dedicated
wireless access point with
my various issues already taken care of. Amazingly, it has gone about 200
hours in normal service without crashing, as this is written. Clearly the
driver bug wasn't fixed, but some aspect of the ARM processor bypasses it.
Stick-Upcameras
My first test was to measure the data transfer rate of my three current NICs at various locations in my house, with these conditions and definitions:
Couchis adjacent to the access point and there should be no issue with interfering signals.
Kitchenis 7 meters distant with a clear line of sight, no walls, no Wi-Fi-active competitors.
Laundryis 14.5 meters away with one wall. The TP-Link range extender is in this room and is on the same channel, providing interference.
Downloadmeans the laptop is sucking data from the server; the server's wireless NIC is transmitting.
Uploadmeans laptop to server (but in this test the server sucks, the laptop isn't pushing). The server's wireless NIC is receiving.
| Couch | Kitchen | Laundry | |
|---|---|---|---|
| Distance from AP (M) | 1.7 | 7.0 | 14.5 |
| — Alfa Long Range Dual Band AC1200 Wireless USB-3.0 Wi-Fi (RTL8812AU) | |||
| Signal (dBm) | -41 | -44 | -55 |
| Download (Mbyte/sec) | 2.1 | 2.2 | 2.1 |
| Upload (Mbyte/sec) | 2.4 | 2.3 | 1.9 |
| — Cudy AC 1300Mbps USB 3.0 Dual Band WiFi Adapter (RTL8812BU) | |||
| Signal (dBm) | -48 | -56 | -75 |
| Download (Mbyte/sec) | 3.0 | 3.4 | 3.3 |
| Upload (Mbyte/sec) | 6.7 | 5.3 | 4.8 |
| — Terow ROW02FD (Mediatek mt7612u) | |||
| Signal (dBm) | -43 | -50 | -67 |
| Download (Mbyte/sec) | 6.8 | 5.1 | 6.3 |
| Upload (Mbyte/sec) | 6.0 | 4.7 | 4.6 |
Analysis of data rate test: I was surprised that the data rate of the Cudy NIC was consistently faster (1.5x for download, up to 2.9x for upload) than the Alfa NIC, despite its lower signal strength. For the Alfa the up and download rates were closely similar, whereas the Cudy receives uploads over twice as fast as it can send downloads. A similar asymmetry was seen in the ping test (next item). The Terow could receive an upload similarly fast as the Cudy, but the Terow could send a download about equally fast as an upload, while the Cudy was 2/3 to 1/2 the speed. The Terow has a significantly higher signal than the Cudy, but less than the Alfa.
Here is a more extended ping test with the Cudy and
Terow NICs, from both the server and the laptop. They were 1.7M apart, so no
issues with interfering stations. The tests were done simultaneously, i.e.
starting a few seconds apart, so unrecognized adverse events in the aether
would affect both equally. Command line: ping -4 -c 100 jacinth (or xena).
Outcome for both: 100 packets sent and received, none lost. Times are in
milliseconds, and N pkts xx ms
means that N packets (of 100) had a round
trip time of xx msec or longer. So 1 pkts
shows the slowest packet,
and 100 pkts
shows the fastest one. Outcomes:
| Cudy (RTL8812BU) | Terow (Mediatek mt7612u) | ||||||
|---|---|---|---|---|---|---|---|
| Upload | Download | Upload | Download | ||||
| Pkts | msec | Pkts | msec | Pkts | msec | Pkts | msec |
| 1 | 121 | 1 | 179 | 1 | 19.4 | 1 | 230 |
| 2 | 21.3 | 12 | 100 | 12 | 7.22 | 12 | 201 |
| 20 | 8.06 | 20 | 89.7 | 20 | 5.97 | 20 | 178 |
| 40 | 6.01 | 40 | 69.8 | 40 | 5.11 | 40 | 127 |
| 60 | 4.61 | 60 | 50.7 | 60 | 4.58 | 60 | 91.3 |
| 80 | 4.46 | 80 | 30.0 | 80 | 4.48 | 80 | 59.1 |
| 88 | 20.1 | 97 | 3.56 | 96 | 30.6 | ||
| 100 | 3.08 | 100 | 2.88 | 100 | 1.20 | 100 | 2.19 |
Normally I use OpenVPN (1194/udp) from the laptop (a routing issue, not for security). There is no reliability layer for OpenVPN UDP i.e. OpenVPN does not detect and retransmit lost bearer packets, as it would when using TCP. (802.11 mandates detection and retransmission in the Wi-Fi firmware.) I repeated the ping test with OpenVPN running. (Data not shown.)
With and without OpenVPN, the results were generally similar, with quite a lot of random variation. I doubt that the extra latency to en/decrypt the data is noticeable.
It's surprising that times for download were consistently a lot longer than for upload, since a ping transaction requires one packet in each direction. Perhaps -- I'm speculating here -- the AP has a compulsion to hold up a packet for a new connection until just after the beacon, because that's when a power-frugal station would be listening for it, whereas this particular station (or stations in general) are allowed to start sending at any time. Whereas the AP responding to a station may be allowed to reply within a short time after an incoming packet, because the station is expected to keep the radio on for a certain time.
Long latency does not slow down the upload-download test; the kernel driver for TCP expands the sliding window until either the speed of the data source or sink is exceeded, or the network is saturated (our case). But the window will just be bigger if the latency is long, similar to an intercontinental connection.
In this set of tests, I see under 1% (I think more like 0.5%) of the packets being lost and retransmitted, vs. a lot more from the Alfa NIC.
I had a two hour session on Apple's FaceTime using
the Cudy NIC, and another with the Terow. The calls were perfect
in
that I noticed no pauses or dropouts, neither single packet delays nor
kickoff-reconnect cycles, and neither did my partner. I also did a 2.5 hour
Zoom session with the Cudy (church service, mixed music and speech/video). I
spotted four delayed packets during music, but none during speech where they
are hard to detect, and again no kickoff events. Repeating with the Terow I
detected no delayed packets. The Terow did best in actual use, and the Cudy
was almost as good; both are very much better than the Alfa NIC. So the
upgrade has been successful.
It was suggested to me, Why don't you
save yourself all this trouble and buy a commercial router. That's what
everyone else does, and they don't have packet dropouts when I do Zoom meetings
with them.
I gave it serious consideration, but finally thought better
of it: I want a lot of features, and to get them I'm going to have to
essentially lobotomize the router and turn it into a fancy desk dock for the
Wi-Fi chipset. Here are the features:
Making (most of) these features happen on a commercial router is possible but would be a lot of error-prone work. So I'm reluctant to give up what's working for me now.
Another issue is, how is the networking going to be arranged? The present net in Jacinth's cabinet goes like this: Hostapd runs on Jacinth and the local Wi-Fi NIC (rad0) is a member of the bridge br0. The onboard 802.3 NIC en0 is also a bridge member, as well as VM Claude's vnet0. The wild-side NIC en1 (USB) is separate. en0 has a short Ethernet cable to a mini-hub (5 ports, Linksys), which bridges between Jacinth en0, Toucan (VOIP), the MOCA net, and an extra Ethernet cable (for setting up new computers, or running my laptop on 802.3).
For security, traffic into Jacinth (and each other Linux box) has to have a registered MAC address. Thru traffic is not restricted, e.g. from a random guest over Wi-Fi through Jacinth to the wild side.
With the proposed Wi-Fi router appliance, hostapd would be shut down, and
the new router would be connected to the mini-hub. Another possibility is a
new USB NIC on Jacinth that connects to the appliance and, presumably, is a
member of br0. This is more complicated with no security benefit (with the
current design), but it's an idea if I rearrange the net to have a true
DMZ
subnet.
The Cudy performed well, but there is one fly in the ointment: the driver. I'm going to need to recompile it on every kernel update, and with OpenSuSE Tumbleweed this happens at least once a week. And I'll always wonder whether the driver will compile at all; after one upgrade it didn't and I had to revert to the Alfa. A familiar spirit nagged me that I should read all the information available to me, specifically morrownr's USB_WiFi writeup. Here's a very, very brief summary emphasizing the areas bothering me:
regularly change chipsets while keeping the same model number on their products.
So I am going to search for yet another Wi-Fi NIC that uses a Mediatek chipset. Targeting the Mediatek mt7612u/mt7612un chipset for AC1200 or 1300, USB-3, 2.4 and 5GHz. Reviewer Nick (in morrownr's writeup) praises the Alfa AWUS036ACM 802.11ac Dual Band 2.4/5 GHz Mimo WiFi. But I couldn't find it on Amazon; there were lots of Alfa AWUS036AC* but the last letter (the *) denotes a variant, and the only variants on Amazon use the RTL8812BU chipset, which is the one I'm trying to get away from.
An alternative, also reviewed favorably by Nick, is the Terow ROW02FD (details above). This is the one I got.
The Terow NIC has a physical WPS button. I have some guests (vaccinated,
and so are my family) coming to visit, and I figured it would be a nice
convenience to get WPS working on hostapd running on the Terow NIC. To make
a long story short, I found this
article on Android Police about WPS by David Ruddock, 2018-07-18.
To summarize: Android P lacks support for WPS. It was removed for what Google
called security issues
. Due to the use of PINs it is vulnerable to brute
force attacks, and PIN mode is required to be enabled. In response to a roar
of customer complaints, Google is said to be doing something unspecified about
WPS.
Jimc's experience: Android Q also lacks WPS and there's no sign in Google searches of any substitute or security mitigation anywhere in Android. Similarly for iPhone, articles dated 2016, 2018 and 2020 say it does not support WPS.
I may have gotten WPS working in hostapd (no possibility to actually connect using it), but given the security issues and the lack of support in mobile operating systems, I removed WPS configuration from my hostapd configuration file.
There are multiple versions of the driver for the RTL8812BU chipset. The Cudy's sales pack includes a mini CD with a Windows driver and Linux source code, but forum posters indicate that it is hard to compile for a recent kernel.
One search hit on Github is https://github.com/fastoe/RTL8812BU. The README says that this will probably be the last version because another driver has come out that has more features (no AP mode here, jimc can't use it) and closer integration with recent kernels.
The driver I used successfully was https://github.com/morrownr/88x2bu. From the README:
does not work well, P2P-client, P2P-GO (peer to peer or
Wi-Fi Directstation or elected access point)
Single/Multi State: Some NICs, not including the Cudy, can get into mass storage state and make available a Windows driver. Install and use usb_modeswitch (SuSE name, also try usb-modeswitch) to flip it to application mode. Many modern distros set this up to happen automatically.
Here's Jimc's summary of the installation instructions:
I spotted this on Amazon: HiLetgo VK172 G-Mouse USB GPS/GLONASS USB GPS Receiver, $12.99 SB Hiletgo FBA. From spec sheet: Ublox 7020 chip. It alleges timing accuracy of 1 microsecond (so how does it export time marks?) From the questions: 3 people report using it for time sync, 2 on Windows and 1 on Raspberry Pi. The latter suggests Youtube videos about the dongle by Jason KM4ACK and by Julian OH8STN. (2020-08-25) From reviews: It acts as a serial tty (/dev/tty/ACM0) and emits NMEA sentences. It's fatter than USB specs so you may need to put it on a short extender cable or on a table dock.