Re: [Ieee80211-devel] Management Frames

[James K. <jke...@li...>]

Ivo van Doorn wrote:

>Hi,
>
>Recently a update was made in GIT where the payload variable was added to all 
>ieee80211_hdr_*addr structures. But doesn this break the 
>ieee80211_authentication
>ieee80211_probe_response
>ieee80211_assoc_response_frame
>Structures? Each of these have the ieee80211_hdr_3addr inside it, and by 
>adding the payload variable to the header it effectively moves all variables 
>inside the mgmt structures 1 byte.
>Which would cause the data from these structures to be read incorrectly.
>  
>
They are u8 payload[0], which takes no storage and essentially creates a
pointer alias to whatever comes next.

struct foo {
    u8 data1;
    u8 payload[0];
    u8 data2;
} bar;

&bar.data2 == bar.payload

>A second thing I noticed, with code that is already longer in the repository,
>ieee80211_rx_mgt checks which kind of frame it is, and when for example it is 
>a IEEE80211_STYPE_ASSOC_RESP frame, then ieee80211_handle_assoc_resp is being 
>called which will create a network structure and passes it to the driver.
>But when should the status variable be checked?
>  
>
Currently, the stack doesn't know about association; it is just
performing some data transforms from 802.11 structures to native
structures (like ieee80211_network).

As intelligence is moved inot the stack (vs. in each driver), then the
stack will start to manage the association state and need to do things
based on the status.

>It s possible a association request will be rejected by the AP, but with the 
>current stack it means that the packet should be handled like this:
>Driver receives packet, driver checks if it is a mgmt packet, driver checks if 
>it is an IEEE80211_STYPE_ASSOC_RESP  frame, driver checks if the association 
>succeeded, driver passes the packet to the stack, stack creates the network 
>structure, and gives it back to the driver.
>Shouldn't at least the status be checked by the stack?
>  
>
With the ipw2200 at least, the IEEE80211_STYPE_ASSOC_RESP frames would
typically only come through in monitor mode (the firmware/ucode filters
out most management frames)   The exception to this is that after an
associate completes, the QoS code will try and pass the payload to the
ieee80211 subsystem to try and construct a ieee80211_network structure

>So the driver only has to act when a association request succeeded.
>  
>
The current 'handle_management_frame' should probably be retyped to have
specific callbacks for each type of management frame, with a parsed
native structure filled out and provided.  The parsing and calling would
only need to be done if the driver has implemented that callback.

For example, instead of having ieee->handle_management_frame there
should be:

handle_probe_resp()
handle_beacon()
handle_assoc_resp()

Once the ieee80211 stack is more mature, a soft mac solution would
likely have little need for the probe_resp/beacon whereas the assoc_resp
could be used to configure the lmac to do filtering of non-network
packets (as an example)

James