Date: Mon, 11 Mar 2002 07:36:42 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Rajesh P Jain <rpjain_1977@eudoramail.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: BPF - Problem with ioctl calls of BPF Message-ID: <Pine.NEB.3.96L.1020311073059.3929A-100000@fledge.watson.org> In-Reply-To: <DPLLFKLDGHMKDAAA@shared1-mail.whowhere.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020311073059.3929A-100000>