Quoting: Cyba.Cowboy

Quoting: tuxintuxedoIt shouldn't be. He already said that it works with other distributions, Pop! OS is the source of the problem.

Do you reckon it's possible that something went screwy during the installation of Pop!_OS, and the driver was corrupted or something? It seems awfully strange that Pop!_OS 21.10 - which is based on Ubuntu 21.10 and in its current form, doesn't really change all that much - has connectivity issues, but Ubuntu 21.10 does not...

As you get an IP address from your wifi router and that you can ping it (the repeating line displays that it got a reply from the router and how long in milliseconds it took) and also ping 8.8.8.8 and 1.1.1.1 shows that you are successfully both sending and receiving data to/from the Internet over Wi-Fi.

So the issue is the DNS resolver, that is the piece of software that turns www.gamingonlinux.com (the URL) into 69.16.242.65 (the IP address) and for some reason your DNS resolver (systemd-resolved) in Pop_OS! are having issues when trying to go over the Wi-Fi card instead of over the wired card.

Luckily you can see the log from systemd-resolved with:

 
f.ultra@Sineya:~/$ journalctl -u systemd-resolved.service --since today
mar 21 17:54:18 Sineya systemd[1]: Starting Network Name Resolution...
mar 21 17:54:19 Sineya systemd-resolved[1126]: Positive Trust Anchors:
mar 21 17:54:19 Sineya systemd-resolved[1126]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
mar 21 17:54:19 Sineya systemd-resolved[1126]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.>
mar 21 17:54:19 Sineya systemd-resolved[1126]: Using system hostname 'Sineya'.
mar 21 17:54:19 Sineya systemd[1]: Started Network Name Resolution.
f.ultra@Sineya:~/$

I added "--since today" to the journalctl so you only will see logs from today and not have to scroll through days and days of logs. Hopefully it will show what is going wrong when you connect over Wi-Fi. One tip here is to open a terminal and simply do a "sudo journalctl -f" this will make the journal log everything that happens from now on to the screen as it happens so you can then see if anything suspicious are being logged when you switch from wired to Wi-Fi and back and forth.

Last edited by F.Ultra on 21 March 2022 at 8:33 pm UTC

Quoting: tuxintuxedo

Quoting: Cyba.CowboyThis is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search Home

I am not sure what the last two lines are doing, but I have doubts about whether they are really needed.

Those two are added by NM or systemd-resolved due to other system settings. the "options edns0 trust-ad" is used if enabling DNSSEC and to allow ssh-keys to be stored in the DNS or something like that: https://bugzilla.redhat.com/show_bug.cgi?id=1878166

The "search Home" option makes the dns-resolver in glibc try both host and host.Home when trying to resolve hostnames. This is useful if you say work for company x so you have to e.g ssh to mail.x.com or server1.x.com then you can add a "search x.com" and now you only need to ssh mail and ssh server1. That feature I use extensively.

Quoting: ArehandoroWhat do you see when you go to Wi-Fi settings and select the IPV4 tab? Are DNS and Routes sliders set to automatic? Do they have any info in the boxes below?

Both are set to 'Automatic' with no IP addresses below them...

Quoting: ArehandoroWhat happens if you disable automatic DNS and enter in the box Google or Cloudflare DNS servers? (After entering the DNS servers, disconnect and connect again to your Wi-Fi)

The way to enter the servers in the box would be like this:

 
1.1.1.1, 8.8.8.8

If I use either Google or Cloudflare's IP address under the 'DNS' section (with 'Automatic' disabled), there is no change... I did not enter anything under the 'ROutes' section, which has 'Address', 'Netmask', 'Gateway' and 'Metric' fields.

Quoting: F.UltraLuckily you can see the log from systemd-resolved with:

 
f.ultra@Sineya:~/$ journalctl -u systemd-resolved.service --since today
mar 21 17:54:18 Sineya systemd[1]: Starting Network Name Resolution...
mar 21 17:54:19 Sineya systemd-resolved[1126]: Positive Trust Anchors:
mar 21 17:54:19 Sineya systemd-resolved[1126]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
mar 21 17:54:19 Sineya systemd-resolved[1126]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.>
mar 21 17:54:19 Sineya systemd-resolved[1126]: Using system hostname 'Sineya'.
mar 21 17:54:19 Sineya systemd[1]: Started Network Name Resolution.
f.ultra@Sineya:~/$

I added "--since today" to the journalctl so you only will see logs from today and not have to scroll through days and days of logs. Hopefully it will show what is going wrong when you connect over Wi-Fi.

