Re: 3945 driver using d80211
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 pgpF2OVtp7q03.pgp Description: PGP signature
RE: 3945 driver using d80211
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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;
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: 3945 driver using d80211
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
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 pgpMi8P3W8Lb5.pgp Description: PGP signature
Re: 3945 driver using d80211
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 MalinenPGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
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 MalinenPGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
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 pgphdl1a29lmf.pgp Description: PGP signature
