Bug#533604: Doesn't bind to IPv6 addresses by default

2010-03-01 Thread Stefan Bauer 
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

2010-03-01 Thread Fabian Knittel 
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  yes|no
#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   mask   value
#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
#see the IPv6 be preferred.  The result

Bug#533604: Doesn't bind to IPv6 addresses by default

2010-02-27 Thread Fabian Knittel 
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\Administratortelnet 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

2010-02-25 Thread Stefan Bauer 
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

2010-02-25 Thread Fabian Knittel 
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

2010-02-25 Thread Stefan Bauer 
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:

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.

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

2010-02-25 Thread Fabian Knittel 
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

Bug#533604: Doesn't bind to IPv6 addresses by default

2010-02-25 Thread Stefan Bauer 
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\Administratortelnet 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

2010-02-24 Thread Fabian Knittel 
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

2009-06-19 Thread Michael Gold 
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