Here's the respective output using my Wi-Fi (wireless) connection:
https://pastebin.com/tQNayHwp

And with my ethernet (wired) connection:
https://pastebin.com/UpDwB1iU

Quoting: F.UltraOne tip here is to open a terminal and simply do a "https://pastebin.com/q6tn00Nq" this will make the journal log everything that happens from now on to the screen as it happens so you can then see if anything suspicious are being logged when you switch from wired to Wi-Fi and back and forth.

Oh, I like this command... This will come in super handy in the future!

Anyway, here's the output of my Wi-Fi (wireless) connection):
https://pastebin.com/DrhrWMNj

And here's the output over my ethernet (physical) connection:
https://pastebin.com/q6tn00Nq

This last output will probably be of most help, because I changed back and forth between my Wi-Fi (wireless) and ethernet (physical) connection a couple of times...

Looks like maybe this bug? https://github.com/systemd/systemd/issues/13432

Does connecting to WiFi and then running systemctl restart systemd-resolved resolve things?

Quoting: whizseLooks like maybe this bug? https://github.com/systemd/systemd/issues/13432

Does connecting to WiFi and then running systemctl restart systemd-resolved resolve things?

Good catch and I do hope this is it, the only problem is that it appears to happen on his wired connection as well and there dns works for some strange reason.

If restating the resolver above doesn't work then I would try to simply disable the resolver and just use the router or google as the resolver. Found a full step by step guide here: https://bobcares.com/blog/disable-systemd-resolved-in-ubuntu/ , basically one disables the systemd-resolver deamon (disable simply means that it won't be launched at boot, later you can enable it again so this will not botch your system). Next they remove the /etc/resolv.conf file which is the file that tells the machine where to look for a DNS resolver, by default this is linked to a runtime generated file by systemd-resolved so by stopping that deamon, removing the file and restarting NetworkManager, NetworkManager will see that the file is not there and create it again but this time linked to NetworkManager. Likewise to get back one simply deletes the file again and then starts systemd-resolved and everything should be back to how it was before.

Quoting: whizseLooks like maybe this bug? https://github.com/systemd/systemd/issues/13432

Does connecting to WiFi and then running systemctl restart systemd-resolved resolve things?

It's uh, working. For no apparent reason, it's working since I made my post this morning. 😕

I didn't apply any updates this morning or anything (though there are some there waiting to apply, according to the Software Center), just ran the Terminal commands as noted above; but when I went to run the (Terminal) command in your post I'm quoting, I was surprised to find that my Internet connection is running perfectly!

How bizarre.

It should be interesting to see if this continues into the night / into tomorrow or if I experience the same problem tomorrow.

Whilst I'm keeping an eye on it, I'm going to have a read of that bug report and see what it contains... Ubuntu "Jammy Jellyfish" is about to drop - which means Pop!_OS 22.04 also should not be too far away - and one would hope that a bug like this has been addressed in the upcoming upgrade.

Annnd it's dead.

Quoting: F.UltraIf restating the resolver above doesn't work then I would try to simply disable the resolver and just use the router or google as the resolver. Found a full step by step guide here: https://bobcares.com/blog/disable-systemd-resolved-in-ubuntu/ , basically one disables the systemd-resolver deamon (disable simply means that it won't be launched at boot, later you can enable it again so this will not botch your system). Next they remove the /etc/resolv.conf file which is the file that tells the machine where to look for a DNS resolver, by default this is linked to a runtime generated file by systemd-resolved so by stopping that deamon, removing the file and restarting NetworkManager, NetworkManager will see that the file is not there and create it again but this time linked to NetworkManager. Likewise to get back one simply deletes the file again and then starts systemd-resolved and everything should be back to how it was before.

I get up to Step 3, but I can't seem to find the 'resolv.conf' file... It wasn't in the 'NetworkManager' directory. If I go to /etc/, there is a 'resolveconf' directory, which contains a 'resol.conf.d' under it; that directory in turn only contains the files 'base', head', original' and 'tail' in it.

If I skip Step 3, sudo service network-manager restart gives me a sudo: unable to resolve host admin-vaio-tap20: Temporary failure in name resolution error.

---

Well, well, well... Look what just popped-up on Reddit:
https://www.reddit.com/r/pop_os/comments/tl36i8/no_wifi_after_upgrade/

That looks awfully similar to my issue.

Whilst networking is not my strong-point, I think @whizse and @F.Ultra and are probably onto something with their theory that this is a bug.

