bin/110689: tcpdump ipv4 snaplen too short for pflog

Charles Sprickman spork at
Fri Mar 23 01:10:05 UTC 2007

>Number:         110689
>Category:       bin
>Synopsis:       tcpdump ipv4 snaplen too short for pflog
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 23 01:10:04 GMT 2007
>Originator:     Charles Sprickman
>Release:        6.2-Release
spork, LLC
[root at slimjim /usr/src/usr.sbin/tcpdump]# uname -a
FreeBSD 6.2-RELEASE-p1 FreeBSD 6.2-RELEASE-p1 #4: Thu Feb 15 17:53:43 EST 2007     spork at  i386
There is a ifdef in the tcpdump sources (I believe just in /usr/src/contrib/tcpdump/interface.h) that sets the default snaplen for tcpdump.  Running tcpdump without a special snaplen against pflog will drop some data (the last octet of the second ip).

This breaks things like spamlogd (/usr/ports/mail/spamd).

The issue is also raised here in the NetBSD bug db:

Same issue...  
Build a recent spamlogd on FreeBSD, try to run it.  You'll see that the traffic it snarfs from pflog is missing the last octet, which makes it unhappy:

Mar 22 03:03:31 slimjim spamlogd[700]: outbound 216.220.96
Mar 22 03:03:31 slimjim spamlogd[700]: invalid ip address 216.220.96
I rebuilt tcpdump after setting the snaplen to 96 in both cases.  Some would argue that the ifdef is not even really necessary and a snaplen big enough to deal with all our "new" interfaces (pflog, carp, etc.) should be the new default.

This snippet starts at line 87.

 * The default snapshot length.  This value allows most printers to print
 * useful information while keeping the amount of unwanted data down.
#ifndef INET6
#define DEFAULT_SNAPLEN 96      /* ether + IPv4 + TCP + 14 */
#define DEFAULT_SNAPLEN 96      /* ether + IPv6 + TCP + 22 */
#endif                           /*   ^^ I upped this */

More information about the freebsd-bugs mailing list