From: Bernhard Schmidt <berni@birkenwald.de>
To: David Stevens <dlstevens@us.ibm.com>
Cc: "Rémi Denis-Courmont" <rdenis@simphalempin.com>,
"Brian Haley" <brian.haley@hp.com>,
netdev@vger.kernel.org
Subject: Re: [IPv6] "sendmsg: invalid argument" to multicast group after some time
Date: Tue, 9 Sep 2008 12:06:20 +0200 [thread overview]
Message-ID: <20080909100620.GA18584@pest> (raw)
In-Reply-To: <OF3335B3DD.83510AA3-ON882574BF.00275BAF-882574BF.00281037@us.ibm.com>
On Tue, Sep 09, 2008 at 12:17:35AM -0700, David Stevens wrote:
> netdev-owner@vger.kernel.org wrote on 09/08/2008 11:52:05 PM:
>
> >
> > On Tue, 9 Sep 2008 02:38:53 +0200, Bernhard Schmidt
> <berni@birkenwald.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
next prev parent reply other threads:[~2008-09-09 10:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-31 18:20 [IPv6] "sendmsg: invalid argument" to multicast group after some time Bernhard Schmidt
2008-09-01 5:49 ` David Stevens
2008-09-01 9:09 ` Bernhard Schmidt
2008-09-01 13:03 ` David Stevens
2008-09-01 17:01 ` Bernhard Schmidt
2008-09-01 17:05 ` Bernhard Schmidt
2008-09-01 17:57 ` Pekka Savola
2008-09-01 18:03 ` Bernhard Schmidt
2008-09-02 9:06 ` Pekka Savola
2008-09-02 13:57 ` Brian Haley
2008-09-02 15:00 ` Bernhard Schmidt
2008-09-02 15:48 ` Brian Haley
2008-09-09 0:34 ` David Stevens
2008-09-09 0:38 ` Bernhard Schmidt
2008-09-09 2:26 ` David Stevens
2008-09-09 6:52 ` Rémi Denis-Courmont
2008-09-09 7:17 ` David Stevens
2008-09-09 10:06 ` Bernhard Schmidt [this message]
2008-09-09 15:05 ` David Stevens
2008-09-09 17:16 ` Pekka Savola
2008-09-09 20:13 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2008-12-28 4:47 Eduard Guzovsky
2008-12-30 7:52 David Miller
2008-12-31 19:53 ` Eduard Guzovsky
2009-01-04 23:56 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080909100620.GA18584@pest \
--to=berni@birkenwald.de \
--cc=brian.haley@hp.com \
--cc=dlstevens@us.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=rdenis@simphalempin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).