From owner-freebsd-pf@FreeBSD.ORG Thu Feb 28 13:56:53 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C0C11065677 for ; Thu, 28 Feb 2008 13:56:53 +0000 (UTC) (envelope-from flo@kasimir.com) Received: from kasimir.com (kasimir.com [85.214.51.166]) by mx1.freebsd.org (Postfix) with ESMTP id 85C7E8FC1C for ; Thu, 28 Feb 2008 13:56:52 +0000 (UTC) (envelope-from flo@kasimir.com) Received: (qmail 75004 invoked from network); 28 Feb 2008 14:30:10 +0100 Received: from relay3.vistream.de (HELO nibbler.vistream.local) (87.139.10.28) by unescopgu.de with SMTP; 28 Feb 2008 14:30:10 +0100 Message-ID: <47C6B744.2050501@kasimir.com> Date: Thu, 28 Feb 2008 14:29:40 +0100 From: Florian Smeets User-Agent: Thunderbird 2.0.0.13pre (Macintosh/20080227) MIME-Version: 1.0 To: Mike Tancsa References: <200802271155.m1RBt6U0058941@lava.sentex.ca> In-Reply-To: <200802271155.m1RBt6U0058941@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: default snaplen on tcpdump X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 13:56:53 -0000 Mike Tancsa wrote: > Is there any chance of changing the default snap length of tcpdump to be > a few bytes bigger ? With pf on RELENG_7, the default of 96 is too > short now. So doing just a > > # tcpdump -nei pflog0 > tcpdump: WARNING: pflog0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size > 96 bytes > 06:50:57.651128 rule 7/0(match): pass in on bge0: 190.73.138.253.2020 > > xx.7.141.12.25: tcp 28 [bad hdr length 0 - too short, < 20] > > Going to -s100 seems to be a safe value and avoids the "bad header" errors. > Thank you! This just saved me some time i guess. I saw this on a 7.0-RC firewall a few days ago and wondered what that could mean. I didn't have time to investigate yet and just now read your mail :-) I think others could also be confused by this, so i think increasing the snap length would make sense. Cheers, Florian