d80211: indicate if unassociate/radio off status
Subsystems (2)
PATCH 5/7 d80211: indicate if unassociate/radio off status
This patch indicate unassociated and radio off status in name field
net/d80211/ieee80211_ioctl.c +13 -0
@@ -1538,6 +1538,19 @@ static int ieee80211_ioctl_giwname(struc char *name, char *extra) { struct ieee80211_local *local = dev->ieee80211_ptr; +struct ieee80211_sub_if_data *sdata; + + sdata =IEEE80211_DEV_TO_SUB_IF (dev); +if (!local->conf.radio_enabled) { +strcpy (name,"radio off" ); +return 0 ; + }else if (sdata->type ==IEEE80211_IF_TYPE_STA ) { +if ((sdata->u.sta.state !=IEEE80211_ASSOCIATED ) || + (sdata->u.sta.probereq_poll)) { +strcpy (name,"unassociated" ); +return 0 ; + } + }switch (local->conf.phymode) {case MODE_IEEE80211A :
It would be helpful if you inlined your patches instead of attaching them next time.
I'm not comfortable with using the name for this purpose. Don't we just report 00:00:00:00:00:00 when not associated? Also, for radio off, wasn't that being covered by the rfkill patches?
-Michael Wu
Quoted 2 lines · Michael Wu
It would be helpful if you inlined your patches instead of attaching them next time.
Agreed.
Quoted 1 line
I'm not comfortable with using the name for this purpose.
And agreed. wireless.h has this to say about SIOCGIWNAME:
#define SIOCGIWNAME 0x8B01 /* get name == wireless protocol */
/* SIOCGIWNAME is used to verify the presence of Wireless Extensions.
* Common values : "IEEE 802.11-DS", "IEEE 802.11-FH", "IEEE 802.11b"...
* Don't put the name of your driver there, it's useless. */
The proposed use here is against this and should not be applied. SIOCGIWAP can be used to indicate association status and SIOCGIWTXPOW can be used to indicate whether TX is powered which is quite close to radio off indication.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Quoted 24 lines · Jouni Malinen
Quoted 3 lines · Michael Wu
It would be helpful if you inlined your patches instead of attaching them next time.
Agreed.
Quoted 3 lines
I'm not comfortable with using the name for this purpose.
And agreed.
wireless.hhas this to say about SIOCGIWNAME:#define SIOCGIWNAME
0x8B01/* get name == wireless protocol */
/* SIOCGIWNAME is used to verify the presence of Wireless Extensions.
* Common values : "IEEE 802.11-DS", "IEEE 802.11-FH", "IEEE 802.11b"...
* Don't put the name of your driver there, it's useless. */
Quoted 7 lines
The proposed use here is against this and should not be applied. SIOCGIWAP can be used to indicate association status and SIOCGIWTXPOW can be used to indicate whether TX is powered which is quite close to radio off indication.
to associated to a network i do the following
#iwconfig wlan0 essid {some name} channel X ap {bssid of the AP}
after I issues this command SIOCGIWAP will always report the bssid no matter what the status of our link.
Quoted 2 lines · Mohamed Abbas
SIOCGIWAP will always report the bssid no
matter what the status of our link.
That is not the case at the moment. Were you planning to change that?
-Michael Wu
Quoted 6 lines · Michael Wu
Quoted 2 lines · Mohamed Abbas
SIOCGIWAP will always report the bssid no
matter what the status of our link.That is not the case at the moment. Were you planning to change that?
Opps, it looks like it is the case. Ignore that.
Perhaps we should make SIOCGIWAP always reflect the AP we're currently associated to, and 00:00:00:00:00:00 if there is none.
-Michael Wu
Quoted 5 lines · Michael Wu
Quoted 4 lines · Michael Wu
Quoted 2 lines · Mohamed Abbas
SIOCGIWAP will always report the bssid no
matter what the status of our link.
Quoted 8 lines
Quoted 2 lines
That is not the case at the moment. Were you planning to change that?
Opps, it looks like it is the case. Ignore that.
Perhaps we should make SIOCGIWAP always reflect the AP we're currently associated to, and 00:00:00:00:00:00 if there is none.
-Michael Wu
Um, that's how it's supposed to work, and that's how it's always worked. If you're associated with an access point, its BSSID is returned from SIOCGIWAP. If you are not associated, 00:00:00:00:00:00 is returned. Please don't break that. The driver should also send the appropriate netlink IWAP events when it gets disconnected or when a successful connection occurs using wireless_send_event().
If a valid BSSID is returned from an SIOCGIWAP, it's assumed that that access point will allow your traffic to pass, i.e. all required association and authentication has successfully completed.
SIOCGIWAP behavior does _not_ necessarily reflect what BSSID is set with SIOCSIWAP.
Dan
Quoted 4 lines · Dan Williams
Um, that's how it's supposed to work, and that's how it's always worked. If you're associated with an access point, its BSSID is returned from SIOCGIWAP. If you are not associated, 00:00:00:00:00:00 is returned. Please don't break that.
It's already broken in d80211, AFAICT. That's why I replied to myself, after checking how the implementation actually works.
-Michael Wu
Jiri Benc
NAKQuoted 2 lines · mabbas
This patch indicate unassociated and radio off status in name field
NAK.
Fix SIOCGIWAP handler instead.
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs
Quoted 7 lines · Jiri Benc
Quoted 2 lines · mabbas
This patch indicate unassociated and radio off status in name field
NAK.
Fix SIOCGIWAP handler instead.
Right; the _one_ place anyone should ever have to check for unassociated status is SIOCGIWAP. That's it. Lets not put stuff in two different places. If it's all 0s, all 4s (stupid prism) or all Fs (i forget who does that), it's invalid and you're not connected.
About the worst thing we can start doing is having to parse arbitrary strings to find out driver/card status. That's the same problem with "<hidden>" which hope DIES DIES DIES with d80211. If the AP is hidden, then it has a _blank_ SSID, not hacked to "<hidden>".
For radio off, that may be a legitimate thing that's not covered in WE yet. But isn't that the domain of SIOCGIWPOWER, or is that just used to set PM modes and not return current status? [1]
Dan
[1] which would seem like an oversight to correct in nl80211
Quoted 2 lines
Jiri
Quoted 22 lines · Dan Williams
Quoted 9 lines · Jiri Benc
Quoted 3 lines · mabbas
This patch indicate unassociated and radio off status in name field
NAK.
Fix SIOCGIWAP handler instead.
Right; the _one_ place anyone should ever have to check for unassociated status is SIOCGIWAP. That's it. Lets not put stuff in two different places. If it's all 0s, all 4s (stupid prism) or all Fs (i forget who does that), it's invalid and you're not connected.
About the worst thing we can start doing is having to parse arbitrary strings to find out driver/card status. That's the same problem with "<hidden>" which hope DIES DIES DIES with d80211. If the AP is hidden, then it has a _blank_ SSID, not hacked to "<hidden>".
Quoted 9 lines
For radio off, that may be a legitimate thing that's not covered in WE yet. But isn't that the domain of SIOCGIWPOWER, or is that just used to set PM modes and not return current status? [1]
Dan
[1] which would seem like an oversight to correct in nl80211
SIOCGIWPOWER is for power save mode it has nothing to do with radio off, we can indicate radio off in txpower field i guess. I have question regarding SIOCGIWAP. if I do #iwconfig ap 00:13:23:87:150:150, wont iwconfig always show 00:13:23:87:150:150 for SIOCGIWAP regardless if we associated or not? can we display blank in this case to indicate not connected? Mohamed
Quoted 3 lines
Quoted 3 lines
Jiri
Quoted 33 lines · mabbas
Quoted 22 lines · Dan Williams
Quoted 9 lines · Jiri Benc
Quoted 3 lines · mabbas
This patch indicate unassociated and radio off status in name field
NAK.
Fix SIOCGIWAP handler instead.
Right; the _one_ place anyone should ever have to check for unassociated status is SIOCGIWAP. That's it. Lets not put stuff in two different places. If it's all 0s, all 4s (stupid prism) or all Fs (i forget who does that), it's invalid and you're not connected.
About the worst thing we can start doing is having to parse arbitrary strings to find out driver/card status. That's the same problem with "<hidden>" which hope DIES DIES DIES with d80211. If the AP is hidden, then it has a _blank_ SSID, not hacked to "<hidden>".
Quoted 9 lines
For radio off, that may be a legitimate thing that's not covered in WE yet. But isn't that the domain of SIOCGIWPOWER, or is that just used to set PM modes and not return current status? [1]
Dan
[1] which would seem like an oversight to correct in nl80211
Quoted 5 lines
SIOCGIWPOWER is for power save mode it has nothing to do with radio off, we can indicate radio off in txpower field i guess. I have question regarding SIOCGIWAP. if I do #iwconfig ap 00:13:23:87:150:150, wont iwconfig always show 00:13:23:87:150:150 for SIOCGIWAP regardless if we associated or not? can we display blank in this case to indicate not connected?
That's kind a hole in the WE API. In this case, I think, SIOCGIWAP should always return the BSSID of the current association, or none if there is no association.
Doing an iwconfig ap xx:xx:xx:xx:xx:xx should make the driver internally locked to that BSSID, such that until you clear that lock, SIOCGIWAP should only show either that BSSID or 00:00:00:00:00:00. SIOCGIWAP should not return a valid BSSID when there is no association.
Hopefully nl80211 can fix this omission in WE.
Dan
Quoted 7 lines
Mohamed
Quoted 3 lines
Quoted 3 lines
Jiri
Quoted 47 lines · Dan Williams
Quoted 31 lines · mabbas
Quoted 29 lines · Dan Williams
Quoted 12 lines · Jiri Benc
Quoted 4 lines · mabbas
This patch indicate unassociated and radio off status in name field
NAK.
Fix SIOCGIWAP handler instead.
Right; the _one_ place anyone should ever have to check for unassociated status is SIOCGIWAP. That's it. Lets not put stuff in two different places. If it's all 0s, all 4s (stupid prism) or all Fs (i forget who does that), it's invalid and you're not connected.
About the worst thing we can start doing is having to parse arbitrary strings to find out driver/card status. That's the same problem with "<hidden>" which hope DIES DIES DIES with d80211. If the AP is hidden, then it has a _blank_ SSID, not hacked to "<hidden>".
For radio off, that may be a legitimate thing that's not covered in WE yet. But isn't that the domain of SIOCGIWPOWER, or is that just used to set PM modes and not return current status? [1]
Quoted 9 lines
Quoted 6 lines
Dan
[1] which would seem like an oversight to correct in nl80211
SIOCGIWPOWER is for power save mode it has nothing to do with radio off, we can indicate radio off in txpower field i guess. I have question regarding SIOCGIWAP. if I do #iwconfig ap 00:13:23:87:150:150, wont iwconfig always show 00:13:23:87:150:150 for SIOCGIWAP regardless if we associated or not? can we display blank in this case to indicate not connected?
That's kind a hole in the WE API. In this case, I think, SIOCGIWAP should always return the BSSID of the current association, or none if there is no association.
Quoted 9 lines
Doing an iwconfig ap xx:xx:xx:xx:xx:xx should make the driver internally locked to that BSSID, such that until you clear that lock, SIOCGIWAP should only show either that BSSID or 00:00:00:00:00:00. SIOCGIWAP should not return a valid BSSID when there is no association.
Hopefully nl80211 can fix this omission in WE.
Dan
I can fix the patch to do just that if we agree on that.
Quoted 10 lines
Quoted 10 lines
Mohamed
Quoted 4 lines
Quoted 4 lines
Jiri
Quoted 1 line · mabbas
I can fix the patch to do just that if we agree on that.
Well, we need a flag indicating whether we are associated or not. I don't know about such a flag in WE (hopefully we will have that in nl80211).
Now we have two possibilities:
(a) If a fixed BSSID is set (via SIOCSIWAP), return it from SIOCGIWAP. There is no way to find out whether we are associated or not. The behaviour is also inconsistent with the case when no fixed BSSID is set - SIOCGIWAP returns all zeros or some (random from our POV) BSSID then. So, when you get a BSSID from SIOCGIWAP, to determine what that means you need to know if there was a fixed BSSID set. To do that you need to get a BSSID from SIOCGIWAP. The chicken and egg problem?
(b) SIOCSIWAP returns zeros when we are not associated, BSSID otherwise. There is no way to find out if you set a fixed BSSID or not. If you accidentally set a fixed BSSID you will have a hard time finding out why your card is not associating.
Jean, are there any other possibilities?
If not, (b) seems much more reasonable to me, because:
- The value returned from SIOCGIWAP has a well-defined meaning independent of the current configuration of the interface.
- Dan wants that.
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs
Quoted 5 lines · Jiri Benc
Quoted 1 line · mabbas
I can fix the patch to do just that if we agree on that.
Well, we need a flag indicating whether we are associated or not. I don't know about such a flag in WE (hopefully we will have that in nl80211).
SIOCSIWAP is that flag.
Sorry, but the way "struct sockaddr" is designed did not allow
for having an explicit flag, otherwise I would have done it like for every other commands.
Quoted 10 lines
Now we have two possibilities:
(a) If a fixed BSSID is set (via SIOCSIWAP), return it from SIOCGIWAP. There is no way to find out whether we are associated or not. The behaviour is also inconsistent with the case when no fixed BSSID is set - SIOCGIWAP returns all zeros or some (random from our POV) BSSID then. So, when you get a BSSID from SIOCGIWAP, to determine what that means you need to know if there was a fixed BSSID set. To do that you need to get a BSSID from SIOCGIWAP. The chicken and egg problem?
Quoted 6 lines
(b) SIOCSIWAP returns zeros when we are not associated, BSSID otherwise. There is no way to find out if you set a fixed BSSID or not. If you accidentally set a fixed BSSID you will have a hard time finding out why your card is not associating.
Jean, are there any other possibilities?
Yes, dropping SIOCSIWAP (set) entirely, and keep only
SIOCGIWAP (get).
Quoted 4 lines
If not, (b) seems much more reasonable to me, because:
- The value returned from SIOCGIWAP has a well-defined meaning independent of the current configuration of the interface.
- Dan wants that.
(b) is the correct answer ;-)
We need to be pragmatic. Very few people need to set a fixed
BSSID. I would even venture to say that in the case of most people setting a fixed BSSID, it's an error and they should not do it (it kills roaming, which is a desirable feature). I've yet to find a card which scanning is broken to the point that you need to fudge the BSSID.
There are some drivers that don't support SIOCSIWAP (set), and
it's usually not a problem, users are not complaining about it. That's why I claim we could drop the (set) support. Of course, we can't do it because one PhD student at Berkeley need the feature ;-)
If a program like NetworkManager want to play advanced tricks
with the BSSID and want to know if the user has set a fixed BSSID, it can monitor SIOCSIWAP events and remember the state.
Quoted 1 line
Jiri
Regards,
Jean
Quoted 4 lines · Jean Tourrilhes
Quoted 1 line
Jean, are there any other possibilities?
Yes, dropping SIOCSIWAP (set) entirely, and keep only
SIOCGIWAP (get).
I don't think that this would be acceptable.
Quoted 6 lines
We need to be pragmatic. Very few people need to set a fixed
BSSID. I would even venture to say that in the case of most people setting a fixed BSSID, it's an error and they should not do it (it kills roaming, which is a desirable feature). I've yet to find a card which scanning is broken to the point that you need to fudge the BSSID.
Maybe very few _people_ use it directly, but please keep in mind that programs like wpa_supplicant may control roaming and do it by using this SIOCSIWAP. In addition, being able to limit AP selection to one specific BSSID can be quite useful for number of uses.
Quoted 4 lines
There are some drivers that don't support SIOCSIWAP (set), and
it's usually not a problem, users are not complaining about it. That's why I claim we could drop the (set) support. Of course, we can't do it because one PhD student at Berkeley need the feature ;-)
There's more than one PhD student needing this and I would be very much against removing it.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Quoted 8 lines · Jouni Malinen
Quoted 4 lines · Jean Tourrilhes
Quoted 1 line
Jean, are there any other possibilities?
Yes, dropping SIOCSIWAP (set) entirely, and keep only
SIOCGIWAP (get).I don't think that this would be acceptable.
I should have put smileys ;-) You know that's it's not my
style to rock the boat, so SIOCSIWAP won't go away anytime soon.
And actually, I would be more likely to remove RTS/CTS and
Frag first ;-)
Quoted 10 lines
Quoted 6 lines
We need to be pragmatic. Very few people need to set a fixed
BSSID. I would even venture to say that in the case of most people setting a fixed BSSID, it's an error and they should not do it (it kills roaming, which is a desirable feature). I've yet to find a card which scanning is broken to the point that you need to fudge the BSSID.Maybe very few _people_ use it directly, but please keep in mind that programs like
wpa_supplicantmay control roaming and do it by using this SIOCSIWAP.
Yep, fully agree. And in the part of the e-mail you left out,
I described this kind of need and a solution for those specific apps (catching SIOCSIWAP iwevents).
Actually, I'm surprised that those apps don't make more use of
the SIOCS* events. They are a good way to monitor the user and other apps doing change to the wireless config, and could be used to adapt to that.
Quoted 2 lines
In addition, being able to limit AP selection to one specific BSSID can be quite useful for number of uses.
As I said, I've found very few cases where the end-user need
to play with those.
Quoted 7 lines
Quoted 4 lines
There are some drivers that don't support SIOCSIWAP (set), and
it's usually not a problem, users are not complaining about it. That's why I claim we could drop the (set) support. Of course, we can't do it because one PhD student at Berkeley need the feature ;-)There's more than one PhD student needing this and I would be very much against removing it.
Well, so make it one PhD student and one Linux driver hacker ;-)
Quoted 1 line
Jouni Malinen
Have fun... Jean
Quoted 3 lines · Dan Williams
That's kind a hole in the WE API. In this case, I think, SIOCGIWAP should always return the BSSID of the current association, or none if there is no association.
I was never sure if it was a hole or just a lack of clearly defined semantics (duh, I should probably look at the iwconfig code......)
Quoted 6 lines
Doing an iwconfig ap xx:xx:xx:xx:xx:xx should make the driver internally locked to that BSSID, such that until you clear that lock, SIOCGIWAP should only show either that BSSID or 00:00:00:00:00:00. SIOCGIWAP should not return a valid BSSID when there is no association.
Hopefully nl80211 can fix this omission in WE.
I think I have addressed this already.
+ /* set access point BSSID for userspace roaming */
+ NL80211_CMD_SET_BSSID,
...
+
+ /* BSSID to associate to, only used when roaming control
+ * is in userspace */
+ NL80211_ATTR_BSSID,
+
...
+ /* get current association information, if not associated then
+ * the BSSID attribute is not present in response */
+ NL80211_CMD_GET_ASSOCIATION,
as well as in the compatibility document:
+SIOCSIWAP
+ -> if bssid is all-ones: set roaming to kernel, reassociate + -> if bssid is all-zeroes: set roaming to kernel + -> otherwise: set roaming to userspace, set bssid
+
+SIOCGIWAP
+ -> get association parameters and fill return bssid appropriately
I think that should do what you need, no?
johannes
Quoted 43 lines · Johannes Berg
Quoted 3 lines · Dan Williams
That's kind a hole in the WE API. In this case, I think, SIOCGIWAP should always return the BSSID of the current association, or none if there is no association.
I was never sure if it was a hole or just a lack of clearly defined semantics (duh, I should probably look at the iwconfig code......)
Quoted 6 lines
Doing an iwconfig ap xx:xx:xx:xx:xx:xx should make the driver internally locked to that BSSID, such that until you clear that lock, SIOCGIWAP should only show either that BSSID or 00:00:00:00:00:00. SIOCGIWAP should not return a valid BSSID when there is no association.
Hopefully nl80211 can fix this omission in WE.
I think I have addressed this already.
(quoted diff) +10
-0+ /* set access point BSSID for userspace roaming */ + NL80211_CMD_SET_BSSID, + + /* BSSID to associate to, only used when roaming control + * is in userspace */ + NL80211_ATTR_BSSID, + + /* get current association information, if not associated then + * the BSSID attribute is not present in response */ + NL80211_CMD_GET_ASSOCIATION,as well as in the compatibility document:
(quoted diff) +7
-0+SIOCSIWAP + -> if bssid is all-ones: set roaming to kernel, reassociate + -> if bssid is all-zeroes: set roaming to kernel + -> otherwise: set roaming to userspace, set bssid + +SIOCGIWAP + -> get association parameters and fill return bssid appropriately
Quoted 1 line
I think that should do what you need, no?
Looks like it, yes. As long as there are separate mechanisms for the getting/setting a 'locked' BSSID, and a separate attribute for the currently associated access point (if any). Which this looks like it would provide.
Thanks!
Dan
PATCH 1/1 setting bss freq and phymode using rx_status
In reply to Jean Tourrilhesthis patch is a replacement for d80211-iwlist-fix.patch. Now we set bss's phymode and freq using rx_status. The low level driver need to set these values.
net/d80211/ieee80211_sta.c +2 -2
@@ -1539,9 +1539,9 @@ #endif } - bss->hw_mode = local->conf.phymode; + bss->hw_mode = rx_status->phymode; bss->channel = channel; - bss->freq = local->conf.freq; + bss->freq = rx_status->freq; if (channel != local->conf.channel && (local->conf.phymode == MODE_IEEE80211G || local->conf.phymode == MODE_IEEE80211B) &&
Re: [d80211 patch 1/1] setting bss freq and phymode using rx_status
net/d80211/ieee80211_sta.c #endif · line 1547
Quoted 9 lines · mabbas
net/d80211/ieee80211_sta.c +2
-2- bss->hw_mode = local->conf.phymode; + bss->hw_mode = rx_status->phymode; bss->channel = channel; - bss->freq = local->conf.freq; + bss->freq = rx_status->freq; if (channel != local->conf.channel && (local->conf.phymode == MODE_IEEE80211G || local->conf.phymode == MODE_IEEE80211B) &&
Are you sure you want local->conf.phymode here?
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs
Re: [d80211 patch 1/1] setting bss freq and phymode using rx_status
actaully we dont even need local->conf.channel. rx_status->channel holds the channel we physically received the frame on. channel hold the value from ds. if they are not equal then adjust freq. Attached is the modified patch
net/d80211/ieee80211_sta.c +5 -5
@@ -1539,12 +1539,12 @@ #endif } - bss->hw_mode = local->conf.phymode; + bss->hw_mode = rx_status->phymode; bss->channel = channel; - bss->freq = local->conf.freq; -if (channel != local->conf.channel && - (local->conf.phymode ==MODE_IEEE80211G || - local->conf.phymode ==MODE_IEEE80211B ) && + bss->freq = rx_status->freq; +if (channel != rx_status->channel && + (bss->hw_mode ==MODE_IEEE80211G || + bss->hw_mode ==MODE_IEEE80211B ) && channel >=1 && channel <=14 ) {static const int freq_list[] = {2412 ,2417 ,2422 ,2427 ,2432 ,2437 ,2442 ,
Jiri Benc
AppliedRe: [d80211 patch 1/1] setting bss freq and phymode using rx_status
Quoted 5 lines · mabbas
actaully we dont even need
local->conf.channel.rx_status->channelholds the channel
we physically received the frame on. channel hold the value from ds. if they are not equal then
adjust freq. Attached is the modified patch
Applied to my tree. Thanks for the patch!
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs