ieee80211_rx_mgmt: pushing fake 'management' frames into userspace

ieee80211_rx_mgmt: pushing fake 'management' frames into userspace

[Mandy.Peng]

Hi,

I have a problem about the relation between mac80211, hostap and
hostapd. In the ieee80211_rx_mgmt( ), it pushes a fake 'management'
frames into userspace via protocol ETH_P_802_2. May I ask which program
will receive this packet to handling management message ? Where can I
find the suitable userspace management program to work with current
mac80211 ? 

Thanks.

Mandy.

Re: ieee80211_rx_mgmt: pushing fake 'management' frames into userspace

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Wed, 2007-06-27 at 21:25 +0800, Mandy.Peng@infineon.com wrote:
> Hi,
> 
> I have a problem about the relation between mac80211, hostap and
> hostapd. In the ieee80211_rx_mgmt( ), it pushes a fake 'management'
> frames into userspace via protocol ETH_P_802_2. May I ask which program
> will receive this packet to handling management message ? 

hostapd and maybe wpa_supplicant

> Where can I
> find the suitable userspace management program to work with current
> mac80211 ? 

That would be wpa_supplicant when compiled for userspace MLME.

However, don't worry about it, this stuff is going to die.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: ieee80211_rx_mgmt: pushing fake 'management' frames into userspace

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 119 bytes --]

Also, I thought you were doing a fullmac chipset? Then you shouldn't be
worrying about mac80211 *at all*

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: ieee80211_rx_mgmt: pushing fake 'management' frames into userspace

[Holger Schurig]

> Also, I thought you were doing a fullmac chipset? Then you
> shouldn't be worrying about mac80211 *at all*

Yes, unfortunately.

Currently, Linux has only fullmac and softmac. However, I'm 
working with a half-soft-half-full-mac hardware (libertas). What 
I mean is that the generation of the low-level packets etc are 
all done by the firmware in the card (fullmac). However, 
issueing scans (for IBSS or Managed mode), selecting a proper AP 
from the scan result, associating etc are all commands that the 
PC has to send to the firmware.

Some of this is not yet correctly working, e.g. when I kick out 
the WLAN card from the AP, then libertas just notifies this, but 
stays up ... it doesn't re-scan and re-associates. There are 
other scenarios where the current libertas code doesn't 
automatically re-scan/re-associate as well.

All of this is included in net/mac80211/ieee80211_sta.c, but 
tightly coupled to mac80211 so that it is unusable for 
non-mac80211 cards. Sigh.

Re: ieee80211_rx_mgmt: pushing fake 'management' frames into userspace

[Dan Williams]

On Wed, 2007-06-27 at 17:30 +0200, Holger Schurig wrote:
> > Also, I thought you were doing a fullmac chipset? Then you
> > shouldn't be worrying about mac80211 *at all*
> 
> Yes, unfortunately.
> 
> Currently, Linux has only fullmac and softmac. However, I'm 
> working with a half-soft-half-full-mac hardware (libertas). What 
> I mean is that the generation of the low-level packets etc are 
> all done by the firmware in the card (fullmac). However, 
> issueing scans (for IBSS or Managed mode), selecting a proper AP 
> from the scan result, associating etc are all commands that the 
> PC has to send to the firmware.

Are you talking about 88w838x parts here?

> Some of this is not yet correctly working, e.g. when I kick out 
> the WLAN card from the AP, then libertas just notifies this, but 
> stays up ... it doesn't re-scan and re-associates. There are 
> other scenarios where the current libertas code doesn't 
> automatically re-scan/re-associate as well.
> 
> All of this is included in net/mac80211/ieee80211_sta.c, but 
> tightly coupled to mac80211 so that it is unusable for 
> non-mac80211 cards. Sigh.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ieee80211_rx_mgmt: pushing fake 'management' frames into userspace

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

On Wed, 2007-06-27 at 17:30 +0200, Holger Schurig wrote:
> > Also, I thought you were doing a fullmac chipset? Then you
> > shouldn't be worrying about mac80211 *at all*
> 
> Yes, unfortunately.

[...]

I think Mandy's got the right idea here, just use the userspace MLME.
But that chipset actually doesn't do any management tasks at all if I
understand correctly.

Feel free to decouple these things in mac80211 though.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

RE: ieee80211_rx_mgmt: pushing fake 'management' frames intouserspace

[Mandy.Peng]

>-----Original Message-----
>From: Johannes Berg [mailto:johannes@sipsolutions.net] 
>Sent: Wednesday, June 27, 2007 10:02 PM
>To: Peng Mandy (IFTW COM AC SE)
>Cc: linux-wireless@vger.kernel.org
>Subject: Re: ieee80211_rx_mgmt: pushing fake 'management' frames
intouserspace
>
>Also, I thought you were doing a fullmac chipset? Then you shouldn't be
worrying about mac80211 *at all*
>
>johannes

Yes, I have to worry about it. Since our chipset only handle the data
path task, the host software has to take care of all the management
tasks. If we write a netdevice driver and register to cfg80211. Then we
should use the similar way to pass through the management frame as
mac80211. So I wondering how do you testing the mac80211 management
action ? Which version of hostapd and wpa_supplicant are you used to
verify the mac80211 ? We will set up the set environment.

Mandy.

RE: ieee80211_rx_mgmt: pushing fake 'management' frames intouserspace

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

On Thu, 2007-06-28 at 16:40 +0800, Mandy.Peng@infineon.com wrote:

> Yes, I have to worry about it. Since our chipset only handle the data
> path task, the host software has to take care of all the management
> tasks.

Oh. That's an interesting setup, and will require changes to mac80211 to
avoid the 802.3 -> 802.11 reframing and much of the transmit patch.
Interesting, and probably not the simplest thing to do right now. If
you're willing to share some specification on the chipset or such we
should be able to help you with the driver and required mac80211
changes.

And if your device handles all of the datapath, then how can you
transmit raw 802.11 management frames? Is there a bit in the
device-specific transmit header you can set to have it avoid using the
data path handling in firmware? [1]

> If we write a netdevice driver and register to cfg80211. Then we
> should use the similar way to pass through the management frame as
> mac80211.

Ah. That works too, but then you'll be relying on the userspace MLME.
That's fine, however all this stuff hasn't really been worked out
properly yet.

>  So I wondering how do you testing the mac80211 management
> action ? Which version of hostapd and wpa_supplicant are you used to
> verify the mac80211 ? We will set up the set environment.

I have to admit that I've never ran any userspace MLME besides hostapd,
but right now you're probably more managed in managed mode, i.e.
wpa_supplicant, I've never tried that. You might want to talk to Jouni
(CC'ed).

johannes

[1] if that's the case, then you should be able to write a mac80211
driver right now that puts the transmit path into software. That would
allow you to have a driver now and change things accordingly later.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]