Bug 123088 - logwatch does not understand IPv6 addresses
logwatch does not understand IPv6 addresses
Product: Fedora
Classification: Fedora
Component: logwatch (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Ivana Varekova
: 160136 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-05-12 04:04 EDT by Per Steinar Iversen
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-24 07:04:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Per Steinar Iversen 2004-05-12 04:04:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116

Description of problem:
Found in the report from logwatch:

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

Argument "2001:700:700:1:202:b3ff:fe4c:e30" 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:
      unknown.Level3.net (2001:700:700:1:202:b3ff:fe4c:e30): 1 time

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

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Login by SSH over IPv6
2. Get strange report in the mail next morning

Actual Results:  Logwatch does not understand IPv6 addresses.
The PTR records are not properly looked up either, on the same machine
"host" reports:

# host 2001:700:700:1:202:b3ff:fe4c:e30
domain name pointer nei.p52.hio.no.

Expected Results:  No error message, the PTR record should have been

Additional info:
Comment 1 Peter Bieringer 2004-06-11 08:12:35 EDT
Problematic code:

   $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);

BTW: I found still no fix in logwatch's CVS.
Comment 2 Peter Bieringer 2004-06-11 08:33:29 EDT
Looks like for proper and easy handling "Socket6" module is necessary
in core Perl package, but in FC2 still not included:

Comment 3 Robert Scheck 2004-08-23 12:59:11 EDT
Is it necessary? Maybe an update of Net::DNS to the latest one also 
could solve this problem, because Net::DNS >= 0.46 supports IPv6 
reverse lookups with Net::DNS::Resolver::search() and with query().

I'm no perl expert, but I read that in the changelog and remembered
to that bug report.
Comment 4 Zenon Panoussis 2005-03-25 06:49:15 EST
BTW, RHEL3 U4 still generates messages like this:

--------------------- Kernel Begin ------------------------ 

Dropped 1118 packets on interface eth0
   From - 1 packet
      To 81.x.y.z - 1 packet
         Service: 32768 (udp/32768) (DROP,eth0,none) - 1 packet
Dropped 4 packets on interface sit1
   From 2001 - 4 packets
      To 2001 - 4 packets
         Service: 135 (tcp/135) (DROP,sit1,none) - 1 packet
         Service: ldap (tcp/389) (DROP,sit1,none) - 3 packets

---------------------- Kernel End ------------------------- 

Logwatch can't parse ipv6 addresses there either, although it doesn't have to do
reverse lookups on them, just copy them. 
Comment 5 Ivana Varekova 2005-06-28 10:10:03 EDT
*** Bug 160136 has been marked as a duplicate of this bug. ***
Comment 6 Ivana Varekova 2005-10-24 07:04:59 EDT
This bug is fixed in the last version of logwatch (logwatch-7.0-1).

Note You need to log in before you can comment on or make changes to this bug.