Bug 736009

+++ This bug was initially created as a clone of Bug #723108 +++

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:

--- Additional comment from pm-rhel on 2011-07-19 02:22:48 EDT ---

Since this issue was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from pm-rhel on 2011-07-19 02:37:57 EDT ---

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.

--- Additional comment from msekleta on 2011-08-29 04:41:53 EDT ---

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

--- Additional comment from haliu on 2011-08-29 21:28:19 EDT ---

(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.

--- Additional comment from msekleta on 2011-08-31 04:20:59 EDT ---

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

--- Additional comment from msekleta on 2011-08-31 10:52:18 EDT ---

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

--- Additional comment from msekleta on 2011-09-02 10:11:21 EDT ---

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.

--- Additional comment from msekleta on 2011-09-06 06:28:22 EDT ---

Problem is in not in tcpdump but in libpcap, thus switching component to libpcap.

--- Additional comment from msekleta on 2011-09-06 06:34:07 EDT ---

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.