On Wed, 2008-12-03 at 20:39 +0200, John Hay wrote: > 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? Not really (I think). So basically we need to check/adjust the returned value from the ioctl(SIOCGIFMTU) for the IPv6 case. IPv4 too? Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services