My System Info

Linux Distribution: Pop!_OS 22.04 LTS
Desktop Environment: GNOME 42.9
Graphics Card: Mesa Intel HD Graphics 4000 (IVB GT2)
GPU Driver Version: i915

Have you checked for system updates?: Yes

If this is not Steam, you can still give us a system readout using inxi with "inxi -SbCGxx" in terminal (please put that into Pastebin/Gist as linked above!):
https://pastebin.com/mWak7k60

You can note your issue below here

My second computer, a Sony VAIO Tap 20 SVJ20215CB "sees" and connects to our Wi-Fi network, but it doesn't actually have Internet connectivity. No other device in our household, including other Linux-based laptops, have this issue. This particular computer also has perfect connectivity (i.e. no issues) when connected ti my modem / router by ethernet.

I thought it was something related to the modem / router I was previously using, but I just changed to Starlink and it is the same issue with the new modem / router. Again, no other device in the household, including other Linux-based laptops, have issues, suggesting the problem is unique to this computer.

Obviously I can leave it connected by ethernet, and that is my "Plan B", but it would not be ideal.

Any ideas?

Try updating your wifi card driver separately.

Edit:
how to do that:
lspci -vq
look for the one with wireless in the name
post the name and kernel-module here
sudo apt install -only-module [kernel-module]

Last edited by LoudTechie on 12 October 2024 at 4:04 pm UTC

Output of ip addr and ip route might be helpful.

My second computer, a Sony VAIO Tap 20 SVJ20215CB "sees" and connects to our Wi-Fi network, but it doesn't actually have Internet connectivity. No other device in our household, including other Linux-based laptops, have this issue. This particular computer also has perfect connectivity (i.e. no issues) when connected ti my modem / router by ethernet.

Could be poor driver support for your Wi-Fi chipset.

I have this problem with my Lenovo ThinkPad T440p laptop as well. Like you, the Internet is rock-solid on Ethernet but completely unreliable/unstable on Wi-Fi. I traced the problem to poor driver support for the Intel Wireless-N 7260 chipset.

This problem was present regardless of the distro. I'm currently on Pop!_OS like you. Prior to that, I was on Manjaro. Interestingly enough, Manjaro seemed to have stabilized the driver over time but, initially, the Wi-Fi was just as unstable as on Pop!_OS. Ironically, the Wi-Fi driver is rock-solid in Windows 10.

Unfortunately, I never did resolve the issue in Pop!_OS. The problem with the Intel Wireless-N 7260 Linux driver is a notorious one all over the web. I gave up and I just use the Ethernet connection instead.

Edit: Verified chipset model.

Last edited by Caldathras on 12 October 2024 at 5:33 pm UTC

Output of ip addr and ip route might be helpful.

ip addr:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 54:53:ed:bb:3d:e6 brd ff:ff:ff:ff:ff:ff
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 0c:d2:92:3d:62:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.24/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp1s0
       valid_lft 3404sec preferred_lft 3404sec
    inet6 fd9a:2aa7:35e2:10:5ebd:35bf:dad2:43ad/64 scope global temporary dynamic 
       valid_lft 604624sec preferred_lft 86193sec
    inet6 fd9a:2aa7:35e2:10:ecc9:f75:b293:7ba6/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 2406:2d40:444f:f910:42b8:e06f:8a22:306d/64 scope global temporary dynamic 
       valid_lft 218sec preferred_lft 68sec
    inet6 2406:2d40:444f:f910:a9a:ff7c:b60:5798/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 218sec preferred_lft 68sec
    inet6 fe80::7916:2ad1:bc6f:b5e8/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

ip route:
default via 192.168.1.1 dev wlp1s0 proto dhcp metric 600 
169.254.0.0/16 dev wlp1s0 scope link metric 1000 
192.168.1.0/24 dev wlp1s0 proto kernel scope link src 192.168.1.24 metric 600

Could be poor driver support for your Wi-Fi chipset.

I have this problem with my Lenovo ThinkPad T440p laptop as well. Like you, the Internet is rock-solid on Ethernet but completely unreliable/unstable on Wi-Fi. I traced the problem to poor driver support for the Intel Wireless-N 7260 chipset.

This computer has the Centrino Wireless-N 135 (rev c4) chipset... I always thought Intel generally had pretty good hardware support under Linux-based operating systems, but your theory is certainly plausible.

I might have to see if anybody else is complaining about this particular chipset online...

Last edited by Cyba.Cowboy on 13 October 2024 at 8:28 am UTC

ip addr:
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

