[PATCH 5/7] d80211: indicate if unassociate/radio off status

[PATCH 5/7] d80211: indicate if unassociate/radio off status

[mabbas]

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



[-- Attachment #2: d80211-wname.patch --]
[-- Type: text/x-patch, Size: 896 bytes --]


This patch indicate unassociated and radio off status
in name field

Signed-off-by: Mohamed Abbas <mabbas@linux.intel.com>

diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 89a58e3..44b2698 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -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:

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Michael Wu]

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

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

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

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Jouni Malinen]

On Mon, Aug 28, 2006 at 02:17:34PM -0700, Michael Wu wrote:

> It would be helpful if you inlined your patches instead of attaching them next 
> time.

Agreed.

> 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.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Mohamed Abbas]

Jouni Malinen wrote:

>On Mon, Aug 28, 2006 at 02:17:34PM -0700, Michael Wu wrote:
>
>  
>
>>It would be helpful if you inlined your patches instead of attaching them next 
>>time.
>>    
>>
>
>Agreed.
>
>  
>
>>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.
>
>  
>
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.

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Michael Wu]

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

On Tuesday 29 August 2006 15:28, Mohamed Abbas wrote:
>  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

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

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Michael Wu]

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

On Tuesday 29 August 2006 15:50, Michael Wu wrote:
> On Tuesday 29 August 2006 15:28, Mohamed Abbas wrote:
> >  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

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

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Dan Williams]

On Tue, 2006-08-29 at 16:01 -0700, Michael Wu wrote:
> On Tuesday 29 August 2006 15:50, Michael Wu wrote:
> > On Tuesday 29 August 2006 15:28, Mohamed Abbas wrote:
> > >  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

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

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Michael Wu]

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

On Wednesday 30 August 2006 06:41, Dan Williams wrote:
> 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

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

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Jiri Benc]

On Mon, 28 Aug 2006 13:49:35 -0700, mabbas wrote:
> This patch indicate unassociated and radio off status
> in name field

NAK.

Fix SIOCGIWAP handler instead.

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Dan Williams]

On Thu, 2006-09-21 at 19:01 +0200, Jiri Benc wrote:
> On Mon, 28 Aug 2006 13:49:35 -0700, mabbas wrote:
> > 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

>  Jiri
> 

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[mabbas]

Dan Williams wrote:
> On Thu, 2006-09-21 at 19:01 +0200, Jiri Benc wrote:
>   
>> On Mon, 28 Aug 2006 13:49:35 -0700, mabbas wrote:
>>     
>>> 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
>
>   

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 

 

>>  Jiri
>>
>>     

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Dan Williams]

On Thu, 2006-09-21 at 12:47 -0700, mabbas wrote:
> Dan Williams wrote:
> > On Thu, 2006-09-21 at 19:01 +0200, Jiri Benc wrote:
> >   
> >> On Mon, 28 Aug 2006 13:49:35 -0700, mabbas wrote:
> >>     
> >>> 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
> >
> >   
> 
> 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

> Mohamed 
> 
>  
> 
> >>  Jiri
> >>
> >>     

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[mabbas]

Dan Williams wrote:
> On Thu, 2006-09-21 at 12:47 -0700, mabbas wrote:
>   
>> Dan Williams wrote:
>>     
>>> On Thu, 2006-09-21 at 19:01 +0200, Jiri Benc wrote:
>>>   
>>>       
>>>> On Mon, 28 Aug 2006 13:49:35 -0700, mabbas wrote:
>>>>     
>>>>         
>>>>> 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
>>>
>>>   
>>>       
>> 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
>   
I can fix the patch to do just that if we agree on that.
>   
>> Mohamed 
>>
>>  
>>
>>     
>>>>  Jiri
>>>>
>>>>     
>>>>         

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Jiri Benc]

On Thu, 21 Sep 2006 13:39:18 -0700, mabbas wrote:
> 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

-- 
Jiri Benc
SUSE Labs

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Jean Tourrilhes]

On Fri, Sep 22, 2006 at 12:38:44AM +0200, Jiri Benc wrote:
> On Thu, 21 Sep 2006 13:39:18 -0700, mabbas wrote:
> > 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.

> 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?

	Yes, dropping SIOCSIWAP (set) entirely, and keep only
SIOCGIWAP (get).

> 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.

>  Jiri

	Regards,

	Jean

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Jouni Malinen]

On Thu, Sep 21, 2006 at 03:55:14PM -0700, Jean Tourrilhes wrote:

> > 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.

> 	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.

> 	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.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Jean Tourrilhes]

On Thu, Sep 21, 2006 at 05:42:35PM -0700, Jouni Malinen wrote:
> On Thu, Sep 21, 2006 at 03:55:14PM -0700, Jean Tourrilhes wrote:
> 
> > > 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 ;-)

> > 	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.

	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.

> 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.

> > 	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 ;-)

> Jouni Malinen

	Have fun...

	Jean

[d80211 patch 1/1] setting bss freq and phymode using rx_status

[mabbas]

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

this 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.

[-- Attachment #2: d80211-iwlist-fix-freq-mode.patch --]
[-- Type: text/x-patch, Size: 561 bytes --]


Signed-off-by: Mohamed Abbas <mabbas@linux.intel.com>

diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index a933d92..ddbaf14 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -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

[Jiri Benc]

On Fri, 22 Sep 2006 15:29:42 -0700, mabbas wrote:
> -	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

-- 
Jiri Benc
SUSE Labs

Re: [d80211 patch 1/1] setting bss freq and phymode using rx_status

[mabbas]

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

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



[-- Attachment #2: d80211-iwlist-fix-freq-mode.patch --]
[-- Type: text/x-patch, Size: 808 bytes --]


Signed-off-by: Mohamed Abbas <mabbas@linux.intel.com>

diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index a933d92..a0746b9 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -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,

Re: [d80211 patch 1/1] setting bss freq and phymode using rx_status

[Jiri Benc]

On Mon, 25 Sep 2006 10:15:28 -0700, mabbas wrote:
> 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

Applied to my tree. Thanks for the patch!

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Johannes Berg]

On Thu, 2006-09-21 at 16:30 -0400, Dan Williams wrote:

> 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......)

> 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

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

[Dan Williams]

On Fri, 2006-09-22 at 10:32 +0200, Johannes Berg wrote:
> On Thu, 2006-09-21 at 16:30 -0400, Dan Williams wrote:
> 
> > 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......)
> 
> > 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?

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