[Top] [All Lists]

Re: Kernel 2.4.22 MLD problems

To: Takashi Hibi <hibi665@xxxxxxx>
Subject: Re: Kernel 2.4.22 MLD problems
From: David Stevens <dlstevens@xxxxxxxxxx>
Date: Wed, 10 Dec 2003 00:22:33 -0800
Cc: netdev@xxxxxxxxxxx
Importance: Normal
Sender: netdev-bounce@xxxxxxxxxxx


>But there are still some problems.
>1. After joining multicast address, MLDv2 listener report isn't issued immediately.

This looks like a bug; it should send the first one immediately,
and QRV-1 more at random intervals between 0 and MRC. It's adding
the MRC random delay before sending the first one. Not critical,
but I'll put a patch together in the next couple of days.

>2. After leaving multicast address, MLDv2 listener report is issued, but multicast

> routing doesn't stop. The type of report is ChangeToIncludeMode.
> FreeBSD doesn't seem to stop multicast after receiving it.

"CHANGE_TO_INCLUDE {}" is the MLDv2 "leave group"; if FreeBSD continues
to forward them, I'm guessing that's a problem with FreeBSD, assuming
the report is well-formed. Have you tried with a FreeBSD listener?
I'd be interested in seeing packet traces if Linux and FreeBSD listeners
behave differently with the FreeBSD multicast router for this case.

>1. After joining multicast address, MLDv2 listener report(not MLDv1) is issued.

>  After receiving MLDv2 query, MLDv1 listener report is issued.

MLDv2 is the default. If it has received an MLDv1 query "recently", then
it'll be in "MLDv1 compatibility mode" and will answer with v1 reports, even
for a v2 query. Leaving v1 compatibility mode is based on a timer, not on
the types of subsequent queries. So, you probably don't want to mix testing
unless you're specifically testing the v1 compatibility mode. You should
either have a v1 querier on the net, or a v2 querier, and use only that
version for the whole test. Otherwise, you can get a mix of report versions
depending on when the last v1 query was received.

I'm guessing you joined the group (v2 report scheduled) and then someone
issued a v1 query (switch to v1 compatibility mode), followed by another
(v1) report.

If you don't think there was any v1 query at that time, please do send me
a packet trace, and with the latest 2.6.0 test kernel, if possible. This
worked in my testing.

>2. After leaving multicast address, MLDv2 listener report is sometimes issued.

>  It happens after long communication.

This is the same problem as you listed in "[MLDv2] 1)" -- there's a random
delay between reports, but the code appears to have the delay before the
first report. That's correct for a query, but not an interface state change.

>And I have a question about recent patch.

This patch wasn't submitted to netdev, or the mainline-kernel. It's a version
I created for specific testing and delivered to 2 people. You really want the
latest mainline kernel, which has all of the patches, already integrated.

>This patch doesn't include the following patch.
>Isn't it necessary?

Yes, you probably want that. Again, the latest mainline kernel tree is the
most up-to-date.

Thanks for reporting the problem, and let me know if the explanations for
the other things don't fit what you're doing (with packet traces).


<Prev in Thread] Current Thread [Next in Thread>