netdev - Re: [IPv6] "sendmsg: invalid argument" to multicast group after some time

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:	Tue, 9 Sep 2008 12:06:20 +0200
From:	Bernhard Schmidt <berni@...kenwald.de>
To:	David Stevens <dlstevens@...ibm.com>
Cc:	Rémi Denis-Courmont <rdenis@...phalempin.com>,
	Brian Haley <brian.haley@...com>, netdev@...r.kernel.org
Subject: Re: [IPv6] "sendmsg: invalid argument" to multicast group after
	some time

On Tue, Sep 09, 2008 at 12:17:35AM -0700, David Stevens wrote:
> netdev-owner@...r.kernel.org wrote on 09/08/2008 11:52:05 PM:
> 
> > 
> > On Tue, 9 Sep 2008 02:38:53 +0200, Bernhard Schmidt 
> <berni@...kenwald.de>
> > 
> > wrote:
> > 
> > > ff00::/8 dev teredo  metric 256  mtu 1280 advmss 1220 hoplimit 
> 4294967295
> > 
> >                ^^^^^^
> > 
> > Uho... that interface is not multicast-capable. Not sure how the kernel
> > handles the conflicting routes.
> 
>         Multicast programs shouldn't rely on the routing
> table at all, IMAO. Unicast routing has nothing at all
> to do with multicast routing, where a single address
> means copying and forwarding to multiple different
> segments, and the address has nothing at all to do with
> the routing topology.

I agree with you that it should not rely on it. However, it obviously
did (in some way):

miredo:~# ip -6 route del ff00::/8 dev teredo  metric 256  mtu 1280 advmss 1220 hoplimit 4294967295                           
miredo:~# ping6 -I eth0 ff02::9
PING ff02::9(ff02::9) from fe80::216:3eff:feb9:29f5 eth0: 56 data bytes
64 bytes from fe80::216:3eff:feb9:29f5: icmp_seq=1 ttl=64 time=0.098 ms
64 bytes from fe80::2c0:9fff:fe4b:8ccf: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::20c:86ff:fe9a:3819: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
64 bytes from fe80::20c:86ff:fe9a:2819: icmp_seq=1 ttl=64 time=0.472 ms (DUP!)

I'm not convinced that this route was the culprit though, I think it
might be related to some sort of routing-table locking foo that got
resolved when I changed something. I'll keep it running (will take one
or two days max to reappear) and try deleting an arbitrary route when it
happens again.

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