Re: connect() with AF_INET6 freezes on some Debian/unstable machine
On Wed, Apr 08, 2015 at 10:02:23AM +0200, Vincent Lefevre wrote:
> 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:
> > > > SLAAC is a good thing if the host that advertises RA is an actual
> > > > router. If it is not - you get exactly the behavior you got.
> > >
> > > Thanks for the information. Do you mean that random machines on
> > > the network can send fake advertising?
> > Yes. And by default - every host in a local network segment and their
> > dog will accept this RA. Worse - there can be more than one RA
> > advertiser on a network segment (and it leads to *very* funny results).
> > > If SLAAC can be a bad thing on arbitrary networks, why is it enabled
> > > by default? (IMHO, the default should be the safest.)
> > Treat SLAAC as DHCP. It's considered pretty normal to run DHCP client in
> > a foreign network and trust whatever information DHCP server sends the
> > client. Heck, some clients are going that far as setting own hostname
> > the way DHCP server told them.
> > The only difference being that DHCP requires userspace client
> > and SLAAC does not (in Linux).
> OK, so if I understand correctly, the problem I see with SLAAC is
> similar to what I would get for IPv4 too with a rogue DHCP server.
> > > > 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.
> OK. I suppose that I should use /etc/sysctl.conf to make this setting
net.ipv6.conf.all.accept_ra = 0
> > > But on the other machine that doesn't have this "scope global",
> > > /proc/sys/net/ipv6/conf/*/accept_ra is also 1, so that I'm confused.
> > If it's on the same network - check whenever you have ip6tables
> > configured on that host. If it's a different network - it's no wonder.
> Yes, they are behind different routers (same place, but different
> networks). For the other network, the machines are not administrated
> by their end users, so that I suppose that it cannot have these
Oh, then it solves this. By design NDC is limited to one network
segment. Unless you're allowing to pass L2 traffic from one network to
another - you should not have this problem.