Vero 4K+'s wifi performance inferior to Raspberry Pi

Help and Support
1

My Vero 4K+'s wifi performance is a lot worse than my Raspberry Pi 3 B+. The Vero seems stuck on using 802.11n, absolutely incapable of using 802.11ac features such as 5GHz or even 256-QAM modulation at 2.4GHz.

My Raspberry Pi can easily play original BD rips from a local NFS file server, including high-bitrate files nearing 40-45 Mbps. The Vero exhibits constant video stuttering.

As a test I put the Vero, the Raspberry Pi (also running OSMC), and my laptop all 2 feet away from a wifi access point sitting on a table. I have a pretty solid wifi setup: multiple Ubiquiti access points (UniFi AP AC Lite) configured to use a 40MHz VHT channel at 5GHz and a 20MHz HT channel at 2.4GHz. I ran benchmarks piping /dev/zero through netcat to test the raw TCP throughput from the NFS server:

  • My laptop achieves 270-290 Mbps.
  • The Raspberry Pi achieves 90-100 Mbps.
  • The Vero barely sees 35-40 Mbps.

My access point’s management interface tells me the Vero is stuck at 2.4 GHz while the Raspberry Pi and laptop are happily on 5 GHz, see screenshot (“osmc” is the Raspberry Pi and “vero” is the Vero):

stats
stats2016Ă—145 37.9 KB

The negotiated rates (in Mbps) are:

  • Raspberry Pi: rx=150, tx=200
  • Vero: rx=65, tx=72.1

Comparing these rates with http://mcsindex.com tells us that the Raspberry Pi uses the best modulation scheme 256-QAM 5/6 for tx (which I sometimes see for rx as well although it’s not the case in that particular screenshot) while the Vero is stuck using 64-QAM 5/6 (800 ns GI on the downlink and 400 ns SGI on the uplink.)

These inferior rates are confirmed locally on the Vero with “iw” showing a tx rate of 72 Mbps (rx rate isn’t shown presumably because the Vero’s kernel and toolset are so old–both kernel and iw are 4-5 years old–that I think the rx rate info API isn’t present):

$ iw wlan0 link
Connected to 80:2a:a8:xx:xx:xx (on wlan0)
        SSID: <edited>
        freq: 2437
        signal: -26 dBm
        tx bitrate: 72.0 MBit/s

How can the Vero’s wifi performance be trounced by a 35 USD Raspberry Pi?

Trying to investigate a bit, I found the Vero uses the AP6255 Wifi chip which in theory is compatible with 802.11ac, 256-QAM, and 5GHz [1]. It’s probably a kernel/driver/firmware configuration issue that is hampering wifi performance. The outdated 4-year-old 3.14.29 kernel certainly suggests that. I was hoping to not have to run a network wire to the Vero, well I see no other solution at the moment.

[1] http://files.lindeni.org/lindenis-v5/datasheets/AP6255%20IND%20datasheet_V1.1_12042017.pdf

For reference I included some information about the Vero here (uname, packages, wireless info reported by iw, dmesg):

2

Looking more into it, “iw list” reports for Band 2 (5GHz): HT20. For comparison, both the Raspberry Pi and my laptop report HT20/HT40. This means the Vero 4k+ wlan0 driver claim to not support 40MHz channels, and that’s why it doesn’t pick my 5GHz network.

However this is in direct contradiction with the AP6255 datasheet which claims 20, 40, 80 MHz are all supported by the hardware. Is the driver or firmware misconfigured?

3

Are your 5 and 2.4 networks named identically? If so, try naming the 5Ghz to your.ssid-5 and connect specifically to that network with your Vero.

4

It sounds like OP hasn’t got separate names for his WiFi hotspots.

Depending on the environment, the 2.4Ghz band is likely being favoured over 5Ghz. This can either be adjusted in wpa_supplicant or ideally by connecting to the 5G SSID individually.

Real word performance of the 802.11ac adapter will give you 200Mbps, which is a little above double what you can expect from the Pi 3 B +

Also worth confirming your region.

Sam

5

Correct, I use the same SSID on both 2.4 and 5GHz (standard practice for enterprise-grade APs like my Ubiquiti gear). I should have tested a 5GHz-only SSID but didn’t. Just tried now and sure enough, the Vero connects to it and the throughput is much improved (140 Mbps).

The fact it doesn’t automatically select 5GHz when it’s clearly a better signal is still a problem though. As soon as I re-enabled my 2.4GHz network, the Vero switched back to it right away and the throughput dropped to 35-40 Mbps… All my other devices (phones, laptops) are able to select the better band dynamically and automatically.

6

It depends how you define better band.

CFG80211 spec mandates picking the best signal; as 5Ghz can be nominal through walls. 5Ghz doesn’t always guarantee better throughput.

