Le samedi 7 octobre 2006 19:39, Noah Meyerhans a écrit : > On Sat, Oct 07, 2006 at 05:03:37PM +0300, R??mi Denis-Courmont wrote: > > With the binary currently in unstable: > > % ping6 ::1 > > PING ::1(::1) 56 data bytes > > 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.058 ms > > > > --- ::1 ping statistics --- > > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > > rtt min/avg/max/mdev = 0.058/0.058/0.058/0.000 ms > > > > With the binary obtained from unmodified Debian source: > > % ping6 ::1 > > can't receive hop limit: Protocol not available > > > > I've not checked yet, but my best guess is a mixup between the > > RFC2292- and RFC3542-style socket options.
Indeed, putting IPV6_RECVHOPLIMIT instead of IPV6_HOPLIMIT at ping6.c:485 seems to solve the problem. > So, just out of curiosity, if the source doesn't build a working > binary, where do you suppose the working binaries in unstable > actually came from? I presume the problem is with some newer linux-kernel-headers since the build. With RFC2292, IPV6_HOPLIMIT(8) was used both as a socket option and for ancilliary data (CMSG_* thingy). With RFC3542, the socket option becomes IPV6_RECVHOPLIMIT(51) while the ancilliary data still users IPV6_HOPLIMIT(52). I don't know when the kernel switched; I thinkg glibc switches with 2.4 (which is post Etch), but iputils has the peculiarity of using the linux kernel headers instead of the glibc ones. Regards, -- Rémi Denis-Courmont http://www.remlab.net/
pgpPP35Y8O51j.pgp
Description: PGP signature
