Bug 723108

Summary: tcpdump icmp6 option can't catch icmpv6 package larger than 1460
Product: Red Hat Enterprise Linux 6 Reporter: Hangbin Liu <haliu>
Component: libpcapAssignee: Michal Sekletar <msekleta>
Status: CLOSED ERRATA QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2CC: azelinka, harald, mmalik, msekleta, rhack, wnefal+redhatbugzilla
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: libpcap generates wrong filtering code for Berkeley Packet Filter infrastructure, thus in-kernel packet filter will discard some packets which should be received be userspace process Consequence: tcpdump produces incorrect output when there is a fragmentation of IPv6 packet occurs because of link MTU Fix: Fix code which deals with BPF filter generation in way that we check for fragmentation headers in IPv6 PDUs before checking for final protocol. Result: kernel filter is not discarding IPv6 fragments when source-site fragmentation occurs during IPv6 transmission, thus tcpdump and friends (wireshark, etc...) are getting all packets.
 Story Points: ---
Clone Of:
: 736009 (view as bug list) Environment:
Last Closed: 2013-11-21 23:54:41 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:
Attachments:
Description Flags
IPv6 fragmentation patch none

Description Hangbin Liu 2011-07-19 06:07:05 UTC 
Description of problem:

When use tcpdump icmp6 option, It can't catch icmpv6 package larger than 1460, but tcpdump without this option can catch the package. It seem tcpdump catch the icmpv6 package just based on next-header.

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


How reproducible:


Steps to Reproduce:
1.# tcpdump icmp6 -i eth1 -vvv
2.# ping6 fe80::62eb:69ff:fed2:a6c3 -I eth1 -c 2 -s 1452
3.# ping6 fe80::62eb:69ff:fed2:a6c3 -I eth1 -c 2 -s 1453
4.# ping6 fe80::62eb:69ff:fed2:a6c3 -I eth1 -c 2 -s 1452
  
Actual results:

# tcpdump icmp6 -i eth1 -vvv
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
05:11:52.981322 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1460) fe80::e61f:13ff:fee6:947a > fe80::62eb:69ff:fed2:a6c3: ICMP6, echo request, length 1460, seq 1
05:11:53.149359 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1460) fe80::62eb:69ff:fed2:a6c3 > fe80::e61f:13ff:fee6:947a: ICMP6, echo reply, length 1460, seq 1
05:11:53.981256 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1460) fe80::e61f:13ff:fee6:947a > fe80::62eb:69ff:fed2:a6c3: ICMP6, echo request, length 1460, seq 2
05:11:53.981271 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1460) fe80::62eb:69ff:fed2:a6c3 > fe80::e61f:13ff:fee6:947a: ICMP6, echo reply, length 1460, seq 2
05:11:58.197245 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1460) fe80::e61f:13ff:fee6:947a > fe80::62eb:69ff:fed2:a6c3: ICMP6, echo request, length 1460, seq 1
05:11:58.197257 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1460) fe80::62eb:69ff:fed2:a6c3 > fe80::e61f:13ff:fee6:947a: ICMP6, echo reply, length 1460, seq 1
05:11:59.197095 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1460) fe80::e61f:13ff:fee6:947a > fe80::62eb:69ff:fed2:a6c3: ICMP6, echo request, length 1460, seq 2
05:11:59.197107 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1460) fe80::62eb:69ff:fed2:a6c3 > fe80::e61f:13ff:fee6:947a: ICMP6, echo reply, length 1460, seq 2

