You are not logged in.
Pages: 1
Hi! I've been having an exact same issue as this , though that topic never seemed to have been resolved. Some pages are timing out on all browsers, (can't even ping it). To resolve the issue I've tried changing my DNS and disabling ipv6 to no avail. Here's a list of webpages that do work:
google.com
archlinux.org
facebook.com
messenger.com
fast.com
reddit.com (this one is like 50/50)
wikipedia.org
Pages that don't seem to work:
discord.com (note that after a horrible amount of wait time and like 10 retries I was able to connect to discord.com.)
x.com
github.com
desmos.com
here's my uname
uname -a
Linux data 6.9.3-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 31 May 2024 15:14:45 +0000 x86_64 GNU/Linuxiptables:
Chain INPUT (policy ACCEPT)
target prot opt source destination
LIBVIRT_INP all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
LIBVIRT_FWX all -- anywhere anywhere
LIBVIRT_FWI all -- anywhere anywhere
LIBVIRT_FWO all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
LIBVIRT_OUT all -- anywhere anywhere
Chain LIBVIRT_FWI (1 references)
target prot opt source destination
ACCEPT all -- anywhere 192.168.100.0/24 ctstate RELATED,ESTABLISHED
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain LIBVIRT_FWO (1 references)
target prot opt source destination
ACCEPT all -- 192.168.100.0/24 anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain LIBVIRT_FWX (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain LIBVIRT_INP (1 references)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
Chain LIBVIRT_OUT (1 references)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
ACCEPT tcp -- anywhere anywhere tcp dpt:bootpcOffline
Do note that after the connection to discord.com, the issue kind of resolve itself on that domain alone.
Offline
Compare
tracepath archlinux.org
tracepath github.comand where it stalls.
can't even ping it
ping -c3 github.com
ping -c3 -n github.com
ping 140.82.121.4 # a github IPv4
ping -c3 -W 60 github.com # this waits 60s for a response before giving upOffline
tracepath github.com 12:14:22
1?: [LOCALHOST] pmtu 1500
1: no reply
2: no reply
3: no reply
4: no reply
5: no reply
6: no reply
7: no reply
8: no reply
9: no reply
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500 tracepath archlinux.org 12:13:55
1?: [LOCALHOST] 0.006ms pmtu 1500
1: 2a0b:6204:1:e479:0:ac75:1d39:7cfa 22.256ms
1: 2a0b:6204:1:e479:0:ac75:1d39:7cfa 18.326ms
2: no reply
3: no reply
4: 2a0b:6200::100 20.962ms
5: 2001:930:9a::c1 58.304ms
6: ae4-18-ucr1.tuz.cw.net 49.441ms
7: ae33-xcr1.bcp.cw.net 58.909ms asymm 8
8: telia-gw-xcr1.bcp.cw.net 56.791ms asymm 9
9: win-bb2-v6.ip.twelve99.net 76.889ms asymm 11
10: ffm-bb1-v6.ip.twelve99.net 83.566ms asymm 11
11: sto-bb2-v6.ip.twelve99.net 203.636ms asymm 12
12: hls-b4-v6.ip.twelve99.net 191.933ms asymm 13
13: hls-b6-v6.ip.twelve99.net 121.844ms asymm 14
14: hetzner-ic-376888.ip.twelve99-cust.net 196.313ms asymm 12
15: core32.hel1.hetzner.com 203.905ms asymm 11
16: no reply
17: spine2.cloud1.hel1.hetzner.com 180.764ms asymm 13
18: no reply
19: 13353.your-cloud.host 277.925ms asymm 15
20: archlinux.org 110.194ms !Aping -c3 github.com 12:18:52
ping -c3 -n github.com
ping 140.82.121.4 # a github IPv4
ping -c3 -W 60 github.com # this waits 60s for a response before giving up
PING github.com (140.82.121.4) 56(84) bytes of data.
--- github.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2026ms
PING github.com (140.82.121.4) 56(84) bytes of data.
--- github.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms
PING 140.82.121.4 (140.82.121.4) 56(84) bytes of data.
64 bytes from 140.82.121.4: icmp_seq=1 ttl=48 time=64.1 ms
64 bytes from 140.82.121.4: icmp_seq=2 ttl=48 time=66.3 ms
64 bytes from 140.82.121.4: icmp_seq=3 ttl=48 time=64.0 ms
64 bytes from 140.82.121.4: icmp_seq=4 ttl=48 time=64.2 ms
64 bytes from 140.82.121.4: icmp_seq=59 ttl=48 time=2565 ms
64 bytes from 140.82.121.4: icmp_seq=60 ttl=48 time=1553 ms
64 bytes from 140.82.121.4: icmp_seq=61 ttl=48 time=537 ms
64 bytes from 140.82.121.4: icmp_seq=62 ttl=48 time=64.1 ms
64 bytes from 140.82.121.4: icmp_seq=63 ttl=48 time=69.0 ms
64 bytes from 140.82.121.4: icmp_seq=64 ttl=48 time=173 ms
64 bytes from 140.82.121.4: icmp_seq=65 ttl=48 time=103 ms
64 bytes from 140.82.121.4: icmp_seq=231 ttl=48 time=1121 ms
64 bytes from 140.82.121.4: icmp_seq=232 ttl=48 time=112 ms
64 bytes from 140.82.121.4: icmp_seq=233 ttl=48 time=64.1 ms
64 bytes from 140.82.121.4: icmp_seq=234 ttl=48 time=78.4 ms
64 bytes from 140.82.121.4: icmp_seq=235 ttl=48 time=66.2 ms
64 bytes from 140.82.121.4: icmp_seq=236 ttl=48 time=65.4 ms
^C
--- 140.82.121.4 ping statistics ---
594 packets transmitted, 17 received, 97.138% packet loss, time 600746ms
rtt min/avg/max/mdev = 64.047/401.743/2564.888/681.208 ms, pipe 3
PING github.com (140.82.121.3) 56(84) bytes of data.
--- github.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2021msOffline
To resolve the issue I've tried changing my DNS and disabling ipv6 to no avail.
IPv6 clearly isn't disabled and this is how and where archlinux.org is accessed.
github and the other failing sites you mentioned have no AAAA DNS record (ie. no IPv6)
594 packets transmitted, 17 received, 97.138% packet loss, time 600746ms sounds like IPv4 translation principally works but is underdimensioned.
The problem would most likely be your ISP (Magticom in Georgia?) - if this isn't a temporary issue you'll have to contact them.
But b/c of the libvirt entries: is this on bare metal or in a virtual machine? Do you have the same problem with other hosts in your LAN?
Offline
I've re-enabled IPv6 at this point.
I don't really think it's an ISP issue because the networked behaved normally for a while.
Bare metal; libvirt is installed for Qemu. No, every other host can access everything normally.
Offline
Disable IPv6 again and check the "tracepath archlinux.org" behavior.
You can also briefly
tracepath -4 archlinux.orgbut the pattern is rather strong and you didn't get a response from the immediate hops when tracing github.com
Offline
I had to disable Ipv6 twice. The first time I disabled it, I couldn't reach archlinux.org. I re-enabled it and rebooted. After disabling it the second time I'm able to use the network normally. Sure, I'm happy that the problem is fixed, but why is this behavior so inconsistent ?
tracepath -4 archlinux.org 21:17:27
1?: [LOCALHOST] pmtu 1500
1: _gateway 3.563ms
1: _gateway 6.490ms
2: 100.96.16.1 6.428ms
3: 100.127.255.2 4.701ms asymm 4
4: host-213-157-192-133.customer.magticom.ge 4.833ms asymm 5
5: host-213-157-194-5.customer.magticom.ge 4.835ms asymm 6
6: 84.44.20.157 66.189ms asymm 7
7: 10.135.56.173 31.011ms asymm 8
8: ae3-17-xcr1.ise.cw.net 31.163ms asymm 9
9: ae29-xcr1.sof.cw.net 46.228ms asymm 10
10: no reply
11: ae1.16.edge1.hel1.neo.colt.net 203.988ms asymm 19
12: 212.133.6.2 109.142ms asymm 16
13: core31.hel1.hetzner.com 107.077ms asymm 17
14: no reply
15: spine1.cloud1.hel1.hetzner.com 168.916ms asymm 19
16: no reply
17: 14931.your-cloud.host 100.816ms asymm 21
18: archlinux.org Offline
why is this behavior so inconsistent?
If it wasn't bound to specific domains (all w/o IPv6 records) I'd say your connection is maybe generally unstable (do you have a complete system journal from a bad boot?) and if the trace hadn't failed on the first hop it could have been somewhere one the route but from the present data, all fingers point at some issue w/ your ISP.
Maybe it makes a difference whether the client has a dual stack and asks to route IPv4 and IPv6 packages
tracepath -4 github.com now works as well?
Reliably?
Have you tried to re-enable IPv6 and see whether that actually triggers the behavior again or this all has just been coincidental?
Sanity check: is there a parallel windows installation?
Offline
* Try using another device (e.g. phone), or livecd with some other OS
* Try comparing wired ethernet vs wifi
* Check dmesg for errors from your network drivers, e.g. issues with power states
* Check your Modem web-interface for statistics related to connection stability, reboot the modem
Offline
Pages: 1