problem with the hfa384x_rx_frame structure?


From: Peter K. Lee (saint_at_elixar.net)
Date: 2002-03-18 01:25:47 UTC



I just ran across this while enabling support for host-ap prism2 driver into AirTraf. After numerous binary dumps to figure out what the hell was wrong, and comparing the binary dumps to one produced by cisco aironet driver, this is what I found...

The original structure is as below:

struct hfa384x_rx_frame {

/* HFA384X RX frame descriptor */

	u16 status __attribute__ ((packed));
	u32 time __attribute__ ((packed));
	u8 silence __attribute__ ((packed));
	u8 signal __attribute__ ((packed));
	u8 rate __attribute__ ((packed));
	u8 rxflow __attribute__ ((packed));
	u32 reserved __attribute__ ((packed));


/* 802.11 */
u16 frame_control __attribute__ ((packed)); u16 duration_id __attribute__ ((packed)); u8 addr1[6] __attribute__ ((packed)); u8 addr2[6] __attribute__ ((packed)); u8 addr3[6] __attribute__ ((packed)); u16 seq_ctrl __attribute__ ((packed)); u8 addr4[6] __attribute__ ((packed)); u16 data_len __attribute__ ((packed));
/* 802.3 */
u8 dst_addr[6] __attribute__ ((packed)); u8 src_addr[6] __attribute__ ((packed)); u16 len __attribute__ ((packed));
/* followed by frame data */

};

But for some reason, if you look at the data below the /*802.3 */ stuff:

/* 802.3 */

	u8 dst_addr[6] __attribute__ ((packed));
	u8 src_addr[6] __attribute__ ((packed));
	u16 len __attribute__ ((packed));

==>     u8 crap[6] __attribute__ ((packet));


/* followed by frame data */

there's the "u8 crap[6]" stuff before it is followed by the real frame data. And that "crap" happen to be the "u8 mac4[6]" if you interpret it in comparison with the aironet driver's output. which brings to question what the hell the original "u8 mac4[6]" is holding, but it just seemed to be bunch of 0's...

Just thought I'd bring this to attention, not sure if its already known, since somehow 'wlansniff' does get the management capability (ap info) out properly, but fixing up the structure as above was necessary for proper operation via opening raw netlink socket... if you want to program sniffing stuff using host-ap driver.

BTW, good news is that I *did* get it to work out nicely with AirTraf, so if anyone's interested, or (were interested but was hoping for prism2 card support), it is FULLY integrated, along with wireless extension support to dynamically change channels and scan for access points in incremental manner. For latest screenshots, visit http://www.elixar.net/airtraf. (it'll be released a bit later, need to modify some stuff, but a sneak preview :)

thanks,

Peter K. Lee



This archive was generated by hypermail 2.1.4.