Robin via arch-general <arch-general@xxxxxxxxxxxxx> writes: >> - IPv6 is tried , but takes forever and has 100% package loss >> (frecuent). >> - pinging IPv6 addresses works (very rare) > That's strange. A traceroute with booth working v6 and not working v6 > would be helpful. Also a output of your routing table would be nice. Hi Robin, I remember only one day when IPv6 really worked seamlessly. Today its completely down, so I can only deliver a traceroute with not working v6: ,---- | $ traceroute www.google.com | traceroute to www.google.com (172.217.20.164), 30 hops max, 60 byte | packets | 1 * * * | 2 * * * | 3 * * * | 4 * * * | 5 * 72.14.195.222 (72.14.195.222) 246.613 ms 247.124 ms | 6 108.170.241.195 (108.170.241.195) 249.105 ms * * | 7 216.239.42.70 (216.239.42.70) 40.565 ms 209.85.251.25 | (209.85.251.25) 40.248 ms 108.170.236.140 (108.170.236.140) 39.085 ms | 8 108.170.241.227 (108.170.241.227) 35.108 ms 108.170.241.195 | (108.170.241.195) 40.341 ms 209.85.142.161 (209.85.142.161) 36.544 ms | 9 209.85.143.24 (209.85.143.24) 36.772 ms 209.85.143.27 | (209.85.143.27) 36.526 ms 209.85.143.24 (209.85.143.24) 36.607 ms | 10 209.85.241.98 (209.85.241.98) 58.073 ms 216.239.58.121 | (216.239.58.121) 35.617 ms 216.239.56.17 (216.239.56.17) 35.827 ms | 11 209.85.254.199 (209.85.254.199) 50.322 ms 66.249.95.22 | (66.249.95.22) 83.051 ms 66.249.95.38 (66.249.95.38) 36.208 ms | 12 216.239.41.165 (216.239.41.165) 50.455 ms 216.239.57.241 | (216.239.57.241) 66.627 ms 50.974 ms | 13 209.85.254.157 (209.85.254.157) 49.339 ms | waw02s07-in-f164.1e100.net (172.217.20.164) 52.945 ms 49.656 ms | [tj@arch ~]$ ping www.google.com | PING www.google.com (172.217.20.164) 56(84) bytes of data. | 64 bytes from waw02s07-in-f164.1e100.net (172.217.20.164): icmp_seq=1 | ttl=54 time=93.4 ms | 64 bytes from waw02s07-in-f164.1e100.net (172.217.20.164): icmp_seq=2 | ttl=54 time=50.3 ms | 64 bytes from waw02s07-in-f164.1e100.net (172.217.20.164): icmp_seq=3 | ttl=54 time=49.3 ms | 64 bytes from waw02s07-in-f164.1e100.net (172.217.20.164): icmp_seq=4 | ttl=54 time=51.3 ms | 64 bytes from waw02s07-in-f164.1e100.net (172.217.20.164): icmp_seq=5 | ttl=54 time=49.5 ms | | --- www.google.com ping statistics --- | 5 packets transmitted, 5 received, 0% packet loss, time 4005ms | rtt min/avg/max/mdev = 49.329/58.809/93.484/17.353 ms `---- routing tables: ,---- | $ ip -f inet route show | default via 192.168.2.1 dev ens34 src 192.168.2.122 metric 202 | 192.168.2.0/24 dev ens34 proto kernel scope link src 192.168.2.122 | metric 202 `---- ,---- | $ ip -f inet6 route show | fe80::/64 dev ens34 proto kernel metric 256 pref medium `---- I have a weak WLAN and use a Fritz WLAN Repeater to enhance signal, but this my linux machine has no WLAN card, I plug it by cable into the WLAN repeater ;-) >> - pinging pure IPv6 addresses (ipv6.google.com) results in 'network >> not found', but pinging www.google.com results in a successfull >> IPv4 ping (very rare) > What is rare ? The successful v4 ping ? Yes, because (now I more or less understand what might be happening) normally, v6 is not completely down, so it is tried - and takes forever, pinging with 100 package loss. W3M webbrowsing (using google) still works somehow, but incredibly slow. Today for some reason v6 is completely down, thus v4 is used for www.google.com, and it works (reasonable fast). > This is easy to explain. As far as I know there is only a AAAA record > for ipv6.google.com. So when there are any v6 related problem you > should not able to send packets to this address. www.google.com got > booth an A and and AAAA record. I am not sure how ping decides which > protocol to use, but in your case it seems like you v6 network is down > (maybe no routing information), so it is using v4. You can force it to > use a specific protocol with -4 oder -6 switch. that explains it very well. ping can be forced to use a certain protocol, but my webbrowser doing google searches (e.g. textbased W3M) seems to always try v6 if its available. -- cheers, Thorsten
