3945 driver using d80211

3945 driver using d80211

[Mohamed Abbas]

Hi
I am currently working on porting 3945 driver to use d80211. The porting 
is going well, thanks for the great stack. I ran into some problems and 
issues that I had to use some work around to have it functioning. I hope 
I can find the help to point me to right way of using the stack.

1- I needed to use sta_info_get function to do rate scaling for 3945, 
although this function is exported but it was missing from d80211.h, for 
work around I had to copy more header files to my driver's directory, It 
this plan to add this function to d80211.h ?

2- Scanning; in 3945 driver, we can not tune to other channels while we 
are connected, this will cause a firmware error. The firmware provides a 
scanning command we call so the firmware will take care of switching of 
the available channels and gather beacons and probe responses. The 
current d80211 the stack will call config callback to switch to 
different channel and send the probe requests. One of our engineers did 
come up with a patch to add one more callback function if provided the 
d80211 will call this function to allow the registered driver to perform 
the scanning functionalities. For work around I currently check inside 
config callback if the scanning flag set I will issues the scan command 
then ignore the next config callback.

3- I can not access beacon's info from current associated AP. 
information I need to callback into the firmware like timestamp and aid, 
work around I would parse incoming management frame and filter beacon 
from associated AP to get this info. This is a duplicate code that 
d80211 stack doing, maybe there is away to get these info that I don’t 
know of. Also it will be nice to have some callback function on 
association, disassociation.

4- I am been using the driver for sometime right now and it seems to be 
stable and liable although I am using SMP system. I hearted of some SMP 
issues in d80211 and I have the machine and time to help in this. Do you 
have any test script the cause this SMP problems? Or steps to reproduce it.

again thanks alot for the great work on d80211.

Thanks

Mohamed Abbas

Re: 3945 driver using d80211

[Michael Wu]

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

On Tuesday 08 August 2006 14:27, Mohamed Abbas wrote:
> 2- Scanning; in 3945 driver, we can not tune to other channels while we
> are connected, this will cause a firmware error. The firmware provides a
> scanning command we call so the firmware will take care of switching of
> the available channels and gather beacons and probe responses. The
> current d80211 the stack will call config callback to switch to
> different channel and send the probe requests. One of our engineers did
> come up with a patch to add one more callback function if provided the
> d80211 will call this function to allow the registered driver to perform
> the scanning functionalities. For work around I currently check inside
> config callback if the scanning flag set I will issues the scan command
> then ignore the next config callback.
>
I think it would be best if you made the firmware not be aware of a 
connection, and let the d80211 code take care of all the 
scanning/authenticating/associating. Of course, I know nothing about 3945, so 
I don't know if that's possible.

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 3945 driver using d80211

[Johannes Berg]

Michael Wu wrote:
> I think it would be best if you made the firmware not be aware of a 
> connection, and let the d80211 code take care of all the 
> scanning/authenticating/associating. Of course, I know nothing about 3945, so 
> I don't know if that's possible.
>   
Please not, for now. We need someone pushing for fullmac features in 
d80211, we need those anyway for embedded systems that can't afford 
running all of it on the main CPU. While obviously Intel would benefit 
from doing this since a lot more d80211 features would come available, 
the greater good would be having a main-stream card that someone cares 
about and helps making d80211 full-mac capable.

johannes

Re: 3945 driver using d80211

[John W. Linville]

On Wed, Aug 09, 2006 at 09:57:12AM +0200, Johannes Berg wrote:
> Michael Wu wrote:
> >I think it would be best if you made the firmware not be aware of a 
> >connection, and let the d80211 code take care of all the 
> >scanning/authenticating/associating. Of course, I know nothing about 3945, 
> >so I don't know if that's possible.
> >  
> Please not, for now. We need someone pushing for fullmac features in 
> d80211, we need those anyway for embedded systems that can't afford 
> running all of it on the main CPU. While obviously Intel would benefit 
> from doing this since a lot more d80211 features would come available, 
> the greater good would be having a main-stream card that someone cares 
> about and helps making d80211 full-mac capable.

