From owner-freebsd-hackers Mon Mar 11 5: 7:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0FC1037B41A for ; Mon, 11 Mar 2002 05:07:25 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2BCahi29199; Mon, 11 Mar 2002 07:36:51 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 11 Mar 2002 07:36:42 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Rajesh P Jain Cc: freebsd-hackers@FreeBSD.org Subject: Re: BPF - Problem with ioctl calls of BPF In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Mar 2002, Rajesh P Jain wrote: > In the BPF - Berkeley Packet Filter, when a file descriptor is > associated to an interface to send and receive packets, there is an > ioctl parameter "BIOCSSEESENT", which is by default set to 1. Hence the > packets both from "remote systems" and "locally generated" are received. > > If "locally generated" packets needs to be filtered, we can use the > option "BIOCSSEESENT" and set the value to 0. > > After using this ioctl(BIOCSSEESENT) call for one of the ethernet > intrfaces (successfully) and associating the BPF using the BIOCSETIF. > > Now, if we try to assocaite one more BPF to the second interface of > the machine (using the BIOCSETIF), the association of the BPF with that > interface fails. > > Am I missing something ??? Please throw light on this issue. > > Of course, without using the BIOCSSEESENT, I am able to associate 2 > interfaces to separate BPF's. I haven't run into this -- the circumstance under which I used (and first added) BIOCSSEESENT was one in which I bound (n) BPF devices to (n) seperate interfaces, and set BIOCSSEESENT=0 on each. We used such an environment to create a userland bridging tool, and use this to avoid first order cycles. Could you provide a code snippet demonstrating the failure? What failure do you get? Our loop consisted of (logically): foreach interface (interface list) { open bpf instance set bpf capture length set bpf interface get and check bpf data link type set bpf "complete header" flag to true set bpf "see sent" flag to false set bpf "immediate" flag to true set bpf "promiscuous" flag to true set bpf instructions } It appeared to work fine although I haven't tried it on recent -STABLE. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message