Bug 123088 - logwatch does not understand IPv6 addresses
Summary: logwatch does not understand IPv6 addresses
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: logwatch
Version: rawhide
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Ivana Varekova
QA Contact:
URL:
Whiteboard:
: 160136 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-05-12 08:04 UTC by Per Steinar Iversen
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-10-24 11:04:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Per Steinar Iversen 2004-05-12 08:04:01 UTC
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:
   root:
      unknown.Level3.net (2001:700:700:1:202:b3ff:fe4c:e30): 1 time

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


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

How reproducible:
Always

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

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
0.3.e.0.c.4.e.f.f.f.3.b.2.0.2.0.1.0.0.0.0.0.7.0.0.0.7.0.1.0.0.2.ip6.arpa
domain name pointer nei.p52.hio.no.


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

Additional info:

Comment 1 Peter Bieringer 2004-06-11 12:12:35 UTC
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 12:33:29 UTC
Looks like for proper and easy handling "Socket6" module is necessary
in core Perl package, but in FC2 still not included:

http://search.cpan.org/~umemoto/Socket6-0.17/Socket6.pm

Comment 3 Robert Scheck 2004-08-23 16:59:11 UTC
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 11:49:15 UTC
BTW, RHEL3 U4 still generates messages like this:

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

Dropped 1118 packets on interface eth0
   From 15.211.128.7 - 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 14:10:03 UTC
*** Bug 160136 has been marked as a duplicate of this bug. ***

Comment 6 Ivana Varekova 2005-10-24 11:04:59 UTC
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.