I’ve tried to find solutions but given the fact that about every other attempt to show a thread yields a time out error makes it a bit difficult, so sorry if I missed a solution out there…
Here’s my problem:
My wireless is working now and my LAN was working always but internet can be very slow. S/W dowloads don’t seem to suffer from that issue though. What I found is that IPv6 might be a problem so I switched it off in YaST2 and immediately the net was a lot faster (comparable to what I get with my tablet using the same router). On the next day after the computer was powered down over night the speed is back to super slow yet YaST2 still shows IPv6 disabled.
I found another post which says disabling in YaST2 doesn’t work and it would need to be done in a file in /boot/grub but I don’t seem to have that file plus I didn’t really get what modification I would need to implement.
The problem seems to be interemittend though. Just pinged google twice within about 10 min. First it looked like this:
mark@linux-67ea:/boot/grub> time ping -c 10 google.comPING google.com (173.194.112.102) 56(84) bytes of data.
64 bytes from fra07s30-in-f6.1e100.net (173.194.112.102): icmp_seq=1 ttl=56 time=22.8 ms
64 bytes from fra07s30-in-f6.1e100.net (173.194.112.102): icmp_seq=2 ttl=56 time=21.8 ms
64 bytes from fra07s30-in-f6.1e100.net (173.194.112.102): icmp_seq=3 ttl=56 time=22.0 ms
64 bytes from fra07s30-in-f6.1e100.net (173.194.112.102): icmp_seq=4 ttl=56 time=21.2 ms
64 bytes from fra07s30-in-f6.1e100.net (173.194.112.102): icmp_seq=5 ttl=56 time=22.0 ms
64 bytes from fra07s30-in-f6.1e100.net (173.194.112.102): icmp_seq=6 ttl=56 time=21.9 ms
64 bytes from fra07s30-in-f6.1e100.net (173.194.112.102): icmp_seq=7 ttl=56 time=22.1 ms
64 bytes from fra07s30-in-f6.1e100.net (173.194.112.102): icmp_seq=8 ttl=56 time=22.2 ms
64 bytes from fra07s30-in-f6.1e100.net (173.194.112.102): icmp_seq=9 ttl=56 time=21.7 ms
64 bytes from fra07s30-in-f6.1e100.net (173.194.112.102): icmp_seq=10 ttl=56 time=22.3 ms
--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 21.298/22.060/22.864/0.416 ms
real 0m9.098s
user 0m0.003s
sys 0m0.003s
mark@linux-67ea:/boot/grub>
A few minutes later like this:
mark@linux-67ea:/boot/grub> time ping -c 10 google.comPING google.com (173.194.112.130) 56(84) bytes of data.
--- google.com ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 8999ms
real 0m19.089s
user 0m0.000s
sys 0m0.004s
mark@linux-67ea:/boot/grub>
Any hints as to what I can check or post as additional information would be highly appreciated (my wife is already requesting to back to Windwos since “this LINUX is causing nothing but trouble”…)
I haven’t heard of users suffering IPv6 issues for some time now, but if you really want to disable the IPv6 stack completely , it can be done with the following kernel boot parameter
ipv6.disable=1
You can do that via YaST >> System >> Boot Loader >> Kernel Prameters…
When you reboot and it takes effect, observe the network interfaces output from ifconfig. There should now be no inet6 addresses shown.
BTW, your ping results are entirely unrelated to IPv6. The timeouts could well be internet-related, and google.com has a large range of IP addresses in use, so this test is meaningless really. Is it just your Linux PC that experiences this issue? I’d be checking the router too. Have you investigated your internet connection issues with your service provider yet?
Took me a few hours to get logged in to read the answers…
I just thought it could be IPv6 related because it worked for a few minutes after disabling IPv6 in YaST2. But meanwhile I think this was a coincidence. Ran my meaningless ping test about 60 times today with varying websites. In < 10% of the trials I got ~24ms answers, the rest was 100% package loss. And yes, this is only the LINUX PC, absolutely zero problems with our phones, i-radio or tablet.
Anyways, I added your code to the bootloader in YaST2 (I hope I picked the correct place in that GUI) and it’s trying to install the bootloader ever since. Not looking promising.
Could be something with the firewall or DNS config? I just don’t get why it is so intermittend…
Definitely not an IPV6 problem, but an internet connectivity problem for sure.
Anyways, I added your code to the bootloader in YaST2 (I hope I picked the correct place in that GUI) and it’s trying to install the bootloader ever since. Not looking promising.
Then you’ve added it incorrectly. Hard to know what you’ve done without being in front of machine. You should still be able to boot in failsafe mode though, and undo any changes you made.
Could be something with the firewall or DNS config? I just don’t get why it is so intermittend…
Thanks
Mark
Could be faulty ethernet able or router perhaps? DNS is not involved for pings using IP addresses, so not the reason for the random spikes and timeouts. Try pinging your router (gateway) address. Does that produce consistent ping times? If so, then the next step is to call your service provider for support I would think.
Already undid the changes to the bootloader (did not even have to go through safe mode). If it is not an IPv6 issue that should be ok.
If I’m using
mark@linux-67ea:/boot/grub> time ping -c 10 google.com
, shouldn’t a DNS be involved at some point? The IP address you can see in older posts is from the system and not entered by myself…
I will try the other things with pinging my router and traceroute but I won’t contact the provider. I’m 100% sure it’s got nothing to do with that since all other H/W is fine. The LAN cable should also not be the issue since WLAN is on in parallel (Linux has no problem with LAN and WLAN in parallel, has it?).
Yes it has! As soon as I unplugged the LAN cable it was stable and fast. I plugged it back in and it was back to 100% package loss. I repeated this 3 times, always the same result. Then I deactivated WLAN and plugged the cable back in it also works fine. However, when I then activated WLAN again it remained stable?!
Let’s see how this behaves in the next few days. If it becomes instable again I will test if unplugging the cable or deactivating WLAN helps to reset the whole thing somehow…
shouldn’t a DNS be involved at some point? The IP address you can see in older posts is from the system and not entered by myself…
DNS is involved if a hostname is used and it then needs to be resolved (to an IP address), but not if using IP addresses for pinging and traceroute.
Yes, generally not a good idea to have two interfaces active and assigned with addresses in the same subnet, although if using Network Manager, it usually prefers wired over wireless, and assigns a different metric (cost) associated with the wireless interface.