From owner-freebsd-net@FreeBSD.ORG Wed Aug 31 19:59:47 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E80C16A41F for ; Wed, 31 Aug 2005 19:59:47 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 119B543D46 for ; Wed, 31 Aug 2005 19:59:46 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Aug 2005 15:59:45 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 5F9F213646; Wed, 31 Aug 2005 15:59:45 -0400 (EDT) Date: Wed, 31 Aug 2005 15:59:45 -0400 From: Ed Maste To: freebsd-net@freebsd.org Message-ID: <20050831195945.GA22805@sandvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 31 Aug 2005 19:59:45.0609 (UTC) FILETIME=[88DE3B90:01C5AE66] Subject: BIOCSSEESENT ioctl not honoured for single-mbuf packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 19:59:47 -0000 A coworker of mine discovered a bug in bpf with BIOCSEESENT. In sys/net/bpf.c, bpf_mtap() does if (pktlen == m->m_len) { bpf_tap(bp, mtod(m, u_char *), pktlen); return; } BPFIF_LOCK(bp); LIST_FOREACH(d, &bp->bif_dlist, bd_next) { if (!d->bd_seesent && (m->m_pkthdr.rcvif == NULL)) continue; [...] The pktlen == m->m_len is an optimization for the case where the entire packet is in a single mbuf, added in version 1.95. However, bd_seesent then isn't checked so all packets will be seen. In order to make bpf_tap work correctly with BIOCSEESENT for both this case and the few drivers that use it, I think it needs another argument to indicate if the packet is being sent or not. Is it possible to change the API for bpf_tap? Or add a bpf_tap2 that includes the flag, and make bpf_tap call it (for any third party drivers using bpf_tap)? -- Ed Maste Sandvine Incorporated