# tcpdump -i eth1 -vvv
05:06:44.550124 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1460) fe80::e61f:13ff:fee6:947a > fe80::62eb:69ff:fed2:a6c3: ICMP6, echo request, length 1460, seq 1
05:06:44.550135 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1460) fe80::62eb:69ff:fed2:a6c3 > fe80::e61f:13ff:fee6:947a: ICMP6, echo reply, length 1460, seq 1 
05:06:45.550535 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1460) fe80::e61f:13ff:fee6:947a > fe80::62eb:69ff:fed2:a6c3: ICMP6, echo request, length 1460, seq 2
05:06:45.550549 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1460) fe80::62eb:69ff:fed2:a6c3 > fe80::e61f:13ff:fee6:947a: ICMP6, echo reply, length 1460, seq 2
05:06:47.173196 IP6 (hlim 64, next-header: Fragment (44), length: 1456) fe80::e61f:13ff:fee6:947a > fe80::62eb:69ff:fed2:a6c3: frag (0x00000015:0|1448) ICMP6, echo request, length 1448, seq 1
05:06:47.173205 IP6 (hlim 64, next-header: Fragment (44), length: 21) fe80::e61f:13ff:fee6:947a > fe80::62eb:69ff:fed2:a6c3: frag (0x00000015:1448|13)
05:06:47.173219 IP6 (hlim 64, next-header: Fragment (44), length: 1456) fe80::62eb:69ff:fed2:a6c3 > fe80::e61f:13ff:fee6:947a: frag (0x0000005a:0|1448) ICMP6, echo reply, length 1448, seq 1
05:06:47.173221 IP6 (hlim 64, next-header: Fragment (44), length: 21) fe80::62eb:69ff:fed2:a6c3 > fe80::e61f:13ff:fee6:947a: frag (0x0000005a:1448|13)
05:06:48.173096 IP6 (hlim 64, next-header: Fragment (44), length: 1456) fe80::e61f:13ff:fee6:947a > fe80::62eb:69ff:fed2:a6c3: frag (0x00000016:0|1448) ICMP6, echo request, length 1448, seq 2
05:06:48.173103 IP6 (hlim 64, next-header: Fragment (44), length: 21) fe80::e61f:13ff:fee6:947a > fe80::62eb:69ff:fed2:a6c3: frag (0x00000016:1448|13)
05:06:48.173114 IP6 (hlim 64, next-header: Fragment (44), length: 1456) fe80::62eb:69ff:fed2:a6c3 > fe80::e61f:13ff:fee6:947a: frag (0x0000005b:0|1448) ICMP6, echo reply, length 1448, seq 2
05:06:48.173115 IP6 (hlim 64, next-header: Fragment (44), length: 21) fe80::62eb:69ff:fed2:a6c3 > fe80::e61f:13ff:fee6:947a: frag (0x0000005b:1448|13)

Expected results:

tcpdump icmp6 should catch all icmpv6 packages

Additional info:
Comment 2 RHEL Program Management 2011-07-19 06:37:57 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 3 Michal Sekletar 2011-08-29 08:41:53 UTC 
Hi,

I could not verify that this is actual bug in tcpdump. I've build tcpdump from RHEL-6 and linked against libpcap also from RHEL-6.

Version :
libpcap-1.0.0
tcpdump-4.1-PRE-CVS

I've tested tcpdump on my local machine under Fedora 15. I believe this can't be a problem while pcap and tcpdump are in the same version as in RHEL-6.

Description of test case:
$ sudo ./tcpdump icmp6 -i lo -vvv

$ ping6 ::1 -c 2 -s 1452
$ ping6 ::1 -c 2 -s 1453
$ ping6 ::1 -c 2 -s 1452

Test results (tcpdump output):
10:12:43.643750 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1460) localhost > localhost: [icmp6 sum ok] ICMP6, echo request, length 1460, seq 1
10:12:43.643771 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1460) localhost > localhost: [icmp6 sum ok] ICMP6, echo reply, length 1460, seq 1
10:12:44.644363 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1460) localhost > localhost: [icmp6 sum ok] ICMP6, echo request, length 1460, seq 2
10:12:44.644403 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1460) localhost > localhost: [icmp6 sum ok] ICMP6, echo reply, length 1460, seq 2
10:12:50.870621 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1461) localhost > localhost: [icmp6 sum ok] ICMP6, echo request, length 1461, seq 1
10:12:50.870664 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1461) localhost > localhost: [icmp6 sum ok] ICMP6, echo reply, length 1461, seq 1
10:12:51.870381 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1461) localhost > localhost: [icmp6 sum ok] ICMP6, echo request, length 1461, seq 2
10:12:51.870418 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1461) localhost > localhost: [icmp6 sum ok] ICMP6, echo reply, length 1461, seq 2
10:14:08.582439 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1460) localhost > localhost: [icmp6 sum ok] ICMP6, echo request, length 1460, seq 1
10:14:08.582482 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1460) localhost > localhost: [icmp6 sum ok] ICMP6, echo reply, length 1460, seq 1
10:14:09.582366 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1460) localhost > localhost: [icmp6 sum ok] ICMP6, echo request, length 1460, seq 2
10:14:09.582403 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1460) localhost > localhost: [icmp6 sum ok] ICMP6, echo reply, length 1460, seq 2

