Ubuntu
screen package

WireGuard fails to provide Internet after upgrade from 5.4.0-1026-raspi to 5.4.0-1028-raspi; screen 4.8.0-1ubuntu0.1 (Update: NOT) at fault

Asked by juanejot

Initial problem:
Upon upgrading:
a) from kernel 5.8.0-43 to -44 on an Ubuntu Server 20.10 (on an AMD EPYC CPU), as well as
b) from aarch kernel 5.4.0-1026-raspi to 5.4.0-1028-raspi on a local Raspberry Pi 3 running Ubuntu Server 20.04,
(Both of which upgraded by apt-get update, then apt-get full-upgrade)
Wireguard stopped working on either installation: clients will connect & the server shows their status with “wg show,” but no Internet data gets sent by the server ("transfer: [several] KiB received, [92 or 184 or 220] B sent,” over the course of several minutes, with no ability to visit any website).

All clients still connect to & can use Internet from commercially (non-self-) maintained Wireguard servers, so it’s not on any of my clients’ ends, and there have been no config changes on any of my clients. Removing & reinstalling wireguard & wireguard-tools from my servers, messing around with .conf files (I could bore you with the details, but you’re Ubuntu, not wireguard) does not seem to help, even (when installed) with the wg-quick@wg0 daemon definitely active on both systems, says systemctl.

Partial (intermittent, amd64-only) resolution:
An update to the package “screen” (from version 4.8.0_2 to 4.8.0_2ubuntu0.1_amd64.deb) on the 20.10 server seems to have resolved the issue.

Unfortunately, apt-cache policy seems to show that “screen” on the aarch version on my Pi remains at 4.8.0-1ubuntu0.1 today, with the same bad behavior. Hopefully the aarch and/or raspi ubuntu-ports repo gets updated soon!

Thanks for any insight you can share!

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu screen Edit question
Assignee:
No assignee Edit question
Solved by:
juanejot
Solved:
Last query:
Last reply:
Revision history for this message
Manfred Hampl (m-hampl) said : 		#1

screen version 4.8.0-2* is available only for Ubuntu 20.10, Ubuntu 20.04 has version 4.8.0-1*
This explains the difference in version numbers between your amd and rpi ssystems.

Revision history for this message
juanejot (juanejot) said : 		#2

Thanks for your reply. Perhaps my original question was unclear; matching the version number of screen between different installations on different system versions doesn’t matter to me. Instead, I upgraded separate kernel versions on each system, and wireguard Internet throughput to/from clients got cut off on both systems. Subsequently, I observed that an automatically available version number change for screen on Ubuntu Server 20.10 (on amd64) was concurrent with (may have caused) a return of normal wireguard functionality on that platform. This observation made me wonder whether a similar update to the screen package on Ubuntu Server 20.04 (via the ubuntu-ports repo on aarch/raspi) might contribute to restoring normal wireguard functionality on my other installation, as well?

It’s certainly possible that the update of the screen package is not responsible for wireguard’s return to proper function on Ubuntu Server 20.10 (on amd64). But an upgrade of the screen package is the only thing that changed on that server before function was restored. An update to the screen package has not yet been made available to Ubuntu Server 20.04 (via Ubuntu-ports on aarch/raspi), and wireguard functionality there is still broken.

Perhaps an upgrade to the screen package would be unrelated to wireguard’s behavior, but given my above experience, it currently has at least the appearance of correlation.

If an update to the screen package itself would not help restore wireguard functionality, is there a .conf file for screen that someone might suggest I make changes to on my 20.04 server? I have been unable to find such a .conf file inside any sub folder of /etc on either system, but perhaps it resides elsewhere?

Can anyone say categorically that an upgrade or configuration change to screen will definitely not restore wireguard functionality, and I should look elsewhere?

I’m just looking for a way to get both of my installations back to working normally. Thanks for any insight!

Revision history for this message
Manfred Hampl (m-hampl) said : 		#3

I am no expert in such networking matter, I can only make general suggestions that might help identifying the culprit and/or a solution:

You wrote, that this problem may have started after a kernel upgrade.
What happens if you reboot and select an older kernel from the grub menu, does it work or fail as well?

You assume that an upgrade of screen to version 4.8.0-2* may solve the problem.
There is the possibility to download the deb package version 4.8.0-2* for Ubuntu 20.10 and manually install it on Ubuntu 20.04.
It might be worth trying, to verify whether this helps.

Which config file are you looking for?
They should be in /etc/wireguard/ respectively for screen should be inside your home directory named .screenrc

Revision history for this message
juanejot (juanejot) said : 		#4

Unfortunately, I’ve never seen a grub menu on either of these servers; the 20.10 amd64 one is virtualized off-site, and the 20.04 one is on a Raspberry Pi 3. While I’ve seen a grub menu as part of the startup process for non-server local installations of Ubuntu 20.04/20.10 on amd64, I haven’t seen it on either of these server configurations; I just receive an email once the virtualized off-site server has booted back up, and the Raspberry Pi boot process for for its ubuntu-ports version shows nothing that looks like the grub menu during the boot process.

If you’re suggesting I manually download a separate copy of the screen package to test on my local 20.04 RPi server, I could try that. My original question was just about whether there might be plans to make similar updates to screen on aarch-raspi for 20.04 as seem to have happened on amd64 for 20.10. I’d be happy to test a different .deb package if you suggest it, but is that the expected path for researching an update to the ubuntu-ports repo for the screen package on aarch/raspi?

I was looking for the screen configuration file, yes, as the wg0.conf file on either server hasn’t changed, and yet wireguard is working again on 20.10. Thank you for the location/name of .screenrc; unfortunately, neither of my systems appears to have generated such a file in the home directory of any user.

Thanks for your help so far!

Revision history for this message
Manfred Hampl (m-hampl) said : 		#5

The update of a package (e.g. screen from version 4.8.0_2 to 4.8.0_2ubuntu0.1) happens for all architectures of an Ubuntu release at the same time.

All architectures of Ubuntu 20.10 now have screen 4.8.0-2ubuntu0.1
All architectures of Ubuntu 20.04 now have screen 4.8.0-1ubuntu0.1 (if they have all available updates installed).
This has nothing to do with aarch or the ports repository server.

If the screen packages in Ubuntu 20.04 should be updated to 4.8.0-2* to solve a problem, then this has to undergo a strict procedure (SRU - stable release upgrade, see https://wiki.ubuntu.com/StableReleaseUpdates )

Revision history for this message
juanejot (juanejot) said : 		#6

Thanks for the dedication to getting my question answered so far. The resolution ended up having nothing direct to do with the screen package: It seems an extra rule I had added for dnsmasq to listen on wg0 had somehow gotten deleted upon upgrade, even though I put it in a separate .conf file. Setting up a new .conf file fixed it.