Date: Sat, 12 Sep 2009 07:50:06 +1000 From: Peter Jeremy <peterjeremy@acm.org> To: freebsd-net@freebsd.org Subject: New tcpdump in 8.x Message-ID: <20090911215006.GA31432@server.vk2pj.dyndns.org>
next in thread | raw e-mail | index | archive | help
--pf9I7BMVVzbSWLtt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
[Please excuse long lines]
Who has used tcpdump on FreeBSD 8.x and likes it? Is it just me or is
it now far harder to investigate network problems using it?
Prior to 8.x, the default output includes SEQ number ranges for any
TCP packets with data, so a 'tcpdump -n' looks like the following and
it's immediately obvious that there's 2920 bytes of data missing:
08:48:32.137596 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 221537:222=
997(1460) ack 2609 win 65535
08:48:32.138492 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 222997:224=
457(1460) ack 2609 win 65535
08:48:32.139601 IP 122.106.250.30.2202 > 134.159.99.234.60834: . ack 224457=
win 64240
08:48:32.145623 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 227377:228=
837(1460) ack 2609 win 65535
08:48:32.146703 IP 122.106.250.30.2202 > 134.159.99.234.60834: . ack 224457=
win 65535
The same output on 8.x looks like the following. Whilst the last ACK
packet looks anomolous, there's no useful information to analyse further.
08:48:32.137596 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], a=
ck 2609, win 65535, length 1460
08:48:32.138492 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], a=
ck 2609, win 65535, length 1460
08:48:32.139601 IP 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], a=
ck 224457, win 64240, length 0
08:48:32.145623 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], a=
ck 2609, win 65535, length 1460
08:48:32.146703 IP 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], a=
ck 224457, win 65535, length 0
In order to see the SEQ numbers (which are essential to make sense of
the capture), you need to add '-vv' - which turns the output into:
08:48:32.137596 IP (tos 0x0, ttl 52, id 32485, offset 0, flags [DF], proto =
TCP (6), length 1500)
134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 221537:22299=
7, ack 2609, win 65535, length 1460
08:48:32.138492 IP (tos 0x0, ttl 52, id 32486, offset 0, flags [DF], proto =
TCP (6), length 1500)
134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 222997:22445=
7, ack 2609, win 65535, length 1460
08:48:32.139601 IP (tos 0x8, ttl 63, id 46554, offset 0, flags [DF], proto =
TCP (6), length 40)
122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], cksum 0xe759 (co=
rrect), seq 2609, ack 224457, win 64240, length 0
08:48:32.145623 IP (tos 0x0, ttl 52, id 32489, offset 0, flags [DF], proto =
TCP (6), length 1500)
134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 227377:22883=
7, ack 2609, win 65535, length 1460
08:48:32.146703 IP (tos 0x8, ttl 63, id 46555, offset 0, flags [DF], proto =
TCP (6), length 40)
122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], cksum 0xe24a (co=
rrect), seq 2609, ack 224457, win 65535, length 0
Whilst it's now possible to work out that there's 2920 bytes of data
missing, this information is mixed up in so much other extraneous
information that the dump is almost useless. In particular, it's no
longer possible to scan a tcpdump output and easily see packet loss or
out-of-order delivery.
--=20
Peter Jeremy
--pf9I7BMVVzbSWLtt
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)
iEYEARECAAYFAkqqxg4ACgkQ/opHv/APuIdAngCeMjWwA66RYx5JVMyUI6DxNT+C
jo0An02IM9wDixakm6pq1grALUx8azAM
=q1Ex
-----END PGP SIGNATURE-----
--pf9I7BMVVzbSWLtt--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090911215006.GA31432>