tcpdump mailing list archives

Re: Better dumping of packets with bad TCP checksums?


From: Guy Harris <guy () alum mit edu>
Date: Fri, 30 Jul 2004 12:12:50 -0700


On Jul 30, 2004, at 10:14 AM, Greg Weiss wrote:

Is there a way to command-line filter tcpdump so that only packets with
bad TCP checksums are dumped?

No.

The BPF filtering mechanism can't handle it, as there's no way for it to compute a checksum, and the filtering mechanism is BPF-based.

A separate mechanism could probably be added in tcpdump - note that it won't work if you use a snapshot length shorter than the full length of the packet (because the checksum can't be computed unless you have all the data) or if the TCP segment is fragmented at the IP layer, and it wouldn't do anything useful for packets sent by the machine running tcpdump (and, in fact, might have to forego checking those packets if the interface on which they're being sent does TCP checksum offloading).

In order to support a short snapshot length, there'd have to be OS kernel changes to do the check in the kernel *and* supply the results of the check to libpcap (e.g. a BPF instruction to do a checksum check), or, if checksum checking were done, the snapshot length used when getting packets from the kernel would have to be something large enough to get the entire packet, and the packet would have to be cut off in userland.

Is there a particular tool/approach
anyone would recommend for flagging/logging the existence of
incoming corrupted TCP/IP packets?

An intrusion detection system, if sufficiently user-configurable, might support that. (It'd have to look at all the incoming TCP packets to do that.)

P.S. Sentence 2 in the man page should refer to the -r flag, not the -b
flag, right?

In tcpdump 3.7.2 and later, it *does* refer to the "-r" flag; it referred to "-b" in 3.7.1, but 3.7.2 fixes a problem in the ISAKMP parser for which there's a security advisory. The current version is 3.8.3; hopefully no current version of any OS is shipping 3.7.1.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


Current thread: