Trying to get a sleepy network adapter to wake up faster
The wifi connection with ath9k on Trisquel Aramo (MATE) seems to have developed an oversleeping problem. Whenever the connection has not been actively used for a while, it takes a perceptible amount of time to connect, at least 10s. The delay is even longer at startup and after resuming from suspend, about 30s, at times triggering email client timeout.
As if the network adapter had to be activated or re-activated, and was waiting for something to be set up in the background or to timeout before accepting connections. Not sure where to look to find out what it is waiting for. The connection works just fine otherwise, once it is up.
After various attempts at tweaking powersave options, it transpired that restarting NetworkManager.service also triggers a 30s delay.
According to various sources, the problem could also be caused by some unusual router configurations, so this would need to be tested with a different network. I have no recollection of such delays in other locations, using the same Aramo install on the same hardware.
UPDATE: I am getting no connection delays on a live gnuinos iso. Same network, same hardware.
Have you looked into setting up a tlp configuration? That's where I usually end up when I have WiFi sleep nuisances. I go into tlp configuration and turn off sleep for the WiFi card completely.
I also tried using the barbed tip of a harpoon, to no avail.
Don't do that. Eating whale blubber is bad for your cholesterol.
Do you get some details on syslog?
Any change between 11.0 and 11.0.1 LiveISOs?
Thanks for the hints. This is a fully updated 11.0 install, same behavior with a 11.0.1 live iso.
Syslog had some recurrent lines about dhcp6. Deactivating IPv6 on that wifi connection seems to have reduced the 30s delay at startup and resume to the lesser 10s delay.
UPDATE: that wifi access point was using both 2.4GHz and 5GHz, merged into a single ssid. Using a different ssid and deactivating the 5Ghz signal solved the dhcp6 issue that caused the 30s timeout.
It looks like the following syslog lines may hold a clue to the remaining 10s delay:
Grace period over, resuming full feature set (TLS+EDNS0) for DNS server
Using degraded feature set UDP+EDNS0 instead of TLS+EDNS0 for DNS server
This issue report for Aramo 11.0 has more details, and a workaround:
https://github.com/systemd/systemd/issues/27464.
I wonder if it's a local software failure or a remote DNS validation failure, meaning the external DNS is failing to negotiate a request.
"This is probably caused by providers and/or firewall setups not properly rejecting connections on port 853."
https://github.com/home-assistant/operating-system/pull/1121
Not sure how that delay could be bypassed client-side, jas's issue report is still open. The provided workaround can be applied by editing /etc/systemd/resolved.conf.d/trisquel.conf and switching from 'DNSOverTLS=opportunistic' to 'DNSOverTLS=no'. For the time being I would rather keep it on, as opportunistic as it may sound.