Bug#533604: Doesn't bind to IPv6 addresses by default
Stefan Bauer schrieb: > Am 27.02.2010 17:43, Fabian Knittel schrieb: >> With a few tweaks to /etc/gai.conf I managed to change the order: >> >> $ python -c "import socket; print socket.getaddrinfo(None, 'auth', >> 0, socket.SOCK_STREAM, 0, socket.AI_PASSIVE)" >> [(10, 1, 6, '', ('::', 113, 0, 0)), (2, 1, 6, '', ('0.0.0.0', 113))] >> ^^^^^ >>IPv6 IPv4 > > That's how it is displayed in my case. gai.conf is empty. Right now > i dont see, where this behavior comes from. Great, so we've now established the reason for the differences in your and our tests! Although we haven't determined _why_ getaddrinfo behaves differently, it obviously does. oidentd should be able to cope with the difference the same way it should be able to cope with different values for /proc/sys/net/ipv6/bindv6only. The current works / fails matrix as far as I see it: | bindv6only = 0 | bindv6only = 1 --+-+ getaddrinfo -> ipv6 first | works (*) | works getaddrinfo -> ipv4 first | fails to listen on IPv6 | works (**) (*) Although oidentd fails to open the second socket, the failure has no visible effect as the first socket listens for IPv4 and IPv6 traffic simultaneously. (**) This appears to be the default on current squeeze systems with a 2.6.32 Linux kernel. So my patch only makes a difference for one specific system configuration (ipv4 first and bindv6only = 0). > I hope you understand > that i'm very cautious about patching upstream source as long as we > dont have eliminated all the doughts, where this problem really relies. I understand that very well. Too bad we don't have upstream to ease the process. :) >> With the tweak in effect, oidentd worked without my patch - using only a >> single IPv6 socket which accepted both IPv4 and IPv6. (This would break >> for /proc/sys/net/ipv6/bindv6only=1.) > > I can not confirm this either. Please disregard that side-comment, it was a mistake, sorry. If my statement were correct, it would have meant that my proposed patch would break in the "getaddrinfo -> ipv6 first" case. The above matrix should correctly reflect the cases where it fails / succeeds. > I just enabled bindv6only and tried > to connect again to oidentd on ipv4 and ipv6: > > Mar 1 09:04:34 black oidentd[18481]: Connection from > cl-849.dus-01.de.sixxs.net (2a01:198:200:350::2):39062 > Mar 1 09:04:42 black oidentd[18490]: Connection from > p5B0822FB.dip0.t-ipconnect.de (91.8.34.251):1548 > > black:/home/sb# lsof -itcp:113 > COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME > oidentd 18443 oident6u IPv6 48082507 TCP *:auth (LISTEN) > oidentd 18443 oident7u IPv4 48082508 TCP *:auth (LISTEN) > > Now it binds two 2 single sockets but that's really no advantage or > disadvantage at all. Correct. In the bindv6only=1 case _or_ with my patch, there will always be two single sockets. In the bindv6only=0 case and without my patch, there will always only be a single socket. The second socket will conflict with the first and (silently) fail to open. I've attached my /etc/gai.conf with all assumed defaults enabled. I don't know whether that suffices to achieve "getaddrinfo -> ipv4 first" on your system, but it might be worth a try and works on my system. Cheers Fabian # Configuration for getaddrinfo(3). # # So far only configuration for the destination address sorting is needed. # RFC 3484 governs the sorting. But the RFC also says that system # administrators should be able to overwrite the defaults. This can be # achieved here. # # All lines have an initial identifier specifying the option followed by # up to two values. Information specified in this file replaces the # default information. Complete absence of data of one kind causes the # appropriate default information to be used. The supported commands include: # # reload #If set to yes, each getaddrinfo(3) call will check whether this file #changed and if necessary reload. This option should not really be #used. There are possible runtime problems. The default is no. # # label #Add another rule to the RFC 3484 label table. See section 2.1 in #RFC 3484. The default is: # label ::1/128 0 label ::/0 1 label 2002::/16 2 label ::/96 3 label :::0:0/96 4 label fec0::/10 5 label fc00::/7 6 label 2001:0::/32 7 # #This default differs from the tables given in RFC 3484 by handling #(now obsolete) site-local IPv6 addresses and Unique Local Addresses. #The reason for this difference is that these addresses are never #NATed while IPv4 site-local addresses most probably are. Given #the precedence of IPv6 over IPv4 (see below) on machines having only #site-local IPv4 and IPv6 addresses a lookup for a global address would #s
Bug#533604: Doesn't bind to IPv6 addresses by default
Am 27.02.2010 17:43, Fabian Knittel schrieb: > With a few tweaks to /etc/gai.conf I managed to change the order: > > $ python -c "import socket; print socket.getaddrinfo(None, 'auth', > 0, socket.SOCK_STREAM, 0, socket.AI_PASSIVE)" > [(10, 1, 6, '', ('::', 113, 0, 0)), (2, 1, 6, '', ('0.0.0.0', 113))] > ^^^^^ >IPv6 IPv4 That's how it is displayed in my case. gai.conf is empty. Right now i dont see, where this behavior comes from. I hope you understand that i'm very cautious about patching upstream source as long as we dont have eliminated all the doughts, where this problem really relies. > With the tweak in effect, oidentd worked without my patch - using only a > single IPv6 socket which accepted both IPv4 and IPv6. (This would break > for /proc/sys/net/ipv6/bindv6only=1.) I can not confirm this either. I just enabled bindv6only and tried to connect again to oidentd on ipv4 and ipv6: Mar 1 09:04:34 black oidentd[18481]: Connection from cl-849.dus-01.de.sixxs.net (2a01:198:200:350::2):39062 Mar 1 09:04:42 black oidentd[18490]: Connection from p5B0822FB.dip0.t-ipconnect.de (91.8.34.251):1548 black:/home/sb# lsof -itcp:113 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME oidentd 18443 oident6u IPv6 48082507 TCP *:auth (LISTEN) oidentd 18443 oident7u IPv4 48082508 TCP *:auth (LISTEN) Now it binds two 2 single sockets but that's really no advantage or disadvantage at all. Stefan -- Stefan Bauer - PGP: E80A 50D5 2D46 341C A887 F05D 5C81 5858 DCEF 8C34 plzk.de - Linux - because it works -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533604: Doesn't bind to IPv6 addresses by default
Stefan Bauer schrieb: > Sounds logical, i just cant confirm this thesis: Ah sorry, I didn't realise that you couldn't confirm the bug report. I thought we were only discussing the best possible solution. > black:/home/sb# cat /proc/sys/net/ipv6/bindv6only > 0 > > black:/home/sb# ps aux |grep oidentd > oident 19815 0.0 0.0 12236 620 ?Ss 09:10 0:00 > /usr/sbin/oidentd -mf -P 80.82.223.1 -u oident -g oident > > So bindv6only is disabled and oidentd has not been started with any > option passed to -a > > black:/home/sb# telnet -6 red.cubewerk.de 113 > Trying 2a01:198:200:350::2... > Connected to cl-849.dus-01.de.sixxs.net. > Escape character is '^]'. > > > C:\Documents and Settings\Administrator>telnet red.cubewerk.de 113 > > > oidentd log stanza: > > Feb 25 22:58:08 black oidentd[28955]: Connection from > cl-849.dus-01.de.sixxs.net (2a01:198:200:350::2):60665 > > As well as ... at almost the same time: > > Feb 25 22:58:37 black oidentd[28956]: Connection from > p5B0820FE.dip0.t-ipconnect.de (91.8.32.254):0 > > We have 2 requests on ipv4 and ipv6 at the same time. Oidentd > handles both at the same time. Does your oidentd possibly only have a single IPv6 socket? That would explain why everything appears to work for you... oidentd uses getaddrinfo() to determine what sockets to open for listening. On the systems I checked, getaddrinfo() returns the IPv4 address first and IPv6 address second: $ python -c "import socket; print socket.getaddrinfo(None, 'auth', 0, socket.SOCK_STREAM, 0, socket.AI_PASSIVE)" [(2, 1, 6, '', ('0.0.0.0', 113)), (10, 1, 6, '', ('::', 113, 0, 0))] ^^^ ^^ IPv4 IPv6 With a few tweaks to /etc/gai.conf I managed to change the order: $ python -c "import socket; print socket.getaddrinfo(None, 'auth', 0, socket.SOCK_STREAM, 0, socket.AI_PASSIVE)" [(10, 1, 6, '', ('::', 113, 0, 0)), (2, 1, 6, '', ('0.0.0.0', 113))] ^^^^^ IPv6 IPv4 With the tweak in effect, oidentd worked without my patch - using only a single IPv6 socket which accepted both IPv4 and IPv6. (This would break for /proc/sys/net/ipv6/bindv6only=1.) >> 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. > > I tried to get in contact with upstream but had no luck. Oh, I see. Have a nice week-end Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533604: Doesn't bind to IPv6 addresses by default
Am 25.02.2010 22:00, Fabian Knittel schrieb: > 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.) Sounds logical, i just cant confirm this thesis: black:/home/sb# cat /proc/sys/net/ipv6/bindv6only 0 black:/home/sb# ps aux |grep oidentd oident 19815 0.0 0.0 12236 620 ?Ss 09:10 0:00 /usr/sbin/oidentd -mf -P 80.82.223.1 -u oident -g oident So bindv6only is disabled and oidentd has not been started with any option passed to -a black:/home/sb# telnet -6 red.cubewerk.de 113 Trying 2a01:198:200:350::2... Connected to cl-849.dus-01.de.sixxs.net. Escape character is '^]'. C:\Documents and Settings\Administrator>telnet red.cubewerk.de 113 oidentd log stanza: Feb 25 22:58:08 black oidentd[28955]: Connection from cl-849.dus-01.de.sixxs.net (2a01:198:200:350::2):60665 As well as ... at almost the same time: Feb 25 22:58:37 black oidentd[28956]: Connection from p5B0820FE.dip0.t-ipconnect.de (91.8.32.254):0 We have 2 requests on ipv4 and ipv6 at the same time. Oidentd handles both at the same time. > 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. I tried to get in contact with upstream but had no luck. thanks for your time. Stefan -- Stefan Bauer - PGP: E80A 50D5 2D46 341C A887 F05D 5C81 5858 DCEF 8C34 plzk.de - Linux - because it works -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533604: Doesn't bind to IPv6 addresses by default
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: > > 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
Bug#533604: Doesn't bind to IPv6 addresses by default
Am 25.02.2010 12:53, Fabian Knittel schrieb: > Stefan Bauer schrieb: >> Follow up - tested on a lenny machine which turns me nuts: >> >> bindv6only=0 >> /etc/default/oidentd is without any -a stanzas >> black:/home/sb# lsof -itcp:113 >> COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME >> oidentd 19499 oident6u IPv6 47082698 TCP *:auth (LISTEN) >> >> >> Even though it shows for unknown reasons only a bind to >> ipv6-addresses, the machine answers correctly ident-requests on ipv4 >> and ipv6 address: >> >> tcp6 0 0 [::]:auth [::]:* >> LISTEN root 4708269819499/oidentd > > 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: 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. 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. 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. Stefan -- Stefan Bauer - PGP: E80A 50D5 2D46 341C A887 F05D 5C81 5858 DCEF 8C34 plzk.de - Linux - because it works -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533604: Doesn't bind to IPv6 addresses by default
Stefan Bauer schrieb: > Follow up - tested on a lenny machine which turns me nuts: > > bindv6only=0 > /etc/default/oidentd is without any -a stanzas > black:/home/sb# lsof -itcp:113 > COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME > oidentd 19499 oident6u IPv6 47082698 TCP *:auth (LISTEN) > > > Even though it shows for unknown reasons only a bind to > ipv6-addresses, the machine answers correctly ident-requests on ipv4 > and ipv6 address: > > tcp6 0 0 [::]:auth [::]:* > LISTEN root 4708269819499/oidentd 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? Cheers Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533604: Doesn't bind to IPv6 addresses by default
Am 24.02.2010 23:53, Fabian Knittel schrieb: > So for some use cases, the patch might cause a slight regression and an > enhanced patch would be necessary. The patch would need to resolve the > hostname passed via -a to all possible IPv4 and IPv6 adresses (instead > of only the first) and create listening sockets for each address. Follow up - tested on a lenny machine which turns me nuts: bindv6only=0 /etc/default/oidentd is without any -a stanzas black:/home/sb# lsof -itcp:113 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME oidentd 19499 oident6u IPv6 47082698 TCP *:auth (LISTEN) Even though it shows for unknown reasons only a bind to ipv6-addresses, the machine answers correctly ident-requests on ipv4 and ipv6 address: tcp6 0 0 [::]:auth [::]:* LISTEN root 4708269819499/oidentd If i set bindv6only=1 it changes the behavior of the output but not the binding on interfaces: black:/home/sb# lsof -itcp:113 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME oidentd 19640 oident6u IPv6 47085390 TCP *:auth (LISTEN) oidentd 19640 oident7u IPv4 47085391 TCP *:auth (LISTEN) tcp0 0 *:auth *:* LISTEN root 4708659919723/oidentd tcp6 0 0 [::]:auth [::]:* LISTEN root 4708659819723/oidentd At a first glance, it behaves as it should. Stefan -- Stefan Bauer - PGP: E80A 50D5 2D46 341C A887 F05D 5C81 5858 DCEF 8C34 plzk.de - Linux - because it works -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533604: Doesn't bind to IPv6 addresses by default
tag 533604 +patch thanks Hi, Stefan Bauer wrote: > Am 23.02.2010 12:15, Philipp Kern schrieb: >> Stefan, >> >> am Tue, Feb 23, 2010 at 12:06:04PM +0100 hast du folgendes geschrieben: >>> i'm aware of that problem but still seeking for an easy solution as >>> i'm not familiar with socket programming. bindv6only is a pain in >>> the nack right now for several packages. The attached patch activates bindv6only on all IPv6 sockets used by oidentd. This should avoid the problem experienced by Michael and Phil. >> but, after some thought I just activated "-a ::" for now (i.e. the proposal >> mentioned in the initial mail of the bug report) which works well with both >> IPv4 and IPv6. BTW: With the patch applied, the work-around will no longer work, as "-a ::" will only listen on IPv6. >> I guess you need two sockets, one with AF_INET6 und one >> with AF_INET That's the approach already taken by oidentd - at least if you don't use "-a". With "-a" oidentd only uses a single socket and together with my patch oidentd will only listen on either IPv6 or IPv4 (depending on what the passed hostname resolves to). So for some use cases, the patch might cause a slight regression and an enhanced patch would be necessary. The patch would need to resolve the hostname passed via -a to all possible IPv4 and IPv6 adresses (instead of only the first) and create listening sockets for each address. > and it should bail out if one of the two can be opened? :) As far as I can tell, it currently only bails out if _none_ of the sockets were successfully opened. > Chainging directly the behavior on the socket should do the trick > the best way. Maybe i will add the "-a ::" so called bind to all > stanza in a newer release as default coz this seems by now to be the > most comfortable "workaround". Would that work on systems with blacklisted ipv6 linux kernel module? (Some people still do that.) Cheers Fabian diff --git a/src/oidentd_inet_util.c b/src/oidentd_inet_util.c index fcc8a72..8497563 100644 --- a/src/oidentd_inet_util.c +++ b/src/oidentd_inet_util.c @@ -60,6 +60,12 @@ static int setup_bind(const struct addrinfo *ai, in_port_t listen_port) { #ifdef WANT_IPV6 case AF_INET6: SIN6(ai->ai_addr)->sin6_port = listen_port; + + if (setsockopt(listenfd, IPPROTO_IPV6, IPV6_V6ONLY, &one, + sizeof(one)) != 0) { +debug("setsockopt IPV6_V6ONLY: %s", strerror(errno)); +return (-1); + } break; #endif
Bug#533604: Doesn't bind to IPv6 addresses by default
Package: oidentd Version: 2.0.8-1.2 The oidentd man page states, in the description for the "-a" option, that "The default is to listen for connections on all configured IP addresses" -- but the program actually only listens on IPv4 addresses by default. I had to set OIDENT_OPTIONS="-a ::" in /etc/default/oidentd to get it to listen on all addresses. Ideally the program would be changed to match the documented behaviour; otherwise, the man page should be updated. - Michael -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages oidentd depends on: ii adduser 3.110 add and remove users and groups ii libc6 2.9-13 GNU C Library: Shared libraries ii netbase 4.34 Basic TCP/IP networking system oidentd recommends no packages. oidentd suggests no packages. -- no debconf information signature.asc Description: Digital signature