Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Oct 2012 09:51:48 -0700
From:      Jeremy Chadwick <jdc@koitsu.org>
To:        Harald Schmalzbauer <h.schmalzbauer@omnilan.de>
Cc:        adrian@freebsd.org, freebsd-stable@freebsd.org
Subject:   Re: every 2nd echo-request malformed when ping -s >4067
Message-ID:  <20121024165148.GA4250@icarus.home.lan>
In-Reply-To: <5088163E.2090506@omnilan.de>
References:  <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 24, 2012 at 06:24:30PM +0200, Harald Schmalzbauer wrote:
>  schrieb Jeremy Chadwick am 24.10.2012 17:40 (localtime):
> > (Please keep me CC'd as I'm not subscribed)
> >
> > Regarding:
> >
> > http://lists.freebsd.org/pipermail/freebsd-stable/2012-October/070239.html
> >
> > tcpdump -x is not helpful here.  tcpdump -xx would be.
> >
> > tcpdump -x dumps the *payload* portion of the packet, while -xx dumps
> > everything (all headers/protocol data included).
> >
> > The reason I say -xx would be helpful is because of this:
> >
> >> 2nd: 12:21:10.052891 IP 10.5.49.126 > 10.5.49.65: icmp
> >>         0x0000:  4500 1000 0f2d 0040 4001 e4c7 0a05 317e
> > The ICMP code/type and related header data is not being decoded
> > correctly, or is being *encoded* incorrectly.  I can't tell because all
> > that's shown there is the payload! 
> 
> Hmm, if I understand things right, there's only the link-level-header
> missing, meaning the ethernet adresses. Not the IP-header.
> Verified that:
> 
>  1st: 16:03:08.963292 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id
> 30477, seq 0, length 4076
>         000c 29f1 8424 90e2 ba18 f885 0800
> 
> 2nd: 16:03:09.968454 IP 10.5.49.126 > 10.5.49.65: icmp
>         000c 29f1 8424 90e2 ba18 f885 0800
> 
> Since the link-level-header is identical, the problem must be later and
> the former dump should be valid.
> That's easily reproducable everywhere, since lo0 has mtu 16384, so just
> ' ping -D -s 4068 127.0.0.1 '.

I'm a little confused by your statement.

What concerns me is that tcpdump isn't able to decode the ICMP type,
ID number, sequence number, or length of the 2nd packet in your example.
Those fields are kept within the ICMP header itself, not the ICMP
payload.

What you should be seeing is this (using 4.2.2.1 as a test host):

# tcpdump -p -i em0 -l -n -s 0 -xx "icmp and dst host 4.2.2.1"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:45:22.725137 IP 192.168.1.51 > 4.2.2.1: ICMP echo request, id 6417, seq 0, length 64
        0x0000:  e0cb 4ec0 00c4 0030 48d2 22d0 0800 4500
        0x0010:  0054 2f29 0000 4001 83a2 c0a8 0133 0402
        0x0020:  0201 0800 77b0 1911 0000 5088 1b22 000b
        0x0030:  1086 0809 0a0b 0c0d 0e0f 1011 1213 1415
        0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
        0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
        0x0060:  3637
09:45:23.726143 IP 192.168.1.51 > 4.2.2.1: ICMP echo request, id 6417, seq 1, length 64
        0x0000:  e0cb 4ec0 00c4 0030 48d2 22d0 0800 4500
        0x0010:  0054 2f37 0000 4001 8394 c0a8 0133 0402
        0x0020:  0201 0800 73be 1911 0001 5088 1b23 000b
        0x0030:  1476 0809 0a0b 0c0d 0e0f 1011 1213 1415
        0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
        0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
        0x0060:  3637

Note that in both cases (both outbound ICMP ECHO packets), tcpdump is
able to decode the type (type 8), id number, sequence number, length,
etc..  Said differently, look at this:

09:45:22.725137 IP 192.168.1.51 > 4.2.2.1: ICMP echo request, id 6417, seq 0, length 64
09:45:23.726143 IP 192.168.1.51 > 4.2.2.1: ICMP echo request, id 6417, seq 1, length 64

And compare this to what you're seeing (look closely at the 2nd line):

16:03:08.963292 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 30477, seq 0, length 4076
16:03:09.968454 IP 10.5.49.126 > 10.5.49.65: icmp

And that is what worries me -- it's like the actual packet contents
(specifically the ICMP header portions) of the 2nd packet are getting
mangled, thus tcpdump doesn't know the ICMP type, etc...

This is why I said I want to see output from -xx and not -x.  What I
want to see is the *full packet contents* (IP header, ICMP header, and
any ICMP payload).  Please use the tcpdump command I showed above,
with -i adjusted for your interface and/or a different destination IP,
then use "ping -c 2 {destination IP}".  Please don't edit the output
in any way.

Thanks.

-- 
| Jeremy Chadwick                                   jdc@koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121024165148.GA4250>