onsdag den 19 januari 2011 klockan 11:16 skrev Simon Josefsson detta: > Mats Erik Andersson <[email protected]> writes: > > > onsdag den 19 januari 2011 klockan 08:24 skrev Simon Josefsson detta: > >> Mats Erik Andersson <[email protected]> writes: > >> [...] > > > > a) Do you like the call "logger --ipv6 ..." to print the warning to stderr, > > attempt the requested logging message via IPv4, and also exit execution > > with a non-zero exit code? Presently the exit code is zero, but the > > other two parts are included in my suggestion. > > > > b) Do you desire the IPv6 failure to log a local message about the > > inability to use that transport, thus producing two log messages: > > the intended text which is possibly non-local and the additional > > failure report which remains on the local workstation/server? > > I haven't made up my mind, but wanted to bring this aspect up for > discussion. > > Other InetUtils tools fails when passed a -6 and IPv6 is not working, > for example: > > jas@latte:~$ telnet gnu.org > Trying 140.186.70.148... > ^C > jas@latte:~$ telnet -6 gnu.org > gnu.org/telnet: lookup failure: No address associated with hostname > jas@latte:~$ > > Generally, it feels more natural for a tool to fail when it cannot do > what it is asked to, rather than give a warning and do something else.
This behaviour is present if GNU Inetutils is compiled with IPv6 support: $ ./src/logger -6 -h gnu.org -p user.debug Testing IU-logger ./src/logger: no address associated with name, gnu.org:syslog. $ echo $? 1 It is in a situation where compilation was done without IPv6 support, that the logger client takes the liberty of ignoring `-6', uses IPv4, sends the message, and emits a warning for the user. Thus it is really single stacked IPv4-machines that are expected to rescue the user. On all up to date machines the options `-4' and `-6' will abort with errors if the host, port, and source are not able to fit the chosen domain. > > Typically users won't use --ipv4 or --ipv6 but rather use a hostname, > and let the getaddrinfo() do its magic of selecting ipv4 vs ipv6, right? This is an important point. Presently I have set AF_UNSPEC when both flags are missing (and the compilation had "#define HAVE_IPV6 1"). Since UDP is carrying the message, this means that any dual stacked host with existing A and AAAA DNS-entries might be contacted via a domain where the syslog service does not listen, if it was set up in an asymmetric manner. Can it be argued that AF_INET still should be the default? Bearing in mind that the migration to IPv6 is still in its beginning. I do not know for certain yet. Regards, Mats
