Bug 62893

I'm not planning on fixing this terribly soon - IPv6 support is not a high
priority - but patches are welcome if my priorities don't mesh with yours.

Is "needinfo" a request for loglines?

Here they are:

Apr 15 20:37:37 tunnel sshd[29910]: Accepted publickey for user1 from 
::ffff:80.128.91.202 port 60005 ssh2
Apr 15 21:21:41 tunnel sshd[11930]: Could not reverse map address 
2002:5080:5bca:0123:2e0:18ff:fe01:2345.
Apr 15 21:21:47 tunnel sshd[11930]: Failed password for root from 
2002:5080:5bca:f101:2e0:18ff:fe01:2345 port 32932 ssh2
Apr 15 21:21:49 tunnel sshd[11930]: Accepted password for root from 
2002:5080:5bca:f101:2e0:18ff:fe01:2345 port 32932 ssh2

Just a parking state until someone submits a patch or the upstream version fixes it.

*** Bug 69243 has been marked as a duplicate of this bug. ***

I'm using now logwatch-4.3.1-2 from RHL 9 on RHL 7.2 and 7.3 systems.
Update causes no problem (thanks to Perl...).

Logwatch on a fedora 2 machine:

--------------------- SSHD Begin ------------------------ 

Argument "2001:470:1f80:176:1::feed" isn't numeric in pack at
/etc/log.d//lib/Logwatch.pm line 286, <STDIN> line 1.
Character in 'C' format wrapped in pack at /etc/log.d//lib/Logwatch.pm
line 286, <STDIN> line 1.

Users logging in through sshd:
   zenon:
      unknown.Level3.net (2001:470:1f80:176:1::feed): 1 time

 ---------------------- SSHD End ------------------------- 

Obviously, this bug resurrected. Will you please change the
product/version and re-open it? 

Fedora Core 2 contain version:

# rpm -q logwatch
logwatch-5.1-3

Forgotten: I can confirm that logwatch-5.1-3 has the same problem like
2.6-1

Downgrading to logwatch-4.3.2-2.noarch.rpm of RHEL3U2 will solve this
issue again. Upgrading to logwatch-5.2.2-1.noarch.rpm from
logwatch.org also.
So looks like logwatch-developers have fixed the bug, please provide
new FC packages.

Example of 5.2.2-1:

Failed logins from these:
   root/password from 2001:7b0:1101:****: 1 Time(s)

Users logging in through sshd:
   root:
      unresolved IPv6 addr: 2001:7b0:1101:*****: 2 times

Refused incoming connections:
      ::ffff:210.114.***.*** (::ffff:210.114.***.****): 6 Time(s)


But anyway, there is still a bug in logwatch-5.2.2-1, because 
      unresolved IPv6 addr: 2001:7b0:1101:*****: 2 times
is not proper, it is resolvable...will dig into code now.

Found, Logwatch.pm still doesn't support IPv6 reverse lookup
resolving...probably because delivered Perl currently contain no
module, which supports handling IPv6 addresses (here e.g. expanding
compressed ones).

   if ($Addr =~ /:/ and $Addr !~ /^::ffff:(\d+\.\d+\.\d+\.\d+)/) {
       return "unresolved IPv6 addr: $Addr";
   }
   $Addr =~ s/::ffff://;
   my $PackedAddr = pack('C4', split /\./,$Addr);
   if (my $name = gethostbyaddr ($PackedAddr,2)) {
       my $val = "$name ($Addr)";
       $LookupCache{$Addr} = $val;
       return $val;
   } else {
       $LookupCache{$Addr} = $Addr;
       return ($Addr);
   }

It sounds like the issue now is that logwatch doesn't know how to
resolve IPv6 addresses. There is a perl Socket6 module that provides
access to getaddrinfo(), but for now I don't see that getting pulled
in. Perhaps a future perl release will include it, or perhaps upstream
logwatch will know how to make use of it if it is installed...? I
don't see any actions to take right now, though.

See also
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123088

Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

FC3 contain logwatch-5.2.2-1.FC3.1, so the original bug is gone away.

The other issue "unresolvable IPv6 address" is in conjunction with missing IPv6
support in Perl.

Mho: close this entry.

*** Bug 616828 has been marked as a duplicate of this bug. ***