Output from tcpdump looks correct. I believe that cause of this issue is different packet processing within kernel if working with loopback interface. I'm not trying to say that there's no problem here but I don't blame tcpdump. Please fill free to further discuss this issue, comments and suggestions are very appreciated.

Michal Sekletar
Comment 4 Hangbin Liu 2011-08-30 01:28:19 UTC 
(In reply to comment #3)
> Hi,
> 
> I could not verify that this is actual bug in tcpdump. I've build tcpdump from
> RHEL-6 and linked against libpcap also from RHEL-6.
> 
> Version :
> libpcap-1.0.0
> tcpdump-4.1-PRE-CVS
> 
> I've tested tcpdump on my local machine under Fedora 15. I believe this can't
> be a problem while pcap and tcpdump are in the same version as in RHEL-6.
>
> Output from tcpdump looks correct. I believe that cause of this issue is
> different packet processing within kernel if working with loopback interface.
> I'm not trying to say that there's no problem here but I don't blame tcpdump.
> Please fill free to further discuss this issue, comments and suggestions are
> very appreciated.
> 
> Michal Sekletar

lo's mtu is larger than 1500 usually. change the mtu to 1500 and do the same steps you will find the issue. tcpdump can't recognise icmpv6 packet with icmp6 option when then packet was Fragmented.
Comment 5 Michal Sekletar 2011-08-31 08:20:59 UTC 
Hi, 

so I've reproduced the issue by lowering MTU on loopback in order to achieve  fragmentation. When fragmentation happens there are no packets copied by kernel to tcpdump's read buffer. Backtrace from gdb session indicates that program is blocking in function called from pcap_read_linux_mmap(). From my point of view there are only three possible explanations for this behaviour:

1. there is bug in the Berkeley Packet Filter(BPF) implementation in kernel, which
prevents kernel to recognize fragmented packets and packet filter is discarding 
them

2. there is bug in filter compilation process (libpcap) and code for BPF is wrongly generated so filter can't recognize fragmented icmpv6 packets

3. this is known issue for BPF

I was unable to prove any of these hypothesis so far. Please consider this message as a brief update on the issue, any further discussion is very appreciated.

Michal Sekletar
Comment 6 Michal Sekletar 2011-08-31 14:52:18 UTC 
Hello,

possible solution was proposed to upstream. For further information please follow the upstream issue tracker.

http://sourceforge.net/tracker/?func=detail&aid=3401638&group_id=53067&atid=469579
Comment 7 Michal Sekletar 2011-09-02 14:11:21 UTC 
Proposed patch has been modified by upstream maintainer to handle fragmentation for all protocols not just for icmp6, which is great. Patch has been checked in to upstream git repository and it seems to be working.
Comment 8 Michal Sekletar 2011-09-06 10:28:22 UTC 
Problem is in not in tcpdump but in libpcap, thus switching component to libpcap.
Comment 9 Michal Sekletar 2011-09-06 10:34:07 UTC 
Created attachment 521623 [details]
IPv6 fragmentation patch

Patch changes code generation for kernel packet filter so kernel does not filter out fragmented ipv6 packets and they can be captured by libpcap and processed by tcpdump.
Comment 11 Suzanne Logcher 2012-02-14 23:11:10 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 12 RHEL Program Management 2012-09-07 05:03:51 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 13 Michal Sekletar 2013-08-28 14:54:11 UTC 
libpcap will be rebased in rhel-6.5 and this bug should be solved because of that.

http://bulk-mail.corp.redhat.com/archives/cvs-commits-list/2013-August/msg09611.html
Comment 16 errata-xmlrpc 2013-11-21 23:54:41 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1727.html