netdev - Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinGKJgYM6mzVvR00KANh869z1T_2CD1Vv57Xrqx@mail.gmail.com>
Date:	Tue, 26 Oct 2010 10:09:51 -0700
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	Brian Haley <brian.haley@...com>
Cc:	Stephen Hemminger <shemminger@...tta.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when
 losing link

On Tue, Oct 26, 2010 at 9:58 AM, Brian Haley <brian.haley@...com> wrote:
> > That won't help the case I am trying to fix, which is the case where
> > the new link has a global prefix different than the old link. Marking
> > the addresses as tentative will simply make them pass DAD and come
> > back as soon as link comes back. But since they don't match the prefix
> > that is assigned to the new link, they are unusable, because packets
> > can't be routed back to them.
>
> The old addresses will become deprecated, and eventually get removed, but
> it will take 2 hours.

Yes, but they become deprecated only after the preferred lifetime is
expires. Until that happens, the kernel considers them fair game and
will use them for outgoing connections, without knowing that they
won't work. So the user just sees connection timeouts and thinks that
IPv6 is slow.

> http://marc.info/?l=linux-netdev&m=128415231909522&w=2
>
> But the first response pointed out that I didn't test this with just a
> simple link flap, in which case all the IPv6 addresses are deleted,
> and all sessions using them die.  Not good.  This changes the current
> behavior, and isn't what happens with IPv4 either.

Actually, I just tested this and it works fine. I opened a telnet
session to ipv6.google.com port 80, and while the TCP connection was
open I reassociated with the same wifi link. During the flap, the
patch removed and then readded the same global IPv6 address. While it
was doing it, I typed GET / HTTP/1.0\n\n in the telnet window. When
the address came back, the response came back fine. The connection was
not reset.

> Having these addresses restart DAD is probably about as much as we
> can do I think, unless we add a per-device sysctl to remove the addresses
> (which I think has been shot-down before).

As before, just setting them tentative won't help that case I am
trying to fix. They have to be removed.

> Is this a mobile device that is actually changing it's point of attachment?

This is a laptop that is changing SSIDs, plugging into wired/wireless,
etc. At work we have multiple wireless networks with their own IPv6
ranges. The typical case is that I am connected to the corp network,
then I associate with the guest network... and IPv6 is broken, because
the kernel wants to use my old address and gateway, which don't work.

I'm also doing lab testing of IPv6-capable home routers, each of which
has its own wireless network. As you can imagine, after a couple of
switches, I end up with three IPv6 addresses and between three sets of
default gateways, only one of which works.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html