I second this opinion.  It would be good to make d80211 more capable
of dealing with these cards.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: 3945 driver using d80211

[Michael Wu]

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

On Wednesday 09 August 2006 00:57, Johannes Berg wrote:
> Please not, for now. We need someone pushing for fullmac features in
> d80211, we need those anyway for embedded systems that can't afford
> running all of it on the main CPU. While obviously Intel would benefit
> from doing this since a lot more d80211 features would come available,
> the greater good would be having a main-stream card that someone cares
> about and helps making d80211 full-mac capable.
>
It's not that hard to generate probe, authentication, and association frames, 
and it isn't done frequently enough to stress any embedded system that can 
run linux. Doing this would let 3945 take advantage of all the d80211 
features, so why not?

What level of fullmac support are we talking about? True fullmac cards (as I 
define them) do not need to use d80211. WE19 is all they need, to add 
WPA/WPA2 support. The IPW cards have a particularly unique split between 
firmware and host 802.11 duties which I haven't seen in any other cards. They 
aren't quite fullmac enough to interface with WE directly, yet they only need 
probe response handling to complete the picture. What other half-fullmac, 
half-softmac card besides the other IPW cards splits card/host 802.11 duties 
along those lines? What other splits between card and host are out there? I 
would be very reluctant to make changes to the 802.11 stack to support 
"fullmac" without evidence that other drivers need the change.

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 3945 driver using d80211

[Christoph Hellwig]

On Wed, Aug 09, 2006 at 09:47:15AM -0700, Michael Wu wrote:
> probe response handling to complete the picture. What other half-fullmac, 
> half-softmac card besides the other IPW cards splits card/host 802.11 duties 
> along those lines? What other splits between card and host are out there? I 
> would be very reluctant to make changes to the 802.11 stack to support 
> "fullmac" without evidence that other drivers need the change.

You need to support ipw2[12]00 anyway.

Re: 3945 driver using d80211

[Dan Williams]

On Wed, 2006-08-09 at 09:47 -0700, Michael Wu wrote:
> On Wednesday 09 August 2006 00:57, Johannes Berg wrote:
> > Please not, for now. We need someone pushing for fullmac features in
> > d80211, we need those anyway for embedded systems that can't afford
> > running all of it on the main CPU. While obviously Intel would benefit
> > from doing this since a lot more d80211 features would come available,
> > the greater good would be having a main-stream card that someone cares
> > about and helps making d80211 full-mac capable.
> >
> It's not that hard to generate probe, authentication, and association frames, 
> and it isn't done frequently enough to stress any embedded system that can 
> run linux. Doing this would let 3945 take advantage of all the d80211 
> features, so why not?
> 
> What level of fullmac support are we talking about? True fullmac cards (as I 
> define them) do not need to use d80211. WE19 is all they need, to add 
> WPA/WPA2 support. The IPW cards have a particularly unique split between 
> firmware and host 802.11 duties which I haven't seen in any other cards. They 
> aren't quite fullmac enough to interface with WE directly, yet they only need 
> probe response handling to complete the picture. What other half-fullmac, 
> half-softmac card besides the other IPW cards splits card/host 802.11 duties 
> along those lines? What other splits between card and host are out there? I 
> would be very reluctant to make changes to the 802.11 stack to support 
> "fullmac" without evidence that other drivers need the change.

The atmel driver is somewhat of a hybrid.  For fullmac cards like airo,
you just set the connection info up, let the card go, and you get back a
link event.  But the atmel driver controls authentication and
association stuff; that's not done in firmware.  Look at:

send_authentication_request()
send_association_request()
atmel_transmit_management_frame()
atmel_management_frame()
authenticate()
associate()

