[Xorp-hackers] MLD(v2) on Linux 2.6.26-rc7 kernel?

Pavlin Radoslavov pavlin at ICSI.Berkeley.EDU
Tue Jun 24 11:01:24 PDT 2008


Kevin Fall <kfall at cs.berkeley.edu> wrote:

> Hi.  Thanks for the response, but I believe I have found the root of  
> the problem:
> 
> in mfea_proto_com.cc, at about line 2337 there is an assignment to  
> _sndmh.msg_namelen.  This is for IPv6.  For IPv4, however,
> there is an assignment to this field in addition to:
> 
>          _sndmh.msg_control      = NULL;
>          _sndmh.msg_controllen   = 0;
> 
> So, if you add these lines to the IPv6 case, the sendmsg() call no  
> longer fails, but there is a "bonus" core dump later on.
> 
> As a hacky fix, I basically made these fields null around the  
> sendmsg() call and restored them to their previous values after
> the call using a pair of temporary values.  This seems to work and  
> indeed the system runs.
> 
> Of course, this isn't really a very clean fix.  So, I'd recommend  
> somebody with a broader exposure to the whole code base (maybe you :) )
> come up with something a little more "clean".  In any case, the root  
> of the problem is the control fields not being set in a way the
> kernel likes.

Thanks for the debugging of the problem.
>From what you describe I think you are right that the problem is in
the setting of the IPv6 ancillary data (stored in msg_control).
Setting the msg_control data is a bit complicated, and is guarded by
a number of #ifdef so there could be a number of things that have
gone wrong (e.g., the ./configure script didn't discover HAVE_FOO
property, etc).

To debug the problem and to apply the appropriate fix I/we need to
try exactly same setup as you did.
Hence, could you send info about the OS you are using and the
procedure you used to upgrade the kernel (including your kernel
.config file if you compiled it by hand).

Thanks,
Pavlin

> thx,
> - K
> 
> 
> On Jun 23, 2008, at Jun 238:06 PMPDT, Pavlin Radoslavov wrote:
> 
> > Kevin Fall <kfall at cs.berkeley.edu> wrote:
> >
> >> Hi folks.
> >>
> >> I've just this past weekend spun up Xorp to experiment with MLDv2 and
> >> some other things.  After noticing the lack of v6 multicast routing  
> >> in
> >> Linux 2.6.25.x kernels, I build a more bleeding edge 2.6.26 (rc7)
> >> kernel that has v6 multicast routing included-- or at least, says it
> >> does.
> >>
> >> When I run Xorp 1.4 configured to do MLDv2 (on eth3), I see this:
> >>
> >> [ 2008/06/23 09:01:20 TRACE xorp_mld MLD6IGMP ] TX MLD_LISTENER_QUERY
> >> from fe80::204:5aff:fe9f:9e80 to ff02::1
> >> [ 2008/06/23 09:01:20  ERROR xorp_mld:21363 MLD6IGMP +1519
> >> xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cannot
> >> send a protocol message: 102 Command failed Cannot send MLD protocol
> >> message from fe80::204:5aff:fe9f:9e80 to ff02::1 on vif eth3:
> >> sendmsg(proto 58 size 28 from fe80::204:5aff:fe9f:9e80 to ff02::1 on
> >> vif eth3) failed: Invalid argument
> >>
> >> So, before I spend hours digging to figure out just what this is,  
> >> does
> >> somebody already have an idea?
> >
> > Nothing obvious comes to mind. Do you see the problem if you
> > configure to run MLDv1 instead of MLDv2?
> >
> > Could you try to run the latest XORP code from anon. CVS.
> > Number of things have changed in the FEA since the 1.4 release, so
> > there is some chance this problem is gone.
> >
> > BTW, what OS distribution/version are you using, and how did you
> > update the kernel config: i.e., using a built-in mechanism like
> > apt-get or just downloading from kernel.org and compiling by hand?
> >
> > Could you send your kernel .config file as well.
> >
> > Pavlin
> >
> >
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers



More information about the Xorp-hackers mailing list