On Feb 15, 2008, at 2:15 AM, Christian Stalp wrote:
I changed my capture-routine this way:
void packet_default(u_char *args, const struct pcap_pkthdr *header,
const u_char *packet)
{
char insertvalues[256];
memset (insertvalues, 0x0, 256 );
//struct ieee_802_11_header *wptr; //net/802_11.h
struct ether_header *ethprt;
Note that this means that your filter expression "wlan[0:2] & 0xF1 !=
0" will be checking the first two octets of the destination MAC
address, as that's what the first two octets of the link-layer header
are. (Yes, you said "wlan", but "wlan" is just another name for
"link" in that case, just as "ether" is, and "link[0:2]" - and thus
"ether[0:2]", "wlan[0:2]", "fddi[0:2]", etc. - refers to the first two
octets of the link-layer header, regardless of whether it's an
Ethernet header or an 802.11 header or an FDDI header or a ppp header
or....)
There is no way to check the frame control field of incoming packets
unless the incoming packets have 802.11 headers rather than Ethernet
headers...
A yes, I want to note, that I use Linux not BSD.
...and with most Linux 802.11 drivers the *ONLY* way to get 802.11
headers, as far as I know, is to capture in monitor mode. (The
Atheros driver you're using might be different - it's already
different in that
1) it doesn't call the device "eth0", it calls it "ath0"
and
2) it appears to advertise a *second* device, the "wifi0" device, for
capturing in monitor mode.)
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
