Description of problem:
I posted a patch (Bug 174954) for /usr/share/logwatch/scripts/services/iptables
with a small bug in December last year.  The bug occurs when an icmp packet is
an error response that includes an offending tcp or udp packet.  In that case
netfilter logs both the icmp type and the destination port.  The current
iptables script preferentially extracts the dest port, but should preferentially
extract the icmp type.

Version-Release number of selected component (if applicable):
logwatch-7.2.1-1.fc5
I checked upstream, and the bug still exists in logwatch-7.3, so fc6test is
probably affected, too.  (Sorry, I haven't been testing fc6.)

How reproducible:
Always

Steps to Reproduce:
1. log icmp packets with included tcp or udp packets (example below)
2. run logwatch
  
Actual results: (example)
   From 68.142.193.5 - 1 packet to icmp(33499)

Expected results: (example)
   From 68.142.193.5 - 1 packet to icmp(11)

Additional info:
The above examples are derived from an example syslog entry as follows.

kernel: iptables ACCEPT: IN=ppp0 OUT=eth0 SRC=68.142.193.5 DST=192.168.1.9
LEN=56 TOS=0x00 PREC=0xC0 TTL=240 ID=44656 PROTO=ICMP TYPE=11 CODE=0
[SRC=192.168.1.9 DST=209.191.93.52 LEN=38 TOS=0x00 PREC=0x00 TTL=1 ID=37595
PROTO=UDP SPT=32768 DPT=33499 LEN=18 ]

The included patch corrects the bug.  Port numbers for actual tcp and udp
packets have no type, so their reporting is not affected.

I submitted the same patch to logwatch-patches, so it may come
downstream eventually.