Bug 123088
| Summary: | logwatch does not understand IPv6 addresses | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Per Steinar Iversen <persteinar.iversen> |
| Component: | logwatch | Assignee: | Ivana Varekova <varekova> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | dwmw2, pb |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-10-24 11:04:59 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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.
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 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. 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.
*** Bug 160136 has been marked as a duplicate of this bug. *** This bug is fixed in the last version of logwatch (logwatch-7.0-1). |
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: