Jouni Malinen wrote:
Hi Jouni -
There is a start on a formal RFC for the broadcast transport protocol here:
http://penumbra.warmcat.com/penumbra-rfc-0.0.3.txt
Could you please extend the description of "Wireless Packet Format" to
define all fields in the 802.11 header. I would especially be interested
in seeing what is in the FromDS and ToDS fields of the frame control.
I'm assuming this is using normal data frames, but that (type and
subtype fields) should also be described clearly.
I extended it to this:
frame_control: 08 01 (FCTL_DATA/STYPE_DATA/TODS)
duration_id: 00 00
addr1: FF:FF:FF:FF:FF:FF
addr2: 13:22:33:44:55:66
addr3: 13:22:33:44:55:66
seq_ctrl: 00:00
The TODS will always be accepted for transmission by even a pedantic
device in INFRA mode, and any combination will be accepted in MONITOR
mode. Whereas one of the devices (IPW3945? I forget) would not issue
packets with FROMDS in INFRA mode IIRC.
- The wireless driver gets the packet for transmission, recognizes the
Magic MAC, disables retries and sets the transmission rate (currently
fixed 54Mbps, but this will change) and transmits the packet as a broadcast
So this frame is to be sent by the non-AP STAs directly as a broadcast
frame, not through the AP which is the normal way of transmitting
frames(?)
Yes -- even further there is nothing in the broadcast frame to identify
the sender or recipient. The broadcast frame is not directed at
anything either: any number of stations are either in range to accept it
or not. If you're not in range, but through one or more hops you are in
range of someone that is, a store-and-forward system that rides of top
of this enables intercommunication anyway. So your street or building
or carpark or train or airplane can be a more interesting place,
hopefully even if you are not associated or have nothing to associate to.
I hope there is some interest in this new capability for wireless
devices in Linux. To get any kind of widespread use, the capability
needs to be already available in stock kernels and drivers so that the
user only needs to open iptables and run a userspace daemon rather than
patch his wireless drivers and stack. So this is my reason for
presenting this Request For Comments, to see if it can be considered.
You would need to add "and configure the wlan driver/802.11 stack to
enable this". I don't think this has to be disabled by default.
Yes if I understood it I can bring up the monitor interface when the
daemon is started and take it down when it is stopped.
Is this only for Linux at the moment or is someone looking at supporting
this with other OSes?
It will really become more useful with Windows support. I looked a
little way into it and found they seem to have a hookable minidriver
idea for XP SP2 and Vista. I am hoping somebody with experience on that
side will write it once the system is easily available on Linux.
- Hardware promisc is needed to catch the packets because they are not
tagged as coming from the local AP. All the devices I looked at can do
hardware promisc separately from the logical promisc for Monitor mode.
But perhaps this needs to be enabled and disabled in some modal way.
This has to be disabled by default. There is a reason for such a
filtering in wlan designs and just enabling promiscuous mode at 802.11
level is going to considerable increase power needs for the device which
is not acceptable for many low-power devices.
Fair enough: it seems that creating the logical Monitor interface for rx
will and using that instead of the current system of private monitoring
with hardware promisc will take care of that as well, it will only be
doing promisc while the daemon runs and the interface is up.
-Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
