Rock Pi 4, below-par Wifi connectivity, latency & openSSH

#1

Hi,

Just a quick entry to check if others are observing the same (will add troubleshooting data later)
I’m running a Rock Pi 4 (1.3 hw) with the latest Ubuntu Server image, and I’m planning to use
it headless. The board is connected via WiFi, the router is located on the same floor (i.e. well within an acceptable distance, i.e. more or less optimal conditions)
In AC mode, the connection is not stable at all …a ping to the gw will show highly variable RT-delays, and the connection drops.
in 11n mode, the connection remains up, but an active SSH session to the board (openssh-server) shows very bad “reactivity” … characters entered will not be echo’d for several seconds (especially after some idle time) etc, something which is typical for frameloss & retransmissions … …I never observe this on a Raspberry Pi, connected over the same Wifi network & located even further away.
Does anyone observe the same ?

#2

Hi, PDM

try

sudo iwconfig wlan0 power off

#3

You can edit the following file to permanently disable wifi power management.

/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

Just change it to a value of 2.

#4

Ok, many thanks Setq, I’ll give it a try !

Br

Patrick

#5

I’ve spend quite some time on this, but I’m afraid the persistent-approach doesn’t seem to work in Ubuntu 18.04 … disabling power-save via CLI (after full boot) always works, but setting the value in the .conf file doesn’t have any effect after reboot … I’ve also tried to put the cli cmd in rc.local (after a sleep of 10s) … no luck either. I’m out of ideas on this one.

1 Like
#6

Radxa team, any comments ?

#7

Create a file named wifi-powersave-off.conf and put it under /etc/NetworkManager/conf.d/, and the file contents are as follows,

[connection]
#Values are 0 (use default), 1 (ignore/don’t touch), 2 (disable) or 3 (enable).
wifi.powersave = 2

reboot.

#8

Thanks setq, I tried several approaches/solutions I found on the web, including this one I think, without result … I will try again & let you know.

Br

Patrick

#9

Sorry, same result I’m afraid … some help from the radxa team would be appreciated here.

#10

I’m now by the way booting from NVMe (and SPI Flash), using the debian image …
I’m starting to regret this purchase … Wasn’t expecting to buy into a DIY-project.

#11

I’ll take a look at it later.

#12

Hi, any conclusion on this elusive wifi power issue ?

#13

Bump … Still an issue … radxa team ?!

#14

Are you using 2.4Ghz wifi or 5Ghz wifi?
You could have an interference with other devices. Try changing the frequency band of your router. If too many devices use the same frequency things go bad. Certainly when many people live close.

Also USB3 devices give interference with 2.4Ghz wifi. And I’ve even seen hdmi cables interfering with it.

I’m not sure if this is your problem. Try using a wifi dongle and see if it is the same effect. It often helps to use a usb extension cable to place the dongle far enough so no interference from the board occurs?(OdroidN2 needs that, now why wouldn’t there be wifi on the N2???) Or switch from 5Ghz to 2.4Ghz if you can to see if that makes a difference.

The wifi of the RockPi4 isn’t the best since there’s no big antenna. But for me it works fine while there’s a floor between my RockPi and my rooter. Connection is only midrange. But haven’t got too many problems.
With a big USB3 wifi dongle/antenna I’ve got great reception.

#15

Sorry I forgot about it. I will solve the problem in the next few days.

#16

Thanks Nico for your input on this issue, but it’s not about interference or antenna design … it turns out that the power-save mode is always being enabled for the wifi interface, which leads to increased latency and highly variable RTT’s … normal methods to disable this power-save persistently don’t seem to be working on this board/distro, hence this forum entry.

1 Like
#17

That would be good, thanks.

#18

Add the following line into /etc/rc.local file ( above the ‘exit 0’ line)

(sleep 15 && iwconfig wlan0 power off) &

I don’t think it’s the best solution, but it just worked for me. If I find a better solution later, I’ll let you know.

Wifi Dropouts after short periods of time
#19

Thanks Setq, I will give it a try, but I think I already attempted this workaround … I will try again, but it would be good if you could locate the real rootcause of this issue …

Regards

P.

#20

The Wifi on mine completely craps itself after a certain amount of time. It will work at first, then if it’s allowed to sit without actively being used, it will start spewing “firmware trap in dongle” messages then just completely die and flood dmesg with complaints. (5.4.1 mainline kernel)

1 Like