2: enp3s0: […] state DOWN
doesn't look like it's using the wire at all. Have you tried with the ethernet cable unplugged?


I may be wrong, I'm certainly rusty ;) wrt the OSI layer model, but I seem to recall "link/ether" refers to the link layer using MAC addresses, which are what IEEE802.11 aka. WiFi uses as well.
whereas wlp1s0: […] state UP  ff. certainly looks like it has connectivity and routing over the wireless adapter.

I'd maybe look into the significance of "noprefixroute", that'sdisregard
what it looks to me at first glance is some routing/DHCP or maybe DNS misconfiguration?

Last edited by Valck on 13 October 2024 at 10:56 am UTC

You could try
$ traceroute www.gamingonlinux.com
and
$ traceroute6 www.gamingonlinux.com
to see where the route ends, as a first indicator.

...and I can't help but notice how forums – with their latency on the order of avian IP – aren't really suited for this kind of troubleshooting :)

doesn't look like it's using the wire at all. Have you tried with the ethernet cable unplugged?

The ethernet cable is unplugged, to demonstrate that it is connected to my wireless network, but that the Internet connectivity is not working... As I said, everything works fine when the ethernet cable is connected; but when it is disconnected and I am using Wi-Fi, I have no internet connectivity.

This computer claims that it is connected to my wireless network and my modem / router can "see" this computer, but I have no Internet connectivity on this computer unless there is an ethernet cable connected.

what it looks to me at first glance is some routing/DHCP or maybe DNS misconfiguration?

This is a relatively fresh installation of Pop!_OS and I've not changed any of the networking settings, besides connecting to different wireless networks... So maybe something has corrupted these settings?

How would I fix routing / DHCP issues, or correct a DNS misconfiguration?

How would I fix routing / DHCP issues, or correct a DNS misconfiguration?

Can of worms, and I'm really not that up to speed. Anytimi I'm confronted with that kind of problem on my end, I have to go and RTFM myself, and locate again all the places where information could hide itself...
As I said, I'd first try to find out how far along the way the connection ends as a first indicator; if it's not even reaching your router/modem, or if it can't find a route beyond that. "ping" and "traceroute", along with a good deep look into the /etc directory tree maybe. Ideally get someone who knows at least a bit about networking to look over your shoulder...
I might remember a thing or two when I actually see it in front of me, but off the top of my hat, over a high-latency communication... chances are slim at best, at least as far as I'm concerned.

Try "ping"-ing the IP address of your router first, ie. $ ping -c1 192.168.1.1; the -c1 is to "send one ping only"... even if it might not matter much on your own local net, it's good practice to do your best to avoid flooding other people's networks by accident. As long as it's an 192.168.x.y address, you're on the safe side. Everything else, be as polite as possible (I hope Liam can forgive my using his site in the traceroute example above...)
From there, you can try more remote locations, but the issue is most likely either on your machine, or on the router/modem anyway.

If you can reach the router using the ping example above, you might also try:
ping 1.1.1.1
It's a Cloudflare server, if that works you are technically connected to the internet.

For DNS, you can check nameservers with cat /etc/resolv.conf  and compare it with the wired connection.

That file is autogenerated, so you can't just edit the file. I'm not clear on what Pop uses for DNS (systemd-resolved?) or even general network setup.

Try "ping"-ing the IP address of your router first, ie.

All I got was:
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.24 icmp_seq=1 Destination Host Unreachable

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
That means it's not even receiving a response from the modem / router, right?

How does that work, when my modem / router can "see" the computer connected in the Starlink app (Starlink manage their modem / router exclusively via an app, rather than via a Web-based interface)?

Last edited by Cyba.Cowboy on 13 October 2024 at 2:45 pm UTC

That's very weird.

I would try a live USB with a different distro. If it's broken there too, it's probably a hardware issue.

Try "ping"-ing the IP address of your router first, ie.

All I got was:
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.24 icmp_seq=1 Destination Host Unreachable

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
That means it's not even receiving a response from the modem / router, right?

How does that work, when my modem / router can "see" the computer connected in the Starlink app (Starlink manage their modem / router exclusively via an app, rather than via a Web-based interface)?

All that tells you is it can't find a route via IPv4 (ie. addresses that look like "123.45.67.89", aka. "dotted quad"). If it can "see" the router, that means you have a _physical_ (albeit intangible) connection, and the only possible explanation is that you do have a route via IPv6 //only//, which is clearly a misconfiguration issue. (edit: it might be intentional in some scenarios)