I believe you can force 5Ghz band through wpa_supplicant however.

Sam

7

I was under the impression that it was the AP that decides whether a (dual-band) client gets placed on 2.4 GHz or 5 GHz – assuming that the AP has band steering.

Just out of interest, had you enabled band steering on the access point? I did a quick search and it seems that this function wasn’t always on the UniFi AP AC Lite: https://community.ubnt.com/t5/UniFi-Wireless/Band-Steering-not-an-option-UAP-AC-Lite/td-p/1774557

Also something about the possible band-steering settings, that might be relevant: https://community.ubnt.com/t5/UniFi-Wireless/Band-Steering-Settings/td-p/1429904

8

When using the same SSID on both channels my experience shows the client device selects the band based on RSSI values. In pretty much every circumstance that means devices will choose 2.4Ghz rather than 5Ghz. Clients consider “better” to be more stronger/more reliable signal rather than faster connection speeds.

“Band steering” is a bit of a fudge (that is why its not enabled by default on UniFI AP) where the AP temporarily disallows the client device from associating on the unfavoured band. Some clients will then try to associate on the other band. Some clients will just keep trying to associate (and fail) on the same band. There is no standard specification on how to handle hence its consider a bit of a fudge.

The only way to guarantee is to use different SSID names as mentioned above. They can have the same password. If you want clients to use both networks then bear in mind clients tend to connect to Wifi networks in last added order. So when adding new devices to your network, connect to the 2.4G first then the 5G next. That way clients will connect to 5G as first preference then connect to 2.4G if signal is not strong enough.

I also use UniFi AP. If you want to stick with the same SSID name an alternative (non-guaranteed) way is to reduce the power output for the 2.4G signal on the AP. If you drop it to be -6dbm and -9dbm below 5G power output then client devices will probably favour the 5G signal over 2.4G on a like-for-like basis.

Observations from your screenshot.

Signal levels are very high. Assume both devices are very close to AP. High power levels can saturate the receiving circuitry on the client devices.
Are you in the UK? Channel used for 5G is not within the “norm”. I use this as a good reference guide. Source: Wifi Nigel
With the channel not in the “norm” range perhaps the Vero is being more conservative than other devices?

2 Likes
9

I would recommend leaving “advanced features” off (what turns on band steering) and instead just update your controller and use the new “auto-optimize network” feature and see if that gets you where you need to go.

I also echo the access point being way too close in your testing. That AC-Lite is not designed to be used that close. You might also have better luck if you turn the power level of the 5ghz down to med or low.

I would also try using the “reconnect” button in the clients list for any troublesome devices. The AP’s sometimes seem to get latched on with certain settings and a device reboot does not always get it to change.

10

I have not enabled band steering on my AP, so the client (vero) is the one who decides which band to join. My screenshot shows a very strong signal because I was doing tests with the Vero only 2 feet away from the AP. Anyway, I tried something new:

  • I reconfigured my AP to advertise my SSID on both 2.4 GHz and 5 GHz
  • I edited /var/lib/connman/wifi_xxx_xxx_managed_psk/settings and removed the “Frequency=2437” line. I am not sure if what I did is useful because AFAIK this file is just for connman to store wifi information, but when it reads the file to configure wpa_supplicant over the D-BUS AddNetwork API, it essentially just passes the SSID and passphrase and ignores Frequency - Frequency “is used to configure the initial channel for IBSS (adhoc) networks. It is ignored in the infrastructure mode” according to https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf
  • I went back to the Vero’s setting to “disconnect and forget” my wifi, then I re-joined the network
  • Now for some reason the Vero picked 5 GHz automatically

I then moved the AP back to its original place (20 feet away from the Vero, in a different room) and even though the 5 GHz signal quality is now a bit worse than 2.4 GHz, when I reboot the Vero it still picks 5 GHz:

# wpa_cli -i wlan0 scan
OK
# wpa_cli -i wlan0 scan_results
bssid / frequency / signal level / flags / ssid
80:2a:a8:xx:xx:xx      5785    -56     [WPA2-PSK-CCMP][ESS]    <my-ssid>
82:2a:a8:xx:xx:xx      5785    -56     [WPA2-PSK-CCMP][ESS]    guest
82:2a:a8:xx:xx:xx      2437    -48     [WPA2-PSK-CCMP][ESS]    guest
80:2a:a8:xx:xx:xx      2437    -49     [WPA2-PSK-CCMP][ESS]    <my-ssid>
# iw wlan0 link
Connected to 80:2a:a8:xx:xx:xx (on wlan0)
        SSID: <my-ssid>
        freq: 5785
        signal: -59 dBm
        tx bitrate: 108.0 MBit/s

