Re: Strange wireless frames

[Guy Harris <gharris () sonic net>]

On Sat, Jun 14, 2003 at 11:46:47AM -0400, Greg Stark wrote:
> I'm running tcpdump on a wlan0 interface using the hostap drivers. I'm seeing
> some strange looking packets. They look to me like four-address inter-AP
> packets but I'm not really sure what they should look like or how tcpdump
> is supposed to display these. I've never done anything with wireless before.
>
> The reason I say they look like four-address inter-AP packets is because I
> know 0030 bd60 5e6b is the MAC address for a station on this network, and
> tcpdump is showing that in the payload of the packets.
>
> Is this type of packet supposed to be parsed by tcpdump and it's failing to
> recognize it somehow? or is it behaving as expected and some code needs to be
> written? Or is there something wrong with these packets?

Well, for one thing

> 15:23:22.529791 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype 0x0c00, length 60: 

is what tcpdump prints for Ethernet frames, so it thinks it's seeing
Ethernet frames, not 802.11 frames - i.e., the driver (I assume this is
the Linux hostap driver from

        http://hostap.epitest.fi/

) is returning an ARPHRD_ value of ARPHRD_ETHER, not one of the
ARPHRD_IEEE80211 values.

> From looking at that driver source, it looks as if the
"hostap_monitor_mode_disable()" routine sets the type to ARPHRD_ETHER,
and presumably turns monitor mode off.

It might be that the driver supplies raw 802.11 packets, or some other
type of packet that doesn't start with a 14-byte Ethernet header, even
if monitor mode is off.  If so, then there's a bug in the driver - it
should either supply an Ethernet header (perhaps synthesizing it from
whatever header it receives), or should supply an ARPHRD_ type that
correctly reflects what the headers are.

There's a program that comes with Ethereal called "editcap" that can be
used to, among other things, read a libpcap-format capture file and
write it out with a different link-layer type (but leave the actual
packet data alone).  You might try capturing to a file, and then using
"editcap" to change the link-layer type to "ieee-802-11" or "prism" (I'd
try them in that order), and see whether the resulting file is correctly
dissected by tcpdump; if you find one that works, send a bug report to
the hostap driver developers mentioning this problem and suggesting an
ARPHRD type of:

        ieee-802-11: ARPHRD_IEEE80211
        prism: ARPHRD_IEEE80211_PRISM
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe