On Wed, Oct 24, 2012 at 10:44:25AM -0700, Jeremy Chadwick wrote:
> On Wed, Oct 24, 2012 at 07:00:55PM +0200, Harald Schmalzbauer wrote:
> > schrieb Jeremy Chadwick am 24.10.2012 18:51 (localtime):
> > > ...
> > > # 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
> > Have you ever seen "e0:cb:4e:c0:00:c4" and "00:30:48:d2:22:d0" ?
> > These are your mac addresses, which -xx shows.
> >
> > ...
> > > 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
> >
> > Of course, I saw that. That's why I claim the 2nd outgoing request to be
> > malformed ;-)
> >
> > > ...
> > >
> > > 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).
> >
> > -x gives everything above link-layer, so IP and ICMP are in my last dump.
>
> You're right -- sorry, *I* misread the tcpdump man page! :-) Here I am
> telling you what to do yet...... *laugh* Sorry about that.
>
> So I can tell from your original output that you're using "-x" by
> itself, so what we're seeing should be the IP header and related bits.
>
> Okay, so let's decode what you got. Too bad we don't have snoop-like
> output, since it can decode all of this and output it in a
> human-friendly way. Gotta do this by hand...
>
>
> 12:21:09.048447 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 46597, seq
> 0, length 4076
> 0x0000: 4500 1000 0f2d 4000 4001 a507 0a05 317e
>
> 0x45 = bits 7-4: IPv4 protocol
> = bits 3-0: header length: 20 bytes
> 0x00 = DSF / RFC 2474 stuff (don't ask me :-) )
> 0x1000 = datagram length: 4096 bytes
> 0x0f2d = fragment id
> 0x4000 = bits 15-13: %010 = reserved bit (0), DF bit (1), MF bit (0)
> = bits 12-0: fragment offset: 0
> 0x40 = TTL: 64
> 0x01 = protocol: 1 (ICMP)
> 0xe4c7 = header checksum
> 0x0a05317e = source IP
>
> Now for the malformed/wonky packet:
>
> 12:21:10.052891 IP 10.5.49.126 > 10.5.49.65: icmp
> 0x0000: 4500 1000 0f2d 0040 4001 e4c7 0a05 317e
>
> 0x45 = bits 7-4: IPv4 protocol
> = bits 3-0: header length: 20 bytes
> 0x00 = DSF / RFC 2474 stuff (don't ask me :-) )
> 0x1000 = datagram length: 4096 bytes
> 0x0f2d = fragment id
> 0x0040 = bits 15-13: %000 = reserved bit (0), DF bit (0), MF bit (0)
> = bits 12-0: fragment offset: 64
> 0x40 = TTL: 64
> 0x01 = protocol: 1 (ICMP)
> 0xe4c7 = header checksum
> 0x0a05317e = source IP
>
> So from this we can tell that the working packets have the DF
> (dont-fragment) bit set and have a fragment offset of zero, and the
> "broken" packet has the DF bit cleared and a fragment offset of 64.
>
> Can you please re-run your tests with the following tcpdump arguments
> and provide full, non-edited output?
>
> Even WITHOUT "-s 0" to tcpdump you should be getting back multiple
> lines (0x0000, 0x0010, 0x0020, etc.), yet you've omitted the information
> I need to see.
And an accidental vi/vim mistake on my part deleted the paragraph
specifying the arguments. Doh!
tcpdump -p -i {iface} -l -n -s 0 -x "{filter string}"
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
