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.