The driver has an auth/assoc state machine, receives management frames,
and sends out the next appropriate management frame based on the current
state.  I think this is the reverse of ipw2100, where the firmware
handles assoc/auth but not much else, but it's still less fullmac than
airo, and more fullmac than softmac.

Dan

Re: 3945 driver using d80211

[Mohamed Abbas]

For 3945 a lot of functionalities were moved to the driver level, what 
kept in the firmware is basically some timely related functions like 
beacon in IBSS mode but the beacon frame is provided by the driver and 
the firmware is responsible to send it according to the timing 
constrains. Also scanning was left in the firmware. We don’t do and 
authentication or association frame in the firmware and we use d80211 to 
do this. We just needed to know once we associated to inform the 
firmware we are associated now. I just want to say d80211 was very 
flexible and easy to work with, the porting process was smooth and we 
only faces these problems with a working workaround and I thought we can 
even make d80211 more flexible to cater more varieties of cards. For 
ipw2[2/1]00 we did a gap analysis and we found it is hard to port it to 
use d80211 because of what mentioned below. I hope to post 3945 with 
d80211 code sometime next week so we can have the code available for our 
discussion.


Thanks
Mohamed

Dan Williams wrote:

>On Wed, 2006-08-09 at 09:47 -0700, Michael Wu wrote:
>  
>
>>On Wednesday 09 August 2006 00:57, Johannes Berg wrote:
>>    
>>
>>>Please not, for now. We need someone pushing for fullmac features in
>>>d80211, we need those anyway for embedded systems that can't afford
>>>running all of it on the main CPU. While obviously Intel would benefit
>>>from doing this since a lot more d80211 features would come available,
>>>the greater good would be having a main-stream card that someone cares
>>>about and helps making d80211 full-mac capable.
>>>
>>>      
>>>
>>It's not that hard to generate probe, authentication, and association frames, 
>>and it isn't done frequently enough to stress any embedded system that can 
>>run linux. Doing this would let 3945 take advantage of all the d80211 
>>features, so why not?
>>
>>What level of fullmac support are we talking about? True fullmac cards (as I 
>>define them) do not need to use d80211. WE19 is all they need, to add 
>>WPA/WPA2 support. The IPW cards have a particularly unique split between 
>>firmware and host 802.11 duties which I haven't seen in any other cards. They 
>>aren't quite fullmac enough to interface with WE directly, yet they only need 
>>probe response handling to complete the picture. What other half-fullmac, 
>>half-softmac card besides the other IPW cards splits card/host 802.11 duties 
>>along those lines? What other splits between card and host are out there? I 
>>would be very reluctant to make changes to the 802.11 stack to support 
>>"fullmac" without evidence that other drivers need the change.
>>    
>>
>
>The atmel driver is somewhat of a hybrid.  For fullmac cards like airo,
>you just set the connection info up, let the card go, and you get back a
>link event.  But the atmel driver controls authentication and
>association stuff; that's not done in firmware.  Look at:
>
>send_authentication_request()
>send_association_request()
>atmel_transmit_management_frame()
>atmel_management_frame()
>authenticate()
>associate()
>
>The driver has an auth/assoc state machine, receives management frames,
>and sends out the next appropriate management frame based on the current
>state.  I think this is the reverse of ipw2100, where the firmware
>handles assoc/auth but not much else, but it's still less fullmac than
>airo, and more fullmac than softmac.
>
>Dan
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  
>

RE: 3945 driver using d80211

[Simon Barber]

There are many different functions in a complete 802.11 implementation -
and different implementations put these functions in different places.
In general, I would consider the primary difference between a "full-mac"
card and others to be the location of the MLME function. All full-mac
cards perform the MLME in the card. They typically also do the
conversion of data frames between 802.3 and 802.11 format in the card as
well, and the inter-BSS transitions are handled in the card too.