The logical next step would be to try "ping -6" or "traceroute -6" for IPv6 (that's these type of addresses "1234:5678:90ab:cdef::::ff", larger address space, more intimidating looking, ie. more modern);

$ man traceroute
tells us "-6" for IPv6, and "-i wlp1s0" to use the wireless interface

so give it a try with
$ traceroute -6 -i wlp1s0 the:IPv6:address:::of:your:router

or the router's DNS address, if it is supposed to have one ("fritz.box" comes to mind)
or failing that,even the DNS address of some public host like google the diagnostic DNS address
$ traceroute -6 -i wlp1s0 example.com

and it *should* give you at least *some* result, at least up to your router.

After that, it's back to configuring your routing/DNS, and that depends on what type of distro you use, and is best looked up in the documentation that comes with it.

Last edited by Valck on 14 October 2024 at 7:01 am UTC

This computer has the Centrino Wireless-N 135 (rev c4) chipset... I always thought Intel generally had pretty good hardware support under Linux-based operating systems, but your theory is certainly plausible.

I might have to see if anybody else is complaining about this particular chipset online...

Your chipset is a year older than mine. It is supported by the same kernel-level driver as mine. I think it very likely that you could be experiencing the same problem.

(FYI, which is why I don't think that trying a different distro will give you a conclusive answer. If you dual booted with Windows like I do, that would give you a better answer. My chipset works flawlessly in Windows.)

Perhaps Intel's support on newer Wi-Fi chipsets is good, but from what I've seen, the support for older hardware is not that strong. Rather than asking that Intel improve the driver, most of the online comments take a more resigned tone and suggest replacing the problematic Wi-Fi chipsets instead.

That being said, if the more technically savvy commenters can come up with a solution that benefits both of us, I'm all for it!

Last edited by Caldathras on 14 October 2024 at 5:19 pm UTC

Apperantly this is a common issue for this chipset:
https://forums.fedoraforum.org/showthread.php?299700-WiFi-hardblocked
https://www.linuxquestions.org/questions/centos-111/centos-7-wifi-is-not-working-intel-centrino-wireless-n-135-a-4175543308/
https://www.intel.com/content/www/us/en/support/articles/000005511/wireless.html


One of the driver linked on this page is the right one. I'm still seeking which one specifically.

Rather than asking that Intel improve the driver, most of the online comments take a more resigned tone and suggest replacing the problematic Wi-Fi chipsets instead.

Yeah, I'm not doing that... This is an "all-in-one" computer and uses laptop-like components, so it would be pretty easy to replace the Wi-Fi module, as long as it's not soldered to the motherboard or anything crazy like that (I haven't soldered anything in years and years!) - but this is a pretty old "spare" computer and with the exception of the Wi-Fi module, has already been upgraded as far as the motherboard allows; this computer will likely be replaced entirely, once it's financially feasible for me to do so.

Your chipset is a year older than mine. It is supported by the same kernel-level driver as mine. I think it very likely that you could be experiencing the same problem.

Apperantly this is a common issue for this chipset:
https://forums.fedoraforum.org/showthread.php?299700-WiFi-hardblocked
https://www.linuxquestions.org/questions/centos-111/centos-7-wifi-is-not-working-intel-centrino-wireless-n-135-a-4175543308/
https://www.intel.com/content/www/us/en/support/articles/000005511/wireless.html

So without replacing the chipset, it looks like using ethernet cable is going to be the best Real World solution... Not the solution I wanted, but at least I know what the problem is now and like always, the Gaming on Linux Community has proven it is worth its weight in gold.

Thanks, guys and girls!

Last edited by Cyba.Cowboy on 14 October 2024 at 10:03 pm UTC

Often dmesg can give you an idea of maybe where to start looking for what the issue is. If you know the name of the driver modules(obtainable via the lsmod command), you can search dmesg like so: sudo dmesg |grep $DRIVER_MODULE_NAME( ex: sudo dmesg |grep iwlwifi ). if there was an issue or some kind of warning it may or may not show up in dmesg. you can also use sudo dmesg |grep Intel for info about Intel devices discovered.

you can also try unloading the wifi modules and reloading them in verbose mode and see what info is produced:
sudo rmmod $DRIVER_MODULE_NAME
sudo modprobe -v $DRIVER_MODULE_NAME

that might produce some kind of useful message.

finally sudo dmesg |less will let you step thru all the kernel messages from boot, allowing you to follow the driver loading and other boot processes to see if you can spot an error or warning message

So without replacing the chipset, it looks like using ethernet cable is going to be the best Real World solution... Not the solution I wanted, but at least I know what the problem is now and like always, the Gaming on Linux Community has proven it is worth its weight in gold.

Or el cheapo USB WiFi dongle.