netdev - Re: Linux sends IPv6 NS packets with the link-local address

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]

Date:	Thu, 7 Nov 2013 01:46:11 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	"Steinar H. Gunderson" <sgunderson@...foot.com>
Cc:	netdev@...r.kernel.org, ayourtch@...il.com
Subject: Re: Linux sends IPv6 NS packets with the link-local address

Hi Steinar,

On Thu, Nov 07, 2013 at 01:29:46AM +0100, Steinar H. Gunderson wrote:
> Since this is a SHOULD, there's nothing inherently _illegal_ about sending the
> packets with the link-layer address as source, but the RFC does have a point.
> Most of the time, Linux indeed seems to be sending with the global source
> address (heeding the SHOULD), and again, for some reason it suddenly switches
> to it in this case.
> 
> Would anyone happen to know why it uses the link-local in the first place,
> and why it suddenly changes its mind after ten tries or so? I'm not sure if I
> can _force_ this behavior, but judging from a tcpdump, it happens many times
> a day from that specific machine.

I am currently a bit busy to look into this closely but maybe there is
a patch which does help; it is currently in net-next:

<https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/net/core/neighbour.c?id=4ed377e36ec2f385484d12e516faf88516fad31c>

Problem was, if we enqueue a packet to the resolving queue we use those
packets source address as the address we use as the source address. This
patch chooses the last enqueued skb's source address to do the resolving
thus switching over to a global address much more early (hopefully). I
have seen this problem with routers doing uRPF on the source address of
arp packets, too.

Does this happen when you configure addresses? Do your addresses have
a short lifetime advertised by radvd etc?

Greetings,

  Hannes

--
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