From owner-freebsd-hackers  Mon Oct 11  2: 5:36 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [196.37.91.10])
	by hub.freebsd.org (Postfix) with ESMTP id DD81714D32
	for <freebsd-hackers@freebsd.org>; Mon, 11 Oct 1999 02:04:59 -0700 (PDT)
	(envelope-from rbezuide@oskar.nanoteq.co.za)
Received: (from rbezuide@localhost)
	by oskar.nanoteq.co.za (8.9.0/8.9.0) id LAA26466
	for freebsd-hackers@freebsd.org; Mon, 11 Oct 1999 11:08:08 +0200 (SAT)
From: Reinier Bezuidenhout <rbezuide@oskar.nanoteq.co.za>
Message-Id: <199910110908.LAA26466@oskar.nanoteq.co.za>
Subject: More libpcap problems
To: freebsd-hackers@freebsd.org
Date: Mon, 11 Oct 1999 11:08:08 +0200 (SAT)
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi ...

I have an application which uses libpcap ... after running for several
weeks normally .. the application coredumps .. I've traced the problem
back to libpcap which somehow reads garbage packet information (or is
given garbage). Here is a short view of the gdb ..

(gdb) p *(struct bpf_hdr *)pkt
$2 = {bh_tstamp = {tv_sec = 0, tv_usec = 0}, bh_caplen = 0, 
  bh_datalen = 4294922246, bh_hdrlen = 24577}
(gdb) p *pkt
$3 = {ts = {tv_sec = 0, tv_usec = 0}, caplen = 0, len = 4294922246}
(gdb)   

Take a look at the bh_datalen and bh_hdrlen ... those values are
not ok.  The only value which makes sense is the bh_caplen.  Should
I use that to determine if I should try and examine the packet ???

I've already had to make a change to libpcap where it got stuck
in and endless loop after receiving such "bad" data. (It has been
submitted in a PR)

Thanks
Reinier


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message