My 5 GHz channel (5785 MHz) is standard and legal where I live (USA). I checked the regulatory domain of the Vero and it seems unset/global:

# iw reg get
global
country 00: DFS-UNSET
        (2402 - 2472 @ 40), (6, 20), (N/A)
        (2457 - 2482 @ 40), (6, 20), (N/A), PASSIVE-SCAN
        (2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN
        (5170 - 5250 @ 160), (6, 20), (N/A), PASSIVE-SCAN
        (5250 - 5330 @ 160), (6, 20), (N/A), DFS, PASSIVE-SCAN
        (5490 - 5730 @ 160), (6, 20), (N/A), DFS, PASSIVE-SCAN

I am not sure if wpa_supplicant even considers the regulatory domain when choosing the band to join. Apparently not because my channel falls outside any of these ranges.

My UniFi AP AC Lite have very standard configurations. I set the 2.4 Ghz channel to channel 6, but pretty much anything else is default (no band steering, no advanced feature, etc.)

11

Can’t help with an explanation but at least it’s the result you wanted!

The difference of the signal levels between 2.4Ghz and 5Ghz networks is what I would expect. Looks like it’s all working correctly.

12

Yes the Vero is consistently choosing 5 GHz now, which is good. It’s very strange it was refusing to do so earlier, given that nothing significant changed.

I looked into wpa_supplicant’s source code to inspect the logic deciding which BSS (2.4GHZ or 5GHz) to associate with.

wpa_supplicant appears to initially sort the BSS by a combination of signal level (dBm), estimated throughput (kbps), while favoring 5 GHz, and based on “quality”, as per the logic in wpa_scan_result_compar() at scan.c « wpa_supplicant - hostap - hostapd/wpa_supplicant

Then, as signal levels change over time, wpa_supplicant periodically decides to roam to another BSS based on logic in wpa_supplicant_need_to_roam(): events.c « wpa_supplicant - hostap - hostapd/wpa_supplicant and there are 2 different possibilities:

  1. Either wpa_supplicant selects the BSS based on logic in this function to look at (a) estimated throughput (calculated by scan_est_throughput(): scan.c « wpa_supplicant - hostap - hostapd/wpa_supplicant), then (b) signal level in dBm. The code does favor 5GHz even if the level is slightly worse than 2.4GHz. Note that this logic is similar, but rather different than wpa_scan_result_compar() !

  2. Or BSS selection is handed off to the driver (if wpas_driver_bss_selection() at wpa_supplicant.c « wpa_supplicant - hostap - hostapd/wpa_supplicant returns true) aka driver-based roaming

Perhaps the Vero is using buggy driver-based roaming? I’ll look into it further.

13

I’m doubtful.

Keep in mind that we don’t use top of tree wpa_supplicant; which is what you seem to be inspecting, but rather Debian Stretch’s version of wpa_supplicant.

If you can ascertain that there is indeed an issue with the driver, then I’m more than happy to look in to it more closely.

Latest driver: vero3-linux/drivers/amlogic/wifi/bcmdhd at master · osmc/vero3-linux · GitHub. There are newer upstream versions but they have their own issues.

Sam

14

Update after 3 months:

The Vero 4K + has mostly stayed on 5GHz, however there were multiple days where it inexplicably fell back to 2.4GHz and stuck there even after a reboot. Very annoying since 2.4GHz doesn’t give it enough bandwidth to play BD rips.

I don’t have time to investigate further why wpa_supplicant selects 2.4GHz over 5GHz. It’s even more puzzling because all my other devices (phones, laptops) stayed on 5GHz while the Vero was on 2.4GHz. At this point my theory is that the Vero probably has an antenna that’s not as good as my other devices.

So I forfeited the idea of using WiFi, and wired it to gigabit Ethernet.

15

I think this issue is solved in newer versions of the supplicant which will be made available when we switch to Debian Buster

1 Like
16

Since I ran into the same problem let me add my findings:

  • From my tests wpa_supplicant 2.9 in contrast to the system wpa_supplicant (v2.4) brings better performance at 2.4 GHz but still typically prefers 2.4GHz over 5GHz in my case. 5GHz still performs much better overall.
  • When checking the scan_results with wpa_cli -i wlan0 then often the tool only reports my 2.4GHz network at first and not my 5GHz network. Only after issueing another scan the 5GHz network is reported. This (and the wpa_supplicant finding below) leads me to believe that the wlan driver initially returns cached results.
  • I could not find any connman settings to prefer 5GHz over 2.4GHz.
  • I managed to come up with some wpa_supplicant config which reliably selects the 5GHz network:
	ctrl_interface=/run/wpa_supplicant
	ap_scan=1
	ignore_old_scan_res=1
	freq_list=5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700

	network={
		# for hidden networks: #scan_ssid=1
		ssid="..."
		key_mgmg=WPA-PSK
		psk="..."
	}
  • ignore_old_scan_res=1 seems to be essential.
  • I compiled the list of frequencies from the web ui of my access point. Yours might differ.
  • Now to actually get wpa_supplicant to run I wrote the above content to /etc/wpa_supplicant/wpa_supplicant.conf and then while being connected via eth execute:
$ killall wpa_supplicant
$ /sbin/wpa_supplicant -iwlan0 -s -B -c/etc/wpa_supplicant/wpa_supplicant.conf
$ # For debugging: /sbin/wpa_supplicant -iwlan0 -s -dd -c/etc/wpa_supplicant/wpa_supplicant.conf
  • Checking iw wlan0 link should then consistently report the 5GHz network.
  • I also tried to make this persist between reboots but unfortunately failed. I tried to modify /lib/systemd/system/wpa_supplicant.service and remove the -u switch (no dbus interface), add -iwlan0 and add -c/etc.... I then deactivated wifi in the /var/lib/connman/settings. But this then resulted in wpa_supplicant complaining about a missing p2p device or that it cannot read the interface wlan0 or things like that (check journalctl -u wpa_supplicant). If anyone has some ideas on how to persist the wpa_supplicant settings please let me know.
17

I admit that I’ve (briefly) looked into this in the past and didn’t have much success. Connman and wpa_supplicant are joined together by dbus and separating them isn’t that easy.

Did you leave Type=dbus in the .service file?

18

Before we embark on preferring 5Ghz over 2.4Ghz by default, did you verify performance over 5Ghz only via an iperf test?

Your feedback only shows attempts to favour 5Ghz but it’s unclear if you’ve actually connected to such a network and can confirm a performance improvement

Sam

19

Ok here are the performance measurements obtained by wgetting an Ubuntu 18 iso:

wget http://releases.ubuntu.com/18.04.4/ubuntu-18.04.4-desktop-amd64.iso

  • wpa_supplicant v2.4 at 5 GHz: Stable at around 4.4MB/s (second try: 5.7MB/s)
  • wpa_supplicant v2.4 at 2.4GHz: Varying between 0.4MB/s and 0.9 MB/s (second try: 0.2MB/s and 0.6MB/s)
  • wpa_supplicant v2.9 at 5 GHz: Stable at around 5.8MB/s
  • wpa_supplicant v2.9 at 2.4GHz: Varying between 0.5MB/s and 1.1MB/s

So the 2.4GHz network is considerably worse with wpa_supplicant v2.4 as well as v2.9 in comparison to the 5 GHz network. This is also noticable in the user interface in terms of waiting times until streaming videos load. The self-compiled wpa_supplicant v2.9 seems to marginally improve the 2.4 GHz performance. The 2.4 GHz performance is unstable (constantly varying).

In order to make things persist I had to perform the following steps (please do that at your own risk and with wired access):

  • Disable WiFi and P2P in /var/lib/connman/settings.
  • Write the wpa_supplicant config from my last post to /etc/wpa_supplicant/wpa_supplicant-wlan0.conf.
  • Make sure it is owned by root and cannot be accessed by others: sudo chown root:root /etc/wpa_supplicant/wpa_supplicant-wlan0.conf && chmod o-rwx /etc/wpa_supplicant/wpa_supplicant-wlan0.conf
  • systemctl enable "wpa_supplicant@wlan0.service".
  • Remove wpa_supplicant.service from the After= line in /lib/systemd/system/connman.service.
  • Backup and remove fi.epitest.hostap.WPASupplicant.service and fi.w1.wpa_supplicant1.service from /usr/share/dbus-1/system-services/ (those are installed by the wpa_supplicant package in case you didn’t do the backup).
  • sudo apt install dhcpcd5.

After rebooting iw wlan0 link should report a 5 GHz frequency and ifconfig wlan0 an IP.

In case things go wrong check journalctl -u wpa_supplicant@wlan0. If you get errors like

Successfully initialized wpa_supplicant
rfkill: WLAN soft blocked
Failed to create interface p2p-dev-wlan0: -19 (No such device)
nl80211: Failed to create a P2P Device interface p2p-dev-wlan0
P2P: Failed to enable P2P Device interface

then sudo apt install rfkill and sudo rfkill unblock wifi. Then check rfkill list whether all wifi devices are unblocked again before sudo systemctl restart wpa_supplicant@wlan0.

Please let me know if the steps above can be boiled down and whether they work for you.

20

I would recommend using iperf and not wget which is dependent on an external internet connection.

Further, your internet connection doesn’t seem fast enough to max out the potential throughput of the device