Kevin et al, I finally managed to debug the problem after installing OS (Debian) with Linux kernel 2.6.26. There were few (mostly compilation) errors which are now fixed in CVS.
The original problem with the buggy inet6_opt_init() is still there, but you might want to have a look in Bugzilla entry #761 which contains a hack to get around it: http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=761 Hence, if you want to try XORP with 2.6.26 kernel you should get the latest code from CVS and then apply the hack from Bugzilla entry #761. Note that I haven't tested whether IPv6 multicast routing with that kernel actually works. Any feedbacks are welcome. Thanks, Pavlin Pavlin Radoslavov <[EMAIL PROTECTED]> wrote: > Kevin Fall <[EMAIL PROTECTED]> wrote: > > > Ok, this took me most of the day (unfortunately), but here it is: > > > > I am running on a Redhat linux system, and my problem was due to the issue > > discussed here: > > > > http://sourceware.org/bugzilla/show_bug.cgi?id=5760 > > > > Basically, inet6_opt_init() was setting the v6 extension header length to > > the > > value 1 instead of 0, even for small > > extensions like the HBH/RtAlert one. > > > > This is wrong. But the consequence is that the apparent size of the > > option + > > cmsg structure was > > too big. If cmsg_len is appropriately trimmed to the option size based on > > return values of inet_opt_XX, then the kernel (correctly) gives an EINVAL > > because it thinks > > the option is longer than the ancillary data provided to hold it :(. > > Thanks for the info. The problem appears to be in glibc and > according to the above Bugzilla entry it has been fixed in their > repository. > > I didn't understand your comment about cmsg_len. Are you suggesting > that its value should be set by using the return value of, say, > inet6_opt_init(), inet6_opt_append(), etc? > Currently, cmsg_len is set by using the following assignment: > cmsgp->cmsg_len = CMSG_LEN(...) > which is actually based on the sample code from RFC 3542. > > > Attached is the .config for you. I'm looking into the best way to fix > > this, > > but it would appear > > that verifying and whacking as necessary the header produced by > > inet6_opt_init would be a first step. > > It looks like the RFC3542 support for Linux has some issues. > The right solution for Router Alert problem would be to apply the > glibc fix for inet6_opt_init(). > > > I don't know whether the original issue (the "Invalid argument" > error) is related to the inet6_opt_init(), but anyway I just added a > Bugzilla entry on your behalf re. the "Invalid argument" issue you > were seeing: > http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=761 > > I wish I have the time to start playing with the 2.6.26 release > candidates. Unfortunately I would have to wait until Linux > kernel 2.6.26 is released and is available for Ubuntu before I try > to fix it. > This will also tell us whether the problem is RedHat specific or > applies to more than one distribution. > > In the mean time please add any additional information on the > subject to the new Bugzilla entry. > > > Pavlin > > > > thx, > > > > - K > > > > On Jul 7, 2008, at Jul 712:22 AMPDT, Pavlin Radoslavov wrote: > > > > >> It appears to me that MLD query messages do not include the HBH/ Router- > > >> Alert extension header. I believe this is incorrect. > > >> (queries need to be processed by non-querier multicast routers on the > > >> same subnet). Can somebody very/explain whether > > >> I have this correct? > > > > > > Yes, all MLD messages must include the IPv6 Router Alert option. > > > I just tested it on FreeBSD-7.0, and the Query messages actually > > > include the Router Alert extension header, so the problem is > > > probably OS-specific. > > > > > > If this option is missing in your setup, then this is a bug. In that > > > case please submit a Bugzilla entry with information how to > > > reproduce the problem, OS version, etc. > > > > > > Pavlin > > > (still waiting for your .config Linux kernel config file :) > > > > > > > _______________________________________________ > > Xorp-hackers mailing list > > [email protected] > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > Xorp-hackers mailing list > [email protected] > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
