Stefan Bauer schrieb: > Am 25.02.2010 12:53, Fabian Knittel schrieb: >> That's really weird... I can properly see both sockets (IPv4 and IPv6) >> with lsof and netstat (bindv6only=0). >> >> But I'm running squeeze and linux kernel image 2.6.32-trunk-amd64, so >> maybe there's a display bug on lenny somewhere? > > I just came up with that question on irc - here is the answer: > > <sf> Normalerweise werden die ipv4 adressen in den ipv6 adressraum > gemappt. Ein IPv6 Socket bekommt dann beides. Ausser Du schaltest > dieses verhalten ab (mit /proc/sys/net/ipv6/bindv6only oder > setsockopt, man ipv6). > > [english translation) > Basically ipv4 addresses get mapped into the ipv6-address space. A > ipv6-socket includes both then. This behavior can changed either by > setting bindv6only in /proc or by setting it directly on the socket.
Correct. My patch implements the second approach - it uses setsockopt to set bindv6only to 1. I.e. this is like setting /proc/sys/net/ipv6/bindv6only to 1, but only for the oidentd application. As you noted, this appears to work fine. I'm still not sure why you're lsof output differs, though and that's what my previous mail was going on about. Let me take a step back and try to explain the current situation as I see it. The situation without my patch: * Without the "-a" option, oidentd opens two listening sockets: The first socket for IPv4 and the second for IPv6. If /proc/sys/net/ipv6/bindv6only is 0, the second socket will fail to open. It fails, because it attempts to listen for both IPv4 and IPv6 packets, but the IPv4 case is _already_ handled by the first socket, so there's a conflict. oidentd continues to run, but only listens on the first socket which only processes IPv4 traffic. (This is the problem reported in this bug report.) If /proc/sys/net/ipv6/bindv6only is 1, the second socket will successfully open, because it only attempts to listen for IPv6 and nobody is doing that yet. oidentd would correctly listen on both sockets and correctly process IPv4 and IPv6 traffic. * With the "-a" option, oidentd opens a single listening socket. If /proc/sys/net/ipv6/bindv6only is 0 the hostname/address passed as "-a" parameter is resolved and the first resulting address is used as listener end-point. If the address is an IPv6-address or the hostname resolves to an IPv6-address, oidentd will listen for IPv6 and IPv4 traffic. If /proc/sys/net/ipv6/bindv6only is 1 the hostname/address passed as "-a" parameter is resolved and the first resulting address is used as listener end-point. If the hostname only resolves to an IPv4 address, oidentd will only listen for IPv4. Otherwise, oidentd will only listen for IPv6 traffic. The situation _with_ my patch: The state of /proc/sys/net/ipv6/bindv6only is no longer of any interest. oidentd works as if bindv6only were set to 1. * Without the "-a" option, oidentd opens two listening sockets: The first socket for IPv4 and the second for IPv6. The second socket will successfully open, because it only attempts to listen for IPv6 and nobody is doing that yet. oidentd would correctly listen on both sockets and correctly process IPv4 and IPv6 traffic. * With the "-a" option, oidentd opens a single listening socket. If the hostname/address passed as "-a" parameter is resolved and the first resulting address is used as listener end-point. If the hostname only resolves to an IPv4 address, oidentd will only listen for IPv4. Otherwise, oidentd will only listen for IPv6 traffic. > Anyway, i'm still unsure, where the problem relies if there is any > at all because -a :: is not a workaround it's more an available > option to set. If the system has /proc/sys/net/ipv6/bindv6only set to 1 (or if my patch were applied), setting "-a ::" as default for the Debian package would break IPv4 support (oidentd would only listen on IPv6). So "-a ::" is no proper work-around. > As debian sets nowadays bindv6only by default, it works by default. > For the ones, wo need to change that, i will include a note in the > default/oidentd file. Debian's default is bindv6only=1. My patch assures that bindv6only is 1 for oidentd even on systems where bindv6only=0. So there's no change for the Debian default and bug 533604 is fixed for the case where the default _isn't_ used. In any case, this bug should probably be fixed upstream, so you might want to forward it to Ryan (in case he's still the active upstream?). Or if you'd like, I could forward my patch to him myself. Cheers Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
