Re: Promiscuous mode and BPF filters?

[Guy Harris <guy () alum mit edu>]

On Dec 1, 2004, at 7:53 AM, Claudio Lavecchia wrote:

> I have two laptops (say A and B) that have 802.11 wireless cards. I am 
> developing some application that essentially perform sniffing 
> functions using wireless cards in promiscuous mode. To test my code, I 
> need those two laptops not to "see" each other (--> I do not want the 
> wireless card of laptop A, which is operating in promiscuous mode to 
> process packets coming from laptop B) and I want to test my appliction 
> having my laptops on my desk, hence I need a way to "hide" the two 
> laptops from each others.
> I want to apply some kind of filters to laptops A and B, and I want 
> the filtering to happen BEFORE the packets reach the "promiscuous mode 
> filter".

What do you mean by "the promiscuous mode filter"?  "Promiscuous mode" 
is a hardware mode on LAN adapters (including WLAN adapters), in which 
the adapter doesn't filter out packets that it sees but that are sent 
to a unicast address other than one of the adapter's unicast addresses 
or, on adapters that can be configured with a list of multicast 
addresses, sent to a multicast address other than one of those 
multicast addresses.

That filter is in the hardware or firmware of the adapter, so you're 
not going to be able to do the filtering before that.

> Quickly borwsing the web I found BPF (BSD Packet Filter). Can that be 
> the solution to my problem?

"BPF" is used to refer to two things:

	1) the raw packet capture mechanism on various BSDs (including OS X) 
and AIX;

	2) the packet filtering mechanism used by that raw packet capture 
mechanism *and* in the Linux "socket filter" mechanism and in 
Digital/Tru64 UNIX's raw packet capture mechanism *and* in the WinPcap 
driver *and* in libpcap when reading from a savefile or capturing on a 
platform whose raw packet capture mechanism doesn't support that 
filtering mechanism.

"BPF", in the first sense, won't be the solution to your problem, as 
that's not the raw packet capture mechanism on Linux.  On the platform 
where it *is* the raw packet capture mechanism, it's not really the 
solution, either, it's just a requirement for capturing packets at all.

In the second sense, it's the filter mechanism used by "pcap_compile()" 
and "pcap_setfilter()" in libpcap.  It *could* be the solution *if* 
you're willing to modify your application slightly so that

	if it doesn't use "pcap_compile()" and "pcap_setfilter()", i.e. it 
doesn't do any packet filtering, it temporarily sets a filter, while 
you're testing it, to reject packets from laptop B;

	if it *does* use "pcap_compile()" and "pcap_setfilter()", i.e. it 
already does packet filtering, it *adds* to the filter an expression to 
reject all the traffic from laptop B, i.e. instead of filtering with an 
expression X, you filter with "(not wlan src BB:BB:BB:BB:BB:BB) and 
(X)", where "BB:BB:BB:BB:BB:BB" is the source MAC address of laptop B's 
802.11 card.

It will not be the solution if you expect it to be able to filter out 
packets transparently to libpcap - there's only one filter per packet 
capture "handle", and libpcap uses that for its filtering.  (That also 
applies if you're not using libpcap, but are directly opening a 
PF_PACKET socket - the only difference in that case is that your 
application contains code that duplicates what libpcap does, and that 
code has the same limitations as libpcap, as the limitation of "one 
filter per handle" is an OS limitation.)

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.