Re: connect() with AF_INET6 freezes on some Debian/unstable machine
On 2015-04-08 09:57:28 +0300, Reco wrote:
> On Wed, Apr 08, 2015 at 01:35:44AM +0200, Vincent Lefevre wrote:
> > On 2015-04-08 01:41:58 +0300, Reco wrote:
> > > The correct way to deal with this then is to disable accepting RAs on
> > > your host:
> > >
> > > echo 1 > /proc/sys/net/ipv6/conf/all/accept_ra
> > I did *not* do that yet, but I can see:
> > ypig:~> cat /proc/sys/net/ipv6/conf/all/accept_ra
> > 1
> > i.e. it is already 1 (ditto for /proc/sys/net/ipv6/conf/eth0/accept_ra).
> > Or do you mean 0?
> My bad. Zero to disable, one to enable.
This has no effect. The problem occurs again. I've reported a bug:
The SLAAC seems to have occurred about 2 hours after I rebooted the
machine, since I can see in the logs:
Apr 9 14:35:07 ypig avahi-daemon: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::21f:29ff:fe04:3efb.
Apr 9 14:35:07 ypig avahi-daemon: Joining mDNS multicast group on interface eth0.IPv6 with address 2001:1::21f:29ff:fe04:3efb.
Apr 9 14:35:07 ypig avahi-daemon: Registering new address record for 2001:1::21f:29ff:fe04:3efb on eth0.*.
Apr 9 14:35:07 ypig avahi-daemon: Withdrawing address record for fe80::21f:29ff:fe04:3efb on eth0.
Apr 9 14:35:09 ypig ntpd: Listen normally on 6 eth0 2001:1::21f:29ff:fe04:3efb UDP 123
Apr 9 14:35:09 ypig ntpd: peers refreshed
I'm wondering. Since ntpd listens on the new address, could this
be done to modify the date of the machine, thus introducing a huge
security hole (e.g. concerning normally expired certificates)?
Vincent Lefèvre <firstname.lastname@example.org> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)