[Olsr-dev] mtu problem with multicast ipv6 packets

John Hay (spam-protected)
Wed Dec 3 19:39:13 CET 2008

On Wed, Dec 03, 2008 at 12:29:25PM +0100, Bernd Petrovitsch wrote:
> On Tue, 2008-12-02 at 18:22 +0200, John Hay wrote:
> > Was this ever committed or is something more needed?
> A person to do it was needed;-)
> Apart from the conflicts (which are trivially fixed if you are the
> person which changed the "offending" lines - see the attached patch), I
> get a compile error on Fedora 6 (which is quite old and officially dead)
> and CentOS-5/RHEL-5 (which is pretty current for the "stable RedHat
> world"):
> IPV6_MIN_MTU comes from linux/ipv6.h which is part of the kernel-header
> package. And e.g "struct in6_pktinfo" is also define there.
> But "struct in6_pktinfo" is also defined in netinet/in.h which comes
> from the glibc-headers package.
> And I can't find in the above .h files some preprocessor symbol to make
> that magically work.
> Hmm, ATM I have no idea how to solve that (and the root cause in the .h
> files from the different packages).
> Another issue (which has basically nothing to do with the patch):
> We have two "ioctl(SIOCGIFMTU)" calls and both behave different if they
> fail. I don't think that makes sense.
> The sane strategy is IMHO: *if* the ioctl(SIOCGIFMTU) succeeds, we
> simply believe the result as the currently running IP stack should know
> that (and do not limit it with some constants from some RFCs) and use
> the constants only if the ioctl() fails (for whatever reason).

The issue is that what we actually need is an ioctl that return the ipv6
multicast mtu, but I think it does not exist. The mtu that SIOCGIFMTU
returns is the mtu for the interface, but in the ipv6 case we use
multicast and there the rfc (and FreeBSD and probably all the other Kame
derived ipv6 stacks) limit the multicast mtu because the kernel cannot
know what the mtu further on will be. And path mtu dicovery does not
work with multicast.

Or did I misunderstand you?

John Hay -- (spam-protected) / (spam-protected)

More information about the Olsr-dev mailing list