[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:222997(1460) ack 2609 win 65535 08:48:32.138492 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 222997:224457(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:228837(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 [.], ack 2609, win 65535, length 1460 08:48:32.138492 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], ack 2609, win 65535, length 1460 08:48:32.139601 IP 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], ack 224457, win 64240, length 0 08:48:32.145623 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], ack 2609, win 65535, length 1460 08:48:32.146703 IP 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], ack 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:222997, 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:224457, 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 (correct), 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:228837, 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 (correct), 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. -- Peter Jeremy
pgpnKFDXzBzl1.pgp
Description: PGP signature