From: Jouni Malinen (jkm_at_ssh.com)
Date: 2002-03-21 17:55:20 UTC
On Thu, Mar 21, 2002 at 03:28:25AM -0500, Peter K. Lee wrote:
> What do you mean monitor mode 2 'changes' the wlan0 device to include
> 802.11 header so that it can be sniffed directly? monitor mode 1
> includes the 802.11 header perfectly fine... Or do you mean that
> monitor mode 2 delivers packet in a format that program such as Ethereal
> expects it? (i.e. without the Prism2 headers?)
Monitor mode 1 uses netlink broadcast for sending the sniffed packets to user space. Monitor mode 2 changes netdevice type from ARPHRD_ETHER into ARPHRD_IEEE80211 and the packets are delivered using the wlan0 device.
> If so, what is the packet format? does it start with raw 802.11
> frames? Then, how do you interface in the socket level to open the
> socket for reading? (PF_PACKET? any example code that can use monitor
> mode 2 socket reading w/o relying on external libraries?)
The packet starts with raw 802.11 header (instead of Ethernet header used normally). Packet socket would probably be the best method for accessing the packets in monitor mode 2. Newer versions of libpcap has support for ARPHRD_IEEE80211 type and its Linux specific file has example code for this.
> Also, I posted earlier regarding the inconsistencies I found in the
> defined hfa384x_rx_frame format. Is that a problem that is card
> specific? And I do not understand the existance of 802.3 da/sa stuff as
> part of the hfa384x_rx_frame format. It seems to be filled with 0's and
> not used?
hfa384x_rx_frame is a Prism2 specific header used by the card firmware to pass some values. Most of the fields are in the same position as in hfa384x_tx_frame and since the firmware supports operations both on 802.3 and 802.11 level from the host driver, there are some unused fields depending on the used mode.
> Also, one more thing... I noticed that when I opened the socket layer
> in netlink device, to read in raw frames in monitor mode 1, I was unable
> to use the same socket descriptor to issue wireless extension ioctl
> calls... I had to resort to opening up dummy sockets (non-raw) as how
> iwconfig/iwpriv program interfaced with the card in order to make the
> ioctl calls... Why the difference?
Linux netlink sockets do not seem to implement ioctl()s. I would assume that this leads to kernel ignoring those ioctl() attemps when you have used socket(AF_NETLINK, ...).
-- Jouni Malinen SSH Communications Security Corp jouni.malinen_at_ssh.com