On 2015-11-18 11:12, Guus Sliepen wrote: > severity 805445 important > thanks > > On Wed, Nov 18, 2015 at 10:16:29AM +0100, Jeroen Massar wrote: > >> Package: ifupdown >> Version: 0.7.53.1 >> Severity: critical >> >> Marking critical as it breaks IPv6 connectivity after a reboot, thus >> hope you got IPv4 still (or KVM :) if it is a remote machine ;) > > It's not dropping your SQL tables or blowing up your house, so: > > important > a bug which has a major effect on the usability of a package, > without rendering it completely unusable to everyone.
Well actually.... there are folks with IPv6 only connectivity (or IPv4 behind NAT or worse CGN) and no KVM access (which is silly but still) thus they would lose access to the host if it would restart. There are then also people who manage their home heater system with it and thus won't be able to access that remotely.... thus it could blow up your house ;) Hence, why I think that it should be a priority to look at. But "important" works too. >> See Ubuntu bug report here: >> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1510098 > > Did you try this on a Debian system or on Ubuntu? Debian stable 0.7.53.1, I avoid Ubuntu like a plague :) $ apt-cache policy ifupdown ifupdown: Installed: 0.7.53.1 Candidate: 0.7.53.1 Version table: *** 0.7.53.1 0 500 http://mirror.switch.ch/ftp/pub/debian/ stable/main amd64 Packages 100 /var/lib/dpkg/status > And in either case, which version? See original version above and just the text above. > Then I can try it out in a VM and try to find the cause. Awesome, please do. I would btw not be surprised if this is related to having accept_ra set to 0 in sysctl as it should be for server systems. > It would also be helpful to see your full /etc/network/interfaces, > without any addresses censored if possible, so I can see if it might be > caused by any scoping issues. I am quite good with scoping issues, don't worry about that. Some of the boxes I had this problem on where running fine for over 10 years... It is a bog standard config, did not include it as the bog the same details for the ubuntu bug report apply. But let me give you a simple version: 8<----------------- # The loopback interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.168.200.42 netmask 255.255.255.0 gateway 198.168.200.1 iface eth0 inet6 static address 2001:db8:ff:1234::42 netmask 64 gateway 2001:db8:ff:1234::1 ----------------->8 Note that we zero out /etc/sysctl.d/10-ipv6-privacy.conf (empty file with just comments) to avoid privacy parameters to be set (Ubuntu actually does do that, not sure if Debian does, don't think so though) 8<----------------- $ cat /etc/sysctl.d/99-custom.conf # Upgrade the TCP backlog quite a bit net.ipv4.tcp_max_syn_backlog=8192 # Disable Accept of Router Advertisements net.ipv6.conf.all.accept_ra=0 net.ipv6.conf.default.accept_ra=0 # Disable source routing net.ipv4.conf.default.accept_source_route=0 net.ipv4.conf.all.accept_source_route=0 # Disable ICMP ratelimitting # There are so many people who seemingly need to monitor # SixXS boxes, that these limits are triggered all the time net.ipv4.icmp_ratelimit=0 net.ipv4.icmp_ratemask=0 net.ipv6.icmp.ratelimit=0 # Make sure that privacy addresses are disabled net.ipv6.conf.default.use_tempaddr=0 net.ipv6.conf.all.use_tempaddr=0 ----------------->8 Indeed, Ubuntu sets use_tempaddr=2 in their sysctl (hence the empty file mentioned above) and then when sysctl this custom file the setting is reverted and you lose your default... hmmm, that might actually be affecting this too now I think of it. But the sysctl stuff should run BEFORE ifupdown comes into play (hence setting default+all so that existing and new interfaces get that setting). That might thus be a kernel annoyance, thus just in case on that box the version of that: linux-image-3.16.0-4-686-pae 3.16.7-ckt11-1+deb8u6 i386 hmmmmm you are not toggling use_tempaddr I hope as that would cause default route to be cleared by the kernel (some kernels do that, others do not btw...)? Indeed using the accept_ra etc settings in /etc/network/interfaces would be a good thing, but the current sysctl method has worked for a long long time already and a static config should just work like that. >> Btw, >> https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ifupdown;dist=unstable >> mentions that Guus is the maintainer while the package field has Andrew >> listed... there is a LOT of wishlist bugs there that could just be >> closed even though they are from ~2001.... > > Yes, I took over but Andrew is also still contributing. I have been > going through old bugs, most can indeed be closed, but there are also > some bugs worth fixing (even wishlist bugs from a decade ago). I saw the commit log, I am sure you'll fight through them :) Good luck and thanks for working on it! Greets, Jeroen
