Christian,
what happens, if you listen on the interface using tcpdump?
do you get 802.11 frames or do you get ethernet frames?
i.e. is RFMON on?
-alexm
08:47 15/02/2008
On Fri, 15 Feb 2008, Christian Stalp wrote:
> In the mean time I found some hint.
> I did not told you that my program is multithreaded, because I thought it
> doesn't matter. Accidentally I was stumble over the function "ether_ntoa_r".
>
> So I changed my capture-function (which is called by a thread!) to this:
>
> void packet_default(u_char *args, const struct pcap_pkthdr *header, const
> u_char *packet)
> {
> char insertvalues[256];
> char insertbuffer[256];
> memset (insertvalues, 0x0, 256 );
> memset (insertbuffer, 0x0, 256 );
>
> struct ether_header *ethprt;
>
> ethprt = (struct ether_header *) packet;
> snprintf(insertvalues,255, "default-s: %s",ether_ntoa_r((struct
> ether_addr*) (ethprt->ether_shost), insertbuffer ));
> printf("%s\n", insertvalues);
> }
>
> But the result is the same. Its still the first four fields of my MAC-address
> but the final two are still trash.
>
> Gruss Christian
>
>
>
> -------- Original-Nachricht --------
> > Datum: Thu, 14 Feb 2008 10:51:25 -0800
> > Von: Guy Harris <[EMAIL PROTECTED]>
> > An: [email protected]
> > Betreff: Re: [tcpdump-workers] problem while examinate 802.11-packets
>
> > Christian Stalp wrote:
> >
> > > And now the first weired thing: if I check my interface for ethernet
> > > it passes, if I check for wlan it fails!
> >
> > I infer from the name "ath0" that this is *BSD.
> >
> > If so, then all 802.11 devices default to providing Ethernet headers,
> > for compatibility with applications that don't know about 802.11. You
> > have to explicitly ask it for 802.11 headers; use pcap_list_datalinks()
> > to get a list of all the link-layer types the device supports and, if
> > that list includes DLT_IEEE80211, use pcap_set_datalink() to set the
> > link-layer type to that value.
> >
> > > wptr = (struct ieee_802_11_header *) packet;
> >
> > That won't work unless you set the link-layer type to DLT_IEEE80211.
> >
> > Note also that, on at least some Atheros devices, there's an additional
> > problem - if you ask them to supply 802.11 headers, they stick in some
> > extra padding between the 802.11 header and the frame body. To handle
> > that, you need to request the radiotap header, if available -
> > DLT_IEEE80211_RADIO - and parse the radiotap header to see if the
> > padding is included.
> >
> > > I also tried this with casting to ethernet-frames but came out with
> > > the same result.
> >
> > I.e., you cast the packet pointer to a pointer to a structure such as
> >
> > struct ether_header {
> > __u8 dst[6];
> > __u8 src[6];
> > _u16 type_len;
> > };
> >
> > and "dst" and "src" aren't correct MAC addreses?
> > -
> > This is the tcpdump-workers list.
> > Visit https://cod.sandelman.ca/ to unsubscribe.
>
> --
> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
> Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
