On Tue, Nov 14, 2000 at 03:18:33PM +0100, Johan Jorgensen wrote:
> I am pleased to be able to contribute the code for the IEEE 802.11
> wireless LAN dissector on behalf of Axis Communications AB. The patch
> enables Ethereal to properly dissect and analyze all of the different
> frametypes as defined in the current version of the IEEE 802.11
> standard.
>
> Description of the patch:
> The patch adds a new packet-dissector. It is defined and implemented in
> the files packet-ieee80211.[ch]. A new filetype is defined in
> wtap_fileformat.[ch]. It basically just read or write frames without
> mapping them to pcap or any other format known by wiretap.
I'd prefer not to introduce a new file format, if at all possible; the
current "native" file format for Ethereal is libpcap format, and I'd
like it to remain so as long as possible - with updates made to libpcap
format as necessary.
John Hawkinson at MIT said, in August, in mail to
"tcpdump-workers@xxxxxxxxxxx":
I'm probably going to be adding 802.11 support to tcpdump
shortly. It'll probably be most convenient for me to do this
development in the NetBSD tree, though it'll of course be kicked
back to tcpdump.org when complete.
This involves adding a new DLT_ value for libpcap to use - and, with the
current version of libpcap, a value to use in the header of capture
files, which is not necessarily the same as the DLT_ value (the problem
is that DLT_ values are assigned by developers who don't always talk to
one another, and different platforms *already* have different DLT_ names
for the same numerical values, and different values for the same DLT_
names).
The current version of libpcap in CVS has a LINKTYPE_IEEE802_11 reserved
for future use in capture file headers, with the value 105; I've not put
a DLT_IEEE802_11 into the standard libpcap "bpf.h" file yet, but I'll do
that tonight.
(There doesn't yet appear to be any 802.11 support in the NetBSD CVS
tree; John, what's the current status of the 802.11 support for
tcpdump/libpcap?)
John indicated that the link-layer header on packets in a DLT_IEEE802_11
capture would be
struct wi_80211_hdr {
u_int16_t frame_ctl;
u_int16_t dur_id;
u_int8_t addr1[6];
u_int8_t addr2[6];
u_int8_t addr3[6];
u_int16_t seq_ctl;
u_int8_t addr4[6];
};
which appears to be the header that your dissector analyzes (and appears
to be the format described at the bottom of page 34 of IEEE Std
802.11-1997).
Given that, I'd be inclined, instead, to save 802.11 captures as libpcap
files, with 105 in the "network" field (see "pcap_hdr" in
"wiretap/libpcap.h" in the Ethereal source), rather than add a new
capture file type.