wireless mini-summit agenda proposals?
Greetings,
It looks as if we have a few venue options for a third wireless summit. While this may seem like a luxury, none of the options are perfect for everyone and each has it's own potential drawbacks. So rather than move blindly forward with any given venue, I think it would be good to discuss some potential agenda points.
This will serve both to determine who is most interested in attending a summit and who might most need to be there. This will also serve to justify the trouble of having a summit at all. So, I'd like to open the 'floor' to discussion proposals.
What discussions pertinent to Linux wireless development do you want to see? What can you contribute to those discussions? How would a face-to-face discussion of that issue be better than an online discussion?
If pressed I could make some suggestions. But for now I would like to see what is on the minds of the wireless development community. So, what would do you suggest?
Thanks,
John
Signature · 2 lines
John W. Linville [email protected]
Quoted 13 lines · John W. Linville
Greetings,
It looks as if we have a few venue options for a third wireless summit. While this may seem like a luxury, none of the options are perfect for everyone and each has it's own potential drawbacks. So rather than move blindly forward with any given venue, I think it would be good to discuss some potential agenda points.
This will serve both to determine who is most interested in attending a summit and who might most need to be there. This will also serve to justify the trouble of having a summit at all. So, I'd like to open the 'floor' to discussion proposals.
Quoted 4 lines
What discussions pertinent to Linux wireless development do you want to see? What can you contribute to those discussions? How would a face-to-face discussion of that issue be better than an online discussion?
cfg80211/nl80211 - overview, get Johannes to disseminate knowledge because email isn't optimal for this. I haven't had enough time to jump into it yet, but the fact that Johannes is the vast majority of the effort here is worrisome. Having a reference implementation (airo, atmel, maybe libertas) of a fullmac driver ported to cfg80211 would probably be very useful, even just to get a sense of how the API works.
rfkill - how to clean up the mess, including how it's all supposed to work from userspace with kernel bits, ACPI bits, vendor modules like asus_acpi and dellWirelessCtl, input-only buttons, etc
WiMAX - what hardware is coming, what the APIs should look like (OMA-DM is likely to be part of Sprint's stack for XOHM), what the driver situation is, and how to fend off a repeat of the 802.11 regulatory situation for WiMAX (most parts are apparently fullmac right now, but softmac will surely come).
802.11s - nail down issues that Javier/Luis/others might have and try to push the 802.11s mesh stack forward (driver issues, API issues, etc)
802.11n - do we need any discussion here or is it just a question of executing on the current plan?
Userspace MLME - what's going on here? Noise around this seems to be quieter these days. Is stuff going according to plan/schedule or are there roadblocks?
lib80211/fullmac - maybe this just needs to be picked up and done by somebody and doesn't need any discussion or whatever
Dan
Quoted 3 lines · Dan Williams
Quoted 2 lines · John W. Linville
Greetings,
Gee, I was going to say something but Dan came forward with anything I had on my mind...sooo, yeah, all that Dan said.
Quoted 7 lines
cfg80211/nl80211 - overview, get Johannes to disseminate knowledge because email isn't optimal for this. I haven't had enough time to jump into it yet, but the fact that Johannes is the vast majority of the effort here is worrisome. Having a reference implementation (airo, atmel, maybe libertas) of a fullmac driver ported to cfg80211 would probably be very useful, even just to get a sense of how the API works.
cfg80211/nl80211 is no further for fullmac drivers than a year ago, all work it got so far is for hostapd.
I have a fairly decent plan how to add association/... support but it lacks execution because it's completely boring work that doesn't buy us any new features since we still have to support wext.
Quoted 2 lines
802.11n - do we need any discussion here or is it just a question of executing on the current plan?
I think with the last patchset from Ron it's mostly done, cleanups still to do and probably QoS improvements (I'm thinking multiqueue netdevs here)
Quoted 3 lines
Userspace MLME - what's going on here? Noise around this seems to be quieter these days. Is stuff going according to plan/schedule or are there roadblocks?
Nobody is working on this, but a good part is done since hostapd works and the userspace MLME needs many of the same features. Again, the biggest thing is cfg80211/nl80211 support, setting a device to userspace MLME mode and implementing the communication.
johannes
Quoted 8 lines · Johannes Berg
Quoted 7 lines
cfg80211/nl80211 - overview, get Johannes to disseminate knowledge because email isn't optimal for this. I haven't had enough time to jump into it yet, but the fact that Johannes is the vast majority of the effort here is worrisome. Having a reference implementation (airo, atmel, maybe libertas) of a fullmac driver ported to cfg80211 would probably be very useful, even just to get a sense of how the API works.
Quoted 7 lines
cfg80211/nl80211 is no further for fullmac drivers than a year ago, all work it got so far is for hostapd.
I have a fairly decent plan how to add association/... support but it lacks execution because it's completely boring work that doesn't buy us any new features since we still have to support wext.
Security setting is a bit broken. There is a missing separation between static and dynamic./WPA wep keys.
Quoted 6 lines
Quoted 2 lines
802.11n - do we need any discussion here or is it just a question of executing on the current plan?
I think with the last patchset from Ron it's mostly done, cleanups still to do and probably QoS improvements (I'm thinking multiqueue netdevs here)
Multiqueue and AP mode support is planed. AP mode requires changes in configuration interface (cfg, wext) and hostapd.
Quoted 11 lines
Quoted 3 lines
Userspace MLME - what's going on here? Noise around this seems to be quieter these days. Is stuff going according to plan/schedule or are there roadblocks?
Nobody is working on this, but a good part is done since hostapd works and the userspace MLME needs many of the same features. Again, the biggest thing is cfg80211/nl80211 support, setting a device to userspace MLME mode and implementing the communication.
johannes
Quoted 12 lines · Tomas Winkler
Quoted 11 lines · Johannes Berg
Quoted 7 lines
cfg80211/nl80211 - overview, get Johannes to disseminate knowledge because email isn't optimal for this. I haven't had enough time to jump into it yet, but the fact that Johannes is the vast majority of the effort here is worrisome. Having a reference implementation (airo, atmel, maybe libertas) of a fullmac driver ported to cfg80211 would probably be very useful, even just to get a sense of how the API works.
cfg80211/nl80211 is no further for fullmac drivers than a year ago, all work it got so far is for hostapd.
Quoted 6 lines
Quoted 4 lines
I have a fairly decent plan how to add association/... support but it lacks execution because it's completely boring work that doesn't buy us any new features since we still have to support wext.
Security setting is a bit broken. There is a missing separation between static and dynamic./WPA wep keys.
How do you mean?
Dan
Quoted 21 lines
Quoted 6 lines
Quoted 2 lines
802.11n - do we need any discussion here or is it just a question of executing on the current plan?
I think with the last patchset from Ron it's mostly done, cleanups still to do and probably QoS improvements (I'm thinking multiqueue netdevs here)
Multiqueue and AP mode support is planed. AP mode requires changes in configuration interface (cfg, wext) and hostapd.
Quoted 11 lines
Quoted 3 lines
Userspace MLME - what's going on here? Noise around this seems to be quieter these days. Is stuff going according to plan/schedule or are there roadblocks?
Nobody is working on this, but a good part is done since hostapd works and the userspace MLME needs many of the same features. Again, the biggest thing is cfg80211/nl80211 support, setting a device to userspace MLME mode and implementing the communication.
johannes
Quoted 13 lines · Dan Williams
Quoted 12 lines · Tomas Winkler
Quoted 11 lines · Johannes Berg
Quoted 7 lines
cfg80211/nl80211 - overview, get Johannes to disseminate knowledge because email isn't optimal for this. I haven't had enough time to jump into it yet, but the fact that Johannes is the vast majority of the effort here is worrisome. Having a reference implementation (airo, atmel, maybe libertas) of a fullmac driver ported to cfg80211 would probably be very useful, even just to get a sense of how the API works.
cfg80211/nl80211 is no further for fullmac drivers than a year ago, all work it got so far is for hostapd.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
I have a fairly decent plan how to add association/... support but it lacks execution because it's completely boring work that doesn't buy us any new features since we still have to support wext.
Security setting is a bit broken. There is a missing separation between static and dynamic./WPA wep keys.
How do you mean?
In wext there is encoding setting for static keys only for wep and extended encoding for dynamic keys including wep keys. In mac80211 both setting are funneled to the same point which is incorrect since the usage is not the same. The major problem is in HW acceleration. The static wep keys are passed as belonging to the station with broadcast address and the driver cannot distinguish if the wep key is dynamic key for the bcast address or it is a static wep key that has to be used for all traffic. The problem is of course visible mostly in AP mode.
Tomas
Quoted 3 lines
Dan
Quoted 23 lines · Tomas Winkler
Quoted 13 lines · Dan Williams
Quoted 12 lines · Tomas Winkler
Quoted 11 lines · Johannes Berg
Quoted 7 lines
cfg80211/nl80211 - overview, get Johannes to disseminate knowledge because email isn't optimal for this. I haven't had enough time to jump into it yet, but the fact that Johannes is the vast majority of the effort here is worrisome. Having a reference implementation (airo, atmel, maybe libertas) of a fullmac driver ported to cfg80211 would probably be very useful, even just to get a sense of how the API works.
cfg80211/nl80211 is no further for fullmac drivers than a year ago, all work it got so far is for hostapd.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
I have a fairly decent plan how to add association/... support but it lacks execution because it's completely boring work that doesn't buy us any new features since we still have to support wext.
Security setting is a bit broken. There is a missing separation between static and dynamic./WPA wep keys.
How do you mean?
Quoted 9 lines
In wext there is encoding setting for static keys only for wep and extended encoding for dynamic keys including wep keys. In mac80211 both setting are funneled to the same point which is incorrect since the usage is not the same. The major problem is in HW acceleration. The static wep keys are passed as belonging to the station with broadcast address and the driver cannot distinguish if the wep key is dynamic key for the bcast address or it is a static wep key that has to be used for all traffic. The problem is of course visible mostly in AP mode.
Ah; right. I don't think there really should be a difference in the API to differentiate static vs. dynamic WEP keys. Instead each key sent to the driver (be it WEP, TKIP, or CCMP) should definitely have a BSSID to which it applies which the userspace caller must set, and if the key is to be used for _all_ traffic, then maybe have a flag for that or use 00:00:00:00:00:00 as the BSSID. If we use "magic" #s like 00:00... for the BSSID then we've got to be sure to document that magic # which is where we all fell down with WEXT. Hence I prefer flags, but whatever.
Dan
Quoted 35 lines · Dan Williams
Quoted 23 lines · Tomas Winkler
Quoted 13 lines · Dan Williams
Quoted 12 lines · Tomas Winkler
Quoted 11 lines · Johannes Berg
Quoted 7 lines
cfg80211/nl80211 - overview, get Johannes to disseminate knowledge because email isn't optimal for this. I haven't had enough time to jump into it yet, but the fact that Johannes is the vast majority of the effort here is worrisome. Having a reference implementation (airo, atmel, maybe libertas) of a fullmac driver ported to cfg80211 would probably be very useful, even just to get a sense of how the API works.
cfg80211/nl80211 is no further for fullmac drivers than a year ago, all work it got so far is for hostapd.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
I have a fairly decent plan how to add association/... support but it lacks execution because it's completely boring work that doesn't buy us any new features since we still have to support wext.
Security setting is a bit broken. There is a missing separation between static and dynamic./WPA wep keys.
How do you mean?
Quoted 9 lines
In wext there is encoding setting for static keys only for wep and extended encoding for dynamic keys including wep keys. In mac80211 both setting are funneled to the same point which is incorrect since the usage is not the same. The major problem is in HW acceleration. The static wep keys are passed as belonging to the station with broadcast address and the driver cannot distinguish if the wep key is dynamic key for the bcast address or it is a static wep key that has to be used for all traffic. The problem is of course visible mostly in AP mode.
Quoted 9 lines
Ah; right. I don't think there really should be a difference in the API to differentiate static vs. dynamic WEP keys. Instead each key sent to the driver (be it WEP, TKIP, or CCMP) should definitely have a BSSID to which it applies which the userspace caller must set, and if the key is to be used for _all_ traffic, then maybe have a flag for that or use 00:00:00:00:00:00 as the BSSID. If we use "magic" #s like 00:00... for the BSSID then we've got to be sure to document that magic # which is where we all fell down with WEXT. Hence I prefer flags, but whatever.
Sure this is not good to make too many interfaces, but a flag must be added, i prefer to not abusing BSSID address.
One other difference is that there might be 4 keys for static wep while only one wep key in WPA.
Tomas
Quoted 4 lines
Dan
Quoted 46 lines · Tomas Winkler
Quoted 35 lines · Dan Williams
Quoted 23 lines · Tomas Winkler
Quoted 13 lines · Dan Williams
Quoted 12 lines · Tomas Winkler
Quoted 11 lines · Johannes Berg
Quoted 7 lines
cfg80211/nl80211 - overview, get Johannes to disseminate knowledge because email isn't optimal for this. I haven't had enough time to jump into it yet, but the fact that Johannes is the vast majority of the effort here is worrisome. Having a reference implementation (airo, atmel, maybe libertas) of a fullmac driver ported to cfg80211 would probably be very useful, even just to get a sense of how the API works.
cfg80211/nl80211 is no further for fullmac drivers than a year ago, all work it got so far is for hostapd.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
I have a fairly decent plan how to add association/... support but it lacks execution because it's completely boring work that doesn't buy us any new features since we still have to support wext.
Security setting is a bit broken. There is a missing separation between static and dynamic./WPA wep keys.
How do you mean?
Quoted 9 lines
In wext there is encoding setting for static keys only for wep and extended encoding for dynamic keys including wep keys. In mac80211 both setting are funneled to the same point which is incorrect since the usage is not the same. The major problem is in HW acceleration. The static wep keys are passed as belonging to the station with broadcast address and the driver cannot distinguish if the wep key is dynamic key for the bcast address or it is a static wep key that has to be used for all traffic. The problem is of course visible mostly in AP mode.
Quoted 9 lines
Ah; right. I don't think there really should be a difference in the API to differentiate static vs. dynamic WEP keys. Instead each key sent to the driver (be it WEP, TKIP, or CCMP) should definitely have a BSSID to which it applies which the userspace caller must set, and if the key is to be used for _all_ traffic, then maybe have a flag for that or use 00:00:00:00:00:00 as the BSSID. If we use "magic" #s like 00:00... for the BSSID then we've got to be sure to document that magic # which is where we all fell down with WEXT. Hence I prefer flags, but whatever.
Quoted 4 lines
Sure this is not good to make too many interfaces, but a flag must be added, i prefer to not abusing BSSID address.
One other difference is that there might be 4 keys for static wep while only one wep key in WPA.
Definitely; there will certainly need to be flags or a 'wep_key_idx' field for WEP key indexes. Should probably just have a 'u32 flags' somewhere that goes along with each key.
Dan
(Excuse the top-posting...this isn't really a reply to Dan, but I wanted to remind everyone of his agenda suggestions...)
I'm sorry I didn't find-out sooner (apparently there was an email delivery problem of some sort), but we got approved for a mini-summit just before OLS in July:
http://www.linuxsymposium.org/2008/minisummits.php
This location is reasonably convenient for both North America and Europe, and many people attend the OLS event anyway. Are there any major objections to this venue?
I'm sure some people will need some help with funds for attending. I don't have any budget for such things, but if you are in need of assistance and believe your attendance to be necessary or beneficial then let me know -- I'll see if I can scratch-up some funds from somewhere.
Any comments?
John
Quoted 56 lines · Dan Williams
Quoted 13 lines · John W. Linville
Greetings,
It looks as if we have a few venue options for a third wireless summit. While this may seem like a luxury, none of the options are perfect for everyone and each has it's own potential drawbacks. So rather than move blindly forward with any given venue, I think it would be good to discuss some potential agenda points.
This will serve both to determine who is most interested in attending a summit and who might most need to be there. This will also serve to justify the trouble of having a summit at all. So, I'd like to open the 'floor' to discussion proposals.
Quoted 4 lines
What discussions pertinent to Linux wireless development do you want to see? What can you contribute to those discussions? How would a face-to-face discussion of that issue be better than an online discussion?
cfg80211/nl80211 - overview, get Johannes to disseminate knowledge because email isn't optimal for this. I haven't had enough time to jump into it yet, but the fact that Johannes is the vast majority of the effort here is worrisome. Having a reference implementation (airo, atmel, maybe libertas) of a fullmac driver ported to cfg80211 would probably be very useful, even just to get a sense of how the API works.
rfkill - how to clean up the mess, including how it's all supposed to work from userspace with kernel bits, ACPI bits, vendor modules like
asus_acpiand dellWirelessCtl, input-only buttons, etcWiMAX - what hardware is coming, what the APIs should look like (OMA-DM is likely to be part of Sprint's stack for XOHM), what the driver situation is, and how to fend off a repeat of the 802.11 regulatory situation for WiMAX (most parts are apparently fullmac right now, but softmac will surely come).
802.11s - nail down issues that Javier/Luis/others might have and try to push the 802.11s mesh stack forward (driver issues, API issues, etc)
802.11n - do we need any discussion here or is it just a question of executing on the current plan?
Userspace MLME - what's going on here? Noise around this seems to be quieter these days. Is stuff going according to plan/schedule or are there roadblocks?
lib80211/fullmac - maybe this just needs to be picked up and done by somebody and doesn't need any discussion or whatever
Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
John W. Linville [email protected]
Quoted 7 lines · John W. Linville
(Excuse the top-posting...this isn't really a reply to Dan, but I wanted to remind everyone of his agenda suggestions...)
I'm sorry I didn't find-out sooner (apparently there was an email delivery problem of some sort), but we got approved for a mini-summit just before OLS in July:
Quoted 5 lines
http://www.linuxsymposium.org/2008/minisummits.php
This location is reasonably convenient for both North America and Europe, and many people attend the OLS event anyway. Are there any major objections to this venue?
It is getting late in the day, but it is worth mentioning that the OLS registration price goes up tomorrow. So, if you think you will come then better go ahead and register ASAP!
Quoted 5 lines
I'm sure some people will need some help with funds for attending. I don't have any budget for such things, but if you are in need of assistance and believe your attendance to be necessary or beneficial then let me know -- I'll see if I can scratch-up some funds from somewhere.
I found that the Linux Foundation has a page describing their travel funding process:
http://www.linux-foundation.org/en/Travelfund
John
Signature · 2 lines
John W. Linville [email protected]
Quoted 7 lines
Quoted 7 lines
I'm sorry I didn't find-out sooner (apparently there was an email delivery problem of some sort), but we got approved for a mini-summit just before OLS in July:
Quoted 7 lines
Quoted 3 lines
This location is reasonably convenient for both North America and Europe, and many people attend the OLS event anyway. Are there any major objections to this venue?
It is getting late in the day, but it is worth mentioning that the OLS registration price goes up tomorrow. So, if you think you will come then better go ahead and register ASAP!
Early registration has been extended to the 15th.
johannes
Quoted 10 lines · Johannes Berg
Quoted 10 lines
Quoted 9 lines
I'm sorry I didn't find-out sooner (apparently there was an email delivery problem of some sort), but we got approved for a mini-summit just before OLS in July:
http://www.linuxsymposium.org/2008/minisummits.php
This location is reasonably convenient for both North America and Europe, and many people attend the OLS event anyway. Are there any major objections to this venue?
Quoted 5 lines
Quoted 3 lines
It is getting late in the day, but it is worth mentioning that the OLS registration price goes up tomorrow. So, if you think you will come then better go ahead and register ASAP!
Early registration has been extended to the 15th.
It doesn't, however, seem to be in place in the web application yet, double-check against the FAQ before paying...
johannes
2008/4/1, Johannes Berg <[email protected]>:
Quoted 16 lines · Johannes Berg
Quoted 14 lines
Quoted 13 lines
Quoted 9 lines
I'm sorry I didn't find-out sooner (apparently there was an email delivery problem of some sort), but we got approved for a mini-summit just before OLS in July:
http://www.linuxsymposium.org/2008/minisummits.php
This location is reasonably convenient for both North America and Europe, and many people attend the OLS event anyway. Are there any major objections to this venue?
It is getting late in the day, but it is worth mentioning that the OLS registration price goes up tomorrow. So, if you think you will come then better go ahead and register ASAP!
Quoted 10 lines
Quoted 1 line
Early registration has been extended to the 15th.
It doesn't, however, seem to be in place in the web application yet,
double-check against the FAQ before paying...johannes
Should we make reservations etc until 26 ? How many days we 'll have for the summit ?
Signature · 3 lines
GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick
Quoted 2 lines · Nick Kossifidis
Should we make reservations etc until 26 ? How many days we 'll have for the summit ?
The mini-summit is just the 22nd. However OLS is the 23rd through the 26th. I recommend staying for OLS both to experience and/or enjoy the event itself but also for the extended opportunities to continue discussions with other wireless developers and other members of the Linux community.
The OLS folks seem to be recommending that people leave on the 28th. However I usually leave on Sunday, in this case the 27th.
Hth! I hope to see you there!
John
Signature · 2 lines
John W. Linville [email protected]
Quoted 3 lines
What discussions pertinent to Linux wireless development do you want to see?
QoS/multiqueue rework.
Quoted 1 line
What can you contribute to those discussions?
Thoughts, but no expertise. We should invite somebody like Patrick McHardy :) But also see my recent mail.
johannes
2008/2/1, Johannes Berg <[email protected]>:
Quoted 6 lines
Quoted 3 lines
What discussions pertinent to Linux wireless development do you want to see?
QoS/multiqueue rework.
Plzzz someone explain how WMM is implemented in mac80211 and suggest some tests so we can be sure we implement it correctly, we really want to add multiqueue support in ath5k ;-)
Also it would be great if someone explained what's new in 802.11n/802.11s and what drivers are expected to do (i think on the previous summit there was a talk about encrypted management frames, do we have a plan for that ?).
Signature · 3 lines
GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick
Quoted 4 lines
Plzzz someone explain how WMM is implemented in mac80211 and suggest some tests so we can be sure we implement it correctly, we really want to add multiqueue support in ath5k ;-)
Well nobody knows ;)
Quoted 4 lines
Also it would be great if someone explained what's new in 802.11n/802.11s and what drivers are expected to do (i think on the previous summit there was a talk about encrypted management frames, do we have a plan for that ?).
There's no 11s support yet, the cozybit guys never came forward with a second patchset after we commented on their first. 11w (encrypted management frames) is pretty straight forward, we add the new "encryption" algorithm and wpa_supplicant does the rest (in fact, it already has code)
johannes
Quoted 2 lines · Johannes Berg
There's no 11s support yet, the cozybit guys never came forward with a second patchset after we commented on their first. 11w (encrypted
We've been a bit busy, with some luck we will send the second patchset today.
Signature · 2 lines
Luis Carlos Cobo Rus GnuPG ID: 44019B60 cozybit Inc.
Quoted 2 lines · Luis Carlos Cobo
We've been a bit busy, with some luck we will send the second patchset today.
We weren't that lucky after all :-)
We have just released a fully functional mesh implementation [1], on top of current wireless-2.6/everything. However I did not have time to prepare the patches for the list, will do next Monday.
[1]: http://o11s.org/trac/wiki/RELEASE_NOTES-0.2.0
Signature · 2 lines
Luis Carlos Cobo Rus GnuPG ID: 44019B60 cozybit Inc.
Quoted 6 lines · Johannes Berg
Quoted 4 lines
Plzzz someone explain how WMM is implemented in mac80211 and suggest some tests so we can be sure we implement it correctly, we really want to add multiqueue support in ath5k ;-)
Well nobody knows ;)
There is a certification plan for that under WiFi with tests. The implementation has some holes but it's passing tests. One glitch I know that the priority scheduler is definitely not working correctly in hight loads. and you better have 4 hardware queues to comply with specification. In that case it's better to have RR scheduler instead of what is there now.
Quoted 13 lines
Quoted 4 lines
Also it would be great if someone explained what's new in 802.11n/802.11s and what drivers are expected to do (i think on the previous summit there was a talk about encrypted management frames, do we have a plan for that ?).
There's no 11s support yet, the cozybit guys never came forward with a second patchset after we commented on their first. 11w (encrypted management frames) is pretty straight forward, we add the new "encryption" algorithm and
wpa_supplicantdoes the rest (in fact, it already has code)johannes