6 ms·

E_NOREPRO user@ubuntu-server:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 25.10 Release: 25.1

• nyrikki 6mo ago
  You aren't running it during an external transitive failure that happened on April 15th. The problem isn't the happy path, the problem is when things fail, and that linux, in particular made it really hard to reliably disable [0] Once that hits someone's vagrant or ansible code, it tends to stick forever, because they don't see the value until they try to migrate, then it causes a mess. The last update on the original post link [1] explains this. The ipv4 host being down, not having a response, it being the third Tuesday while Aquarius is rising into what ever, etc... can invoke it. It causes pains, is complex and convoluted to disable when you aren't using it, thus people are afraid to re-enable it. [0] https://wiki.archlinux.org/title/IPv6#Disable_IPv6 https://wiki.archlinux.org/title/IPv6#Disable_IPv6 [1] https://tailscale.com/blog/two-internets-both-flakey https://tailscale.com/blog/two-internets-both-flakey
  • simoncion 6mo ago
    > ...linux, in particular made it really hard to reliably disable Section 10.1 of that Archi Wiki page says that adding 'ipv6.disable=1' to the kernel command line disables IPv6 entirely, and 'ipv6.disable_ipv6=1' keeps IPv6 running, but doesn't assign any addresses to any interfaces. If you don't like editing your bootloader config files, you can also use sysctl to do what it looks like 'ipv6.disable_ipv6=1' does by setting the 'net.ipv6.conf.all.disable_ipv6' sysctl knob to '1'. > You aren't running it during an external transitive failure... I'll assume you meant "transient". Given that I've already demonstrated that the only relevant traffic that is generated is IPv4 traffic, let's see what happens when we cut off that traffic on the machine we were using earlier, restored to its state prior to the updates. We start off with empty firewall rules: root@ubuntu-server:~# iptables-save root@ubuntu-server:~# ip6tables-save root@ubuntu-server:~# nft list ruleset root@ubuntu-server:~# We prep to permit DNS queries and ICMP and reject all other IPv4 traffic: root@ubuntu-server:~# iptables -A OUTPUT -o enp0s3 -p udp --dport 53 -j ACCEPT root@ubuntu-server:~# iptables -A OUTPUT -o enp0s3 -p tcp --dport 53 -j ACCEPT root@ubuntu-server:~# iptables -A OUTPUT -o enp0s3 -p icmp -j ACCEPT root@ubuntu-server:~# iptables -A INPUT -i enp0s3 -p udp --sport 53 -j ACCEPT root@ubuntu-server:~# iptables -A INPUT -i enp0s3 -p tcp --sport 53 -j ACCEPT root@ubuntu-server:~# iptables -A INPUT -i enp0s3 -p icmp -j ACCEPT root@ubuntu-server:~# iptables -A OUTPUT -o enp0s3 -j REJECT root@ubuntu-server:~# iptables -A INPUT -i enp0s3 -j REJECT root@ubuntu-server:~# And we do an apt-get update, which fails in less than ten seconds: root@ubuntu-server:~# apt-get update Ign:1 http://security.ubuntu.com/ubuntu questing-security InRelease Ign:2 http://us.archive.ubuntu.com/ubuntu questing InRelease <snip> Could not connect to security.ubuntu.com:80 (91.189.92.23). - connect (111: Connection refused) Cannot initiate the connection to security.ubuntu.com:80 (2620:2d:4000:1::102). - connect (101: Network is unreachable) <long line snipped> <snip> W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/questing-security/InRelease Cannot initiate the connection to security.ubuntu.com:80 (2620:2d:4000:1::102). - connect (101: Network is unreachable) <long line snipped> W: Some index files failed to download. They have been ignored, or old ones used instead. root@ubuntu-server:~# In this case, the IPv6 traffic I see is... an unanswered router solicitation, and the multicast querier chatter that I saw before. [0] What happens when we change those REJECTs into DROPs root@ubuntu-server:~# iptables -D OUTPUT -o enp0s3 -j REJECT root@ubuntu-server:~# iptables -D INPUT -i enp0s3 -j REJECT root@ubuntu-server:~# iptables -A OUTPUT -o enp0s3 -j DROP root@ubuntu-server:~# iptables -A INPUT -i enp0s3 -j DROP root@ubuntu-server:~# ...and then re-run 'apt-get update'? root@ubuntu-server:~# apt-get update Ign:1 http://security.ubuntu.com/ubuntu questing-security InRelease Ign:1 http://security.ubuntu.com/ubuntu questing-security InRelease Ign:1 http://security.ubuntu.com/ubuntu questing-security InRelease Err:1 http://security.ubuntu.com/ubuntu questing-security InRelease Cannot initiate the connection to security.ubuntu.com:80 (2620:2d:4002:1::103). - connect (101: Network is unreachable) <v6 addrs snipped> Could not connect to security.ubuntu.com:80 (91.189.92.24), connection timed out <long line snipped> <redundant output snipped> W: Some index files failed to download. They have been ignored, or old ones used instead. root@ubuntu-server:~# Exactly the same thing, except it takes like two minutes to fail, rather than ~ten seconds, and the error for IPv4 hosts is "connection timed out", rather than "Connection refused". Other than the usual RS and multicast querier traffic, absolutely no IPv6 traffic is generated. However. The output of 'apt-get' sure makes it seem like an IPv6 connection is what's hanging, because the last thing that its "Connecting to..." line prints is the IPv6 address of the host that it's trying to contact... despite the fact that it immediately got a "Network is unreachable" back from the IPv6 stack. To be certain that my tcpdump filter wasn't excluding IPv6 traffic of a type that I should have accounted for but did not, I re-ran tcpdump with no filter and kicked off another 'apt-get update'. I -again- got exactly zero IPv6 traffic other than unanswered router solicitations and multicast group membership querier chatter. I'm pretty damn sure that what you were seeing was misleading output from apt-get, rather IPv6 troubles. Why? When you combine these facts: * REJECTing all non-DNS IPv4 traffic caused apt-get to fail within ten seconds * DROPping all non-DNS IPv4 traffic caused apt-get to fail after like two minutes. * In both cases, no relevant IPv6 traffic was generated. the conclusion seems pretty clear. But, did I miss something? If so, please do let me know. [0] I can't tell you why the last line in the 'apt-get update' output is only IPv6 hosts. But everywhere there were IPv6 hosts, the reported error was "Network is unreachable" and for IPv4 the error was "Connection refused".