Question about MLDv2 implemenation in Kernel

[GuYong]

Hi, 
The issues are observed from my testing, so I'm 90% sure those issues are real.   see my answers below!
> Date: Thu, 21 Jun 2012 10:20:57 +0100
> From: bms at fastmail.net
> To: rpaulo at felyko.com
> CC: freebsd-net at freebsd.org; bms at freebsd.org; guyong1978 at hotmail.com
> Subject: Re: Question about MLDv2 implemenation in Kernel
> 
> All,
> 
> I'm working on something new just now,and am in a conference, but here
> is my 2p.
> 
> On 20/06/12 22:20, Rui Paulo wrote:
> > On 20 Jun 2012, at 01:12, GuYong <guyong1978 at hotmail.com> wrote:
> >> 1.  RFC3810 clause 6.1 mentions there is a Source Retransmission Counter associated to each source, so that the merged report could contain the content that is interrupted by a new state change report          BUT, I didn't see this is implemented currently!
> > I think this is stored in the mli_rv variable and decremented accordingly.
> 
> Merging of pending state-changes is performed by
> mld_v2_merge_state_changes() and runs on a per-group basis for the
> end-station.
If the new state change occurs before the first transmission of previous state change report, the two reports will be merged.But if new state change occurs after first transmisson and before retransmission of first report, the pending retransmission report is deleted from the queue.     static int  mld_handle_state_change( )     {             ....             _IF_DRAIN(&inm->in6m_scq);    //deleted here!!!!             retval = mld_v2_enqueue_group_record(&inm->in6m_scq, inm, 1, 0, 0, (mli->mli_flags & MLIF_USEALLOW));     }  As no source retransmission counter is associated, the retransmission of previous report is missed. 
> 
> mli_rv controls the retransmission report count.
> 
> > I think you're right and it should be divided by MLD_TIMER_SCALE.
> 
> ENOTIME to look into this further, but if someone sends me a working
> patch, I will review and commit.
> 
> 
> > My reading of it suggests that we are doing the right thing. We do
> > accept it and process it, but, like the text implies, we shouldn't
> > take any action.
> 
> I concur.
 I don't agree, although general query is usually addressed to FF02::1, but kernel should not care about the IP destination of MLDv2 query, and respond with report.  I see this is how Linux does.  What's more, RFC6636 metions the general query could be unicasted to host for some purpose. 
> 
> Bruce
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"