This key difference make it very unlikely that full-mac cards will
implement various advanced 802.11 features - such as WDS, virtual APs,
multiple clients, simultaneous client/AP modes etc etc. (Of course, by
adding a large number of APIs all this can theoretically be achieved -
it's just a lot more work this way).

Because the full-mac cards have functions in the card that other cards
do not the API for these cards will necessarily be quite different from
the API for non-full-mac cards. Typically the full mac cards will only
ever expose a single 802.3 interface - and hence they may not need to
have an 802.11 master interface at all. They will require a user space
API that includes control of MLME functions - because the MLME is in the
card. A non full-mac card does not require this user space API - with
the MLME built in to hostapd since year dot, and in new versions of
wpa_supplicant there is little need for the kernel to have a MLME API
from user space - unless you are using a full-mac card. This is a great
thing - goodbye to much of the awkward parts of the legacy kernel
wireless APIs.

In short - full-mac and non full-mac cards have very different kernel
and API requirements. I'd be very careful in looking at how much their
kernel support should be fully merged.

It would be very interesting to do a taxonomy of the different cards,
and look at where different functions are performed.

One question for intel - will intel ever release a firmware for the
2100/2200 that makes the card into a non-full-mac card? (This would make
unified support so much easier, as well as giving the cards much more
capability and flexability.)

Simon


-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Dan Williams
Sent: Wednesday, August 09, 2006 12:23 PM
To: Michael Wu
Cc: Johannes Berg; Mohamed Abbas; netdev@vger.kernel.org
Subject: Re: 3945 driver using d80211

On Wed, 2006-08-09 at 09:47 -0700, Michael Wu wrote:
> On Wednesday 09 August 2006 00:57, Johannes Berg wrote:
> > Please not, for now. We need someone pushing for fullmac features in

> > d80211, we need those anyway for embedded systems that can't afford 
> > running all of it on the main CPU. While obviously Intel would 
> > benefit from doing this since a lot more d80211 features would come 
> > available, the greater good would be having a main-stream card that 
> > someone cares about and helps making d80211 full-mac capable.
> >
> It's not that hard to generate probe, authentication, and association 
> frames, and it isn't done frequently enough to stress any embedded 
> system that can run linux. Doing this would let 3945 take advantage of

> all the d80211 features, so why not?
> 
> What level of fullmac support are we talking about? True fullmac cards

> (as I define them) do not need to use d80211. WE19 is all they need, 
> to add
> WPA/WPA2 support. The IPW cards have a particularly unique split 
> between firmware and host 802.11 duties which I haven't seen in any 
> other cards. They aren't quite fullmac enough to interface with WE 
> directly, yet they only need probe response handling to complete the 
> picture. What other half-fullmac, half-softmac card besides the other 
> IPW cards splits card/host 802.11 duties along those lines? What other

> splits between card and host are out there? I would be very reluctant 
> to make changes to the 802.11 stack to support "fullmac" without
evidence that other drivers need the change.

The atmel driver is somewhat of a hybrid.  For fullmac cards like airo,
you just set the connection info up, let the card go, and you get back a
link event.  But the atmel driver controls authentication and
association stuff; that's not done in firmware.  Look at:

send_authentication_request()
send_association_request()
atmel_transmit_management_frame()
atmel_management_frame()
authenticate()
associate()

The driver has an auth/assoc state machine, receives management frames,
and sends out the next appropriate management frame based on the current
state.  I think this is the reverse of ipw2100, where the firmware
handles assoc/auth but not much else, but it's still less fullmac than
airo, and more fullmac than softmac.

Dan


-
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

RE: 3945 driver using d80211

[Simon Barber]

One thing driving many silicon vendors away from putting the MLME in the
card - is that in order to support the advanced wireless features of MS
Vista you have to leave the MLME to the host! (this is to enable Vista's
advanced wireless features - like simultaneous client/ad-hoc mode). This
is forcing more and more vendors to do things the right way.

Simon
 

-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Simon Barber
Sent: Wednesday, August 09, 2006 2:33 PM
To: Dan Williams; Michael Wu
Cc: Johannes Berg; Mohamed Abbas; netdev@vger.kernel.org
Subject: RE: 3945 driver using d80211

There are many different functions in a complete 802.11 implementation -
and different implementations put these functions in different places.
In general, I would consider the primary difference between a "full-mac"
card and others to be the location of the MLME function. All full-mac
cards perform the MLME in the card. They typically also do the
conversion of data frames between 802.3 and 802.11 format in the card as
well, and the inter-BSS transitions are handled in the card too.

This key difference make it very unlikely that full-mac cards will
implement various advanced 802.11 features - such as WDS, virtual APs,
multiple clients, simultaneous client/AP modes etc etc. (Of course, by
adding a large number of APIs all this can theoretically be achieved -
it's just a lot more work this way).

Because the full-mac cards have functions in the card that other cards
do not the API for these cards will necessarily be quite different from
the API for non-full-mac cards. Typically the full mac cards will only
ever expose a single 802.3 interface - and hence they may not need to
have an 802.11 master interface at all. They will require a user space
API that includes control of MLME functions - because the MLME is in the
card. A non full-mac card does not require this user space API - with
the MLME built in to hostapd since year dot, and in new versions of
wpa_supplicant there is little need for the kernel to have a MLME API
from user space - unless you are using a full-mac card. This is a great
thing - goodbye to much of the awkward parts of the legacy kernel
wireless APIs.

In short - full-mac and non full-mac cards have very different kernel
and API requirements. I'd be very careful in looking at how much their
kernel support should be fully merged.

It would be very interesting to do a taxonomy of the different cards,
and look at where different functions are performed.

One question for intel - will intel ever release a firmware for the
2100/2200 that makes the card into a non-full-mac card? (This would make
unified support so much easier, as well as giving the cards much more
capability and flexability.)

Simon


-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Dan Williams
Sent: Wednesday, August 09, 2006 12:23 PM
To: Michael Wu
Cc: Johannes Berg; Mohamed Abbas; netdev@vger.kernel.org
Subject: Re: 3945 driver using d80211

On Wed, 2006-08-09 at 09:47 -0700, Michael Wu wrote:
> On Wednesday 09 August 2006 00:57, Johannes Berg wrote:
> > Please not, for now. We need someone pushing for fullmac features in

> > d80211, we need those anyway for embedded systems that can't afford 
> > running all of it on the main CPU. While obviously Intel would 
> > benefit from doing this since a lot more d80211 features would come 
> > available, the greater good would be having a main-stream card that 
> > someone cares about and helps making d80211 full-mac capable.
> >
> It's not that hard to generate probe, authentication, and association 
> frames, and it isn't done frequently enough to stress any embedded 
> system that can run linux. Doing this would let 3945 take advantage of

> all the d80211 features, so why not?
> 
> What level of fullmac support are we talking about? True fullmac cards

> (as I define them) do not need to use d80211. WE19 is all they need, 
> to add
> WPA/WPA2 support. The IPW cards have a particularly unique split 
> between firmware and host 802.11 duties which I haven't seen in any 
> other cards. They aren't quite fullmac enough to interface with WE 
> directly, yet they only need probe response handling to complete the 
> picture. What other half-fullmac, half-softmac card besides the other 
> IPW cards splits card/host 802.11 duties along those lines? What other

> splits between card and host are out there? I would be very reluctant 
> to make changes to the 802.11 stack to support "fullmac" without
evidence that other drivers need the change.

The atmel driver is somewhat of a hybrid.  For fullmac cards like airo,
you just set the connection info up, let the card go, and you get back a
link event.  But the atmel driver controls authentication and
association stuff; that's not done in firmware.  Look at:

send_authentication_request()
send_association_request()
atmel_transmit_management_frame()
atmel_management_frame()
authenticate()
associate()

The driver has an auth/assoc state machine, receives management frames,
and sends out the next appropriate management frame based on the current
state.  I think this is the reverse of ipw2100, where the firmware
handles assoc/auth but not much else, but it's still less fullmac than
airo, and more fullmac than softmac.

Dan


-
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

Re: 3945 driver using d80211

[Michael Wu]

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

On Wednesday 09 August 2006 12:22, Dan Williams wrote:
> The atmel driver is somewhat of a hybrid.

I dunno - the last time I checked atmel, it seemed to have quite a bit of 
softmac code. If atmel isn't actually a softmac card, um.. I dunno. What 
parts of it is fullmac?

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 3945 driver using d80211

[Jouni Malinen]

On Tue, Aug 08, 2006 at 02:27:37PM -0700, Mohamed Abbas wrote:

> 1- I needed to use sta_info_get function to do rate scaling for 3945, 
> although this function is exported but it was missing from d80211.h, for 
> work around I had to copy more header files to my driver's directory, It 
> this plan to add this function to d80211.h ?

sta_info_get() (and well, any access to struct sta_info) was not
designed to be available for the rate control modules. Could you please
provide some more details on what kind of information you would need
from there?

> 2- Scanning; in 3945 driver, we can not tune to other channels while we 
> are connected, this will cause a firmware error. The firmware provides a 
> scanning command we call so the firmware will take care of switching of 
> the available channels and gather beacons and probe responses. The 
> current d80211 the stack will call config callback to switch to 
> different channel and send the probe requests. One of our engineers did 
> come up with a patch to add one more callback function if provided the 
> d80211 will call this function to allow the registered driver to perform 
> the scanning functionalities. For work around I currently check inside 
> config callback if the scanning flag set I will issues the scan command 
> then ignore the next config callback.

If the hardware/firmware has such limitation, providing an alternative
mechanism for this is indeed needed. However, I though 3945 did not have
much firmware on it and I was not expecting this kind of requirement
from it (though, I have to admit that I'm not at all familiar with the
details of its design). Anyway, there are other wireless cards that will
need similar mechanism, so this is needed to support more "full mac"
type designs.

> 3- I can not access beacon's info from current associated AP. 
> information I need to callback into the firmware like timestamp and aid, 
> work around I would parse incoming management frame and filter beacon 
> from associated AP to get this info. This is a duplicate code that 
> d80211 stack doing, maybe there is away to get these info that I don’t 
> know of. Also it will be nice to have some callback function on 
> association, disassociation.

What kind of information/events do you need in the low-level hardware
driver? It sounds reasonable to add this kind of event callbacks.

> 4- I am been using the driver for sometime right now and it seems to be 
> stable and liable although I am using SMP system. I hearted of some SMP 
> issues in d80211 and I have the machine and time to help in this. Do you 
> have any test script the cause this SMP problems? Or steps to reproduce it.

I have heard of open claims on there being SMP issues, but I don't think
I've ever seen any details on this. I've also added a dual core laptop
to my testbed, so it will be interesting to see whether I can trigger
any of the issues easily.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: 3945 driver using d80211

[Jouni Malinen]

On Tue, Aug 08, 2006 at 05:06:31PM -0700, Jouni Malinen wrote:
> On Tue, Aug 08, 2006 at 02:27:37PM -0700, Mohamed Abbas wrote:
> 
> > 1- I needed to use sta_info_get function to do rate scaling for 3945, 
> > although this function is exported but it was missing from d80211.h, for 
> > work around I had to copy more header files to my driver's directory, It 
> > this plan to add this function to d80211.h ?
> 
> sta_info_get() (and well, any access to struct sta_info) was not
> designed to be available for the rate control modules. Could you please
> provide some more details on what kind of information you would need
> from there?

Actually, that was not correct.. What I should have said is that
sta_info was not supposed to be available for low-level drivers. If the
rate control algorithm is tightly coupled with the driver, some cleanup
would likely be needed here.

-- 
Jouni Malinen                                            PGP id EFC895FA