Re: problem while examinate 802.11-packets

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

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.