From: Peter K. Lee (pkl_at_duke.edu)
Date: 2002-03-21 08:28:25 UTC
Jouni,
> Monitor mode 2 changes the wlan0 device to include 802.11 header so
> that it can be sniffed directly, e.g., using Ethereal, so that there
> is no need for temporary files. This requires quite new version of
> libpcap. In addition, this does not include the Prism2 specific RX
> header (that has, e.g., signal quality info, etc.).
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?)
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?)
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?
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?
Sorry about the numerous questions, but often times I use things that I do not quite understand the internals of, and it really really bothers me...
Thanks,
Peter K. Lee