I don't have a Reddit account (the few social media accounts I actually have are used exclusively for work purposes - and I'd get rid of them in a heartbeat if I could!); but if it is a bug, more eyes on the issue is a great thing, because it means a fix might not be too far away.

That's not to say you guys (and girls?) haven't been helpful. The Gaming on Linux Community has (unsurprisingly) been extremely helpful thus far and as somebody that has used Ubuntu since 4.10, I can honestly say that the Gaming on Linux Community reminds me of what the (official) Ubuntu Forums used to be like... But we're not really making any progress here, so hopefully this gets some more people to pay attention to what appears to be a bug.

Of course, if it turns out to be confirmed as a bug or some update fixes it, I will definitely be sure to post back here...

Last edited by Cyba.Cowboy on 24 March 2022 at 5:44 am UTC

Quoting: Cyba.Cowboy

Quoting: whizseLooks like maybe this bug? https://github.com/systemd/systemd/issues/13432

Does connecting to WiFi and then running systemctl restart systemd-resolved resolve things?

It's uh, working. For no apparent reason, it's working since I made my post this morning. 😕

I didn't apply any updates this morning or anything (though there are some there waiting to apply, according to the Software Center), just ran the Terminal commands as noted above; but when I went to run the (Terminal) command in your post I'm quoting, I was surprised to find that my Internet connection is running perfectly!

How bizarre.

It should be interesting to see if this continues into the night / into tomorrow or if I experience the same problem tomorrow.

Whilst I'm keeping an eye on it, I'm going to have a read of that bug report and see what it contains... Ubuntu "Jammy Jellyfish" is about to drop - which means Pop!_OS 22.04 also should not be too far away - and one would hope that a bug like this has been addressed in the upcoming upgrade.

Annnd it's dead.

Quoting: F.UltraIf restating the resolver above doesn't work then I would try to simply disable the resolver and just use the router or google as the resolver. Found a full step by step guide here: https://bobcares.com/blog/disable-systemd-resolved-in-ubuntu/ , basically one disables the systemd-resolver deamon (disable simply means that it won't be launched at boot, later you can enable it again so this will not botch your system). Next they remove the /etc/resolv.conf file which is the file that tells the machine where to look for a DNS resolver, by default this is linked to a runtime generated file by systemd-resolved so by stopping that deamon, removing the file and restarting NetworkManager, NetworkManager will see that the file is not there and create it again but this time linked to NetworkManager. Likewise to get back one simply deletes the file again and then starts systemd-resolved and everything should be back to how it was before.

I get up to Step 3, but I can't seem to find the 'resolv.conf' file... It wasn't in the 'NetworkManager' directory. If I go to /etc/, there is a 'resolveconf' directory, which contains a 'resol.conf.d' under it; that directory in turn only contains the files 'base', head', original' and 'tail' in it.

If I skip Step 3, sudo service network-manager restart gives me a sudo: unable to resolve host admin-vaio-tap20: Temporary failure in name resolution error.

---

Well, well, well... Look what just popped-up on Reddit:
https://www.reddit.com/r/pop_os/comments/tl36i8/no_wifi_after_upgrade/

That looks awfully similar to my issue.

Whilst networking is not my strong-point, I think @whizse and @F.Ultra and are probably onto something with their theory that this is a bug.

I don't have a Reddit account (the few social media accounts I actually have are used exclusively for work purposes - and I'd get rid of them in a heartbeat if I could!); but if it is a bug, more eyes on the issue is a great thing, because it means a fix might not be too far away.

That's not to say you guys (and girls?) haven't been helpful. The Gaming on Linux Community has (unsurprisingly) been extremely helpful thus far and as somebody that has used Ubuntu since 4.10, I can honestly say that the Gaming on Linux Community reminds me of what the (official) Ubuntu Forums used to be like... But we're not really making any progress here, so hopefully this gets some more people to pay attention to what appears to be a bug.

Of course, if it turns out to be confirmed as a bug or some update fixes it, I will definitely be sure to post back here...

Small note about the missing resov.conf, it was probably removed when the systemd-resolved deamon was stopped (perhaps too old a guide for latest Pop_Os!), because normally it's just a symbolic link to a runtime file generated by this deamon:

 
lrwxrwxrwx 1 root root 37 jan 11  2019 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

But if it's missing it's easy to just create a new one with "sudo nano /etc/resolv.conf" and just insert this single line:
 
nameserver 8.8.8.8

to force the whole system to always ask the google dns server for every single resolving. Just don't forget to rm this file before restarting systemd-resolved when you want to restore everything back.