ath9k: /proc/net/wireless always shows status of 0

ath9k: /proc/net/wireless always shows status of 0

[Ben Greear]

This is with today's wireless-testing (with no extra hacks)

[root@a230-ath9k ~]# cat /proc/net/wireless
Inter-| sta-|   Quality        |   Discarded packets               | Missed | WE
  face | tus | link level noise |  nwid  crypt   frag  retry   misc | beacon | 22
  wlan0: 0000   67.  -43.  -256        0      0      0      0      0        0

The interface is running WPA and is passing traffic, so I'd expect some sort of
useful status.  Is this a known issue?

[root@a230-ath9k ~]# iwconfig wlan0
wlan0     IEEE 802.11bgn  ESSID:"candela-n"
           Mode:Managed  Frequency:2.412 GHz  Access Point: 00:14:D1:C6:D2:54
           Bit Rate=117 Mb/s   Tx-Power=27 dBm
           Retry  long limit:7   RTS thr:off   Fragment thr:off
           Encryption key:off
           Power Management:off
           Link Quality=66/70  Signal level=-44 dBm
           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
           Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k: /proc/net/wireless always shows status of 0

[Ben Greear]

On 07/26/2010 12:49 PM, Ben Greear wrote:
> This is with today's wireless-testing (with no extra hacks)

Maybe a better question:  In 2.6.31 you could mount debugfs at /debug
and get the state with:
cat /debug/ieee80211/sta0/state

It seems in .34 there is only phy0 info in debugfs.  Or, am I
just not looking in the right place?

I don't mind hacking code, but I'd appreciate a pointer to the
right part of the code if anyone has suggestions.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k: /proc/net/wireless always shows status of 0

[Luis R. Rodriguez]

On Mon, Jul 26, 2010 at 3:00 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 07/26/2010 12:49 PM, Ben Greear wrote:
>>
>> This is with today's wireless-testing (with no extra hacks)
>
> Maybe a better question:  In 2.6.31 you could mount debugfs at /debug
> and get the state with:
> cat /debug/ieee80211/sta0/state

debugfs is not static API. In fact that's a big reason why we use it.
I considered defining a filesystem API for 802.11 using configfs but
our priority is to first get nl80211 feature-complete with respect to
wext, which we have completed now. But anyway, debugfs is *not* API
and you should not rely on it, if you want to define API consider
configfs.

> It seems in .34 there is only phy0 info in debugfs.  Or, am I
> just not looking in the right place?
>
> I don't mind hacking code, but I'd appreciate a pointer to the
> right part of the code if anyone has suggestions.

The other thing you pointed out with wext, you should stop using wext
and instead rely on nl80211. It is true that if you see something on
/proc/net/wireless/ that was there before but not there now it is a
regression and it should be addressed. Not sure where the status crap
comes from on wext.

  Luis

Re: ath9k: /proc/net/wireless always shows status of 0

[Ben Greear]

On 07/26/2010 03:54 PM, Luis R. Rodriguez wrote:
> On Mon, Jul 26, 2010 at 3:00 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 07/26/2010 12:49 PM, Ben Greear wrote:
>>>
>>> This is with today's wireless-testing (with no extra hacks)
>>
>> Maybe a better question:  In 2.6.31 you could mount debugfs at /debug
>> and get the state with:
>> cat /debug/ieee80211/sta0/state
>
> debugfs is not static API. In fact that's a big reason why we use it.
> I considered defining a filesystem API for 802.11 using configfs but
> our priority is to first get nl80211 feature-complete with respect to
> wext, which we have completed now. But anyway, debugfs is *not* API
> and you should not rely on it, if you want to define API consider
> configfs.
>
>> It seems in .34 there is only phy0 info in debugfs.  Or, am I
>> just not looking in the right place?
>>
>> I don't mind hacking code, but I'd appreciate a pointer to the
>> right part of the code if anyone has suggestions.
>
> The other thing you pointed out with wext, you should stop using wext
> and instead rely on nl80211. It is true that if you see something on
> /proc/net/wireless/ that was there before but not there now it is a
> regression and it should be addressed. Not sure where the status crap
> comes from on wext.

I really don't care what API I end up using..I am just looking for some
way to report to users whether the STA is in the various states that
used to be defined as something similar to:

enum ieee80211_state {
         IEEE80211_UNINITIALIZED = 0,
         IEEE80211_INITIALIZED,
         IEEE80211_ASSOCIATING,
         IEEE80211_ASSOCIATED,
         IEEE80211_AUTHENTICATING,
         IEEE80211_AUTHENTICATED,
         IEEE80211_SHUTDOWN
};

I have been reading the net/wireless code, but so far I don't see
any state machine type logic where this state might be kept.  Maybe
it would have to be inferred from something else?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k: /proc/net/wireless always shows status of 0

[Luis R. Rodriguez]

On Mon, Jul 26, 2010 at 4:17 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 07/26/2010 03:54 PM, Luis R. Rodriguez wrote:
>>
>> On Mon, Jul 26, 2010 at 3:00 PM, Ben Greear<greearb@candelatech.com>
>>  wrote:
>>>
>>> On 07/26/2010 12:49 PM, Ben Greear wrote:
>>>>
>>>> This is with today's wireless-testing (with no extra hacks)
>>>
>>> Maybe a better question:  In 2.6.31 you could mount debugfs at /debug
>>> and get the state with:
>>> cat /debug/ieee80211/sta0/state
>>
>> debugfs is not static API. In fact that's a big reason why we use it.
>> I considered defining a filesystem API for 802.11 using configfs but
>> our priority is to first get nl80211 feature-complete with respect to
>> wext, which we have completed now. But anyway, debugfs is *not* API
>> and you should not rely on it, if you want to define API consider
>> configfs.
>>
>>> It seems in .34 there is only phy0 info in debugfs.  Or, am I
>>> just not looking in the right place?
>>>
>>> I don't mind hacking code, but I'd appreciate a pointer to the
>>> right part of the code if anyone has suggestions.
>>
>> The other thing you pointed out with wext, you should stop using wext
>> and instead rely on nl80211. It is true that if you see something on
>> /proc/net/wireless/ that was there before but not there now it is a
>> regression and it should be addressed. Not sure where the status crap
>> comes from on wext.
>
> I really don't care what API I end up using..I am just looking for some
> way to report to users whether the STA is in the various states that
> used to be defined as something similar to:
>
> enum ieee80211_state {
>        IEEE80211_UNINITIALIZED = 0,
>        IEEE80211_INITIALIZED,
>        IEEE80211_ASSOCIATING,
>        IEEE80211_ASSOCIATED,
>        IEEE80211_AUTHENTICATING,
>        IEEE80211_AUTHENTICATED,
>        IEEE80211_SHUTDOWN
> };
>
> I have been reading the net/wireless code, but so far I don't see
> any state machine type logic where this state might be kept.  Maybe
> it would have to be inferred from something else?

You can use nl28011 and register for netlink multicast messages which
broadcast device state changes like the ones you mentioned. These come
in on iw via event.c, see print_event() and see the case statements
for NL80211_CMD_ASSOCIATE, NL80211_CMD_DEAUTHENTICATE,
NL80211_CMD_DISASSOCIATE, etc, you even get reason codes parsed for
you too.

  Luis

Re: ath9k: /proc/net/wireless always shows status of 0

[Ben Greear]

On 07/26/2010 04:30 PM, Luis R. Rodriguez wrote:
> On Mon, Jul 26, 2010 at 4:17 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 07/26/2010 03:54 PM, Luis R. Rodriguez wrote:
>>>
>>> On Mon, Jul 26, 2010 at 3:00 PM, Ben Greear<greearb@candelatech.com>
>>>   wrote:
>>>>
>>>> On 07/26/2010 12:49 PM, Ben Greear wrote:
>>>>>
>>>>> This is with today's wireless-testing (with no extra hacks)
>>>>
>>>> Maybe a better question:  In 2.6.31 you could mount debugfs at /debug
>>>> and get the state with:
>>>> cat /debug/ieee80211/sta0/state
>>>
>>> debugfs is not static API. In fact that's a big reason why we use it.
>>> I considered defining a filesystem API for 802.11 using configfs but
>>> our priority is to first get nl80211 feature-complete with respect to
>>> wext, which we have completed now. But anyway, debugfs is *not* API
>>> and you should not rely on it, if you want to define API consider
>>> configfs.
>>>
>>>> It seems in .34 there is only phy0 info in debugfs.  Or, am I
>>>> just not looking in the right place?
>>>>
>>>> I don't mind hacking code, but I'd appreciate a pointer to the
>>>> right part of the code if anyone has suggestions.
>>>
>>> The other thing you pointed out with wext, you should stop using wext
>>> and instead rely on nl80211. It is true that if you see something on
>>> /proc/net/wireless/ that was there before but not there now it is a
>>> regression and it should be addressed. Not sure where the status crap
>>> comes from on wext.
>>
>> I really don't care what API I end up using..I am just looking for some
>> way to report to users whether the STA is in the various states that
>> used to be defined as something similar to:
>>
>> enum ieee80211_state {
>>         IEEE80211_UNINITIALIZED = 0,
>>         IEEE80211_INITIALIZED,
>>         IEEE80211_ASSOCIATING,
>>         IEEE80211_ASSOCIATED,
>>         IEEE80211_AUTHENTICATING,
>>         IEEE80211_AUTHENTICATED,
>>         IEEE80211_SHUTDOWN
>> };
>>
>> I have been reading the net/wireless code, but so far I don't see
>> any state machine type logic where this state might be kept.  Maybe
>> it would have to be inferred from something else?
>
> You can use nl28011 and register for netlink multicast messages which
> broadcast device state changes like the ones you mentioned. These come
> in on iw via event.c, see print_event() and see the case statements
> for NL80211_CMD_ASSOCIATE, NL80211_CMD_DEAUTHENTICATE,
> NL80211_CMD_DISASSOCIATE, etc, you even get reason codes parsed for
> you too.

Ahhh, that is the kind of thing I'm looking for.  I'll check out that
code in detail tomorrow.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k: /proc/net/wireless always shows status of 0

[Luis R. Rodriguez]

On Mon, Jul 26, 2010 at 4:36 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 07/26/2010 04:30 PM, Luis R. Rodriguez wrote:
>>
>> On Mon, Jul 26, 2010 at 4:17 PM, Ben Greear<greearb@candelatech.com>
>>  wrote:
>>>
>>> On 07/26/2010 03:54 PM, Luis R. Rodriguez wrote:
>>>>
>>>> On Mon, Jul 26, 2010 at 3:00 PM, Ben Greear<greearb@candelatech.com>
>>>>  wrote:
>>>>>
>>>>> On 07/26/2010 12:49 PM, Ben Greear wrote:
>>>>>>
>>>>>> This is with today's wireless-testing (with no extra hacks)
>>>>>
>>>>> Maybe a better question:  In 2.6.31 you could mount debugfs at /debug
>>>>> and get the state with:
>>>>> cat /debug/ieee80211/sta0/state
>>>>
>>>> debugfs is not static API. In fact that's a big reason why we use it.
>>>> I considered defining a filesystem API for 802.11 using configfs but
>>>> our priority is to first get nl80211 feature-complete with respect to
>>>> wext, which we have completed now. But anyway, debugfs is *not* API
>>>> and you should not rely on it, if you want to define API consider
>>>> configfs.
>>>>
>>>>> It seems in .34 there is only phy0 info in debugfs.  Or, am I
>>>>> just not looking in the right place?
>>>>>
>>>>> I don't mind hacking code, but I'd appreciate a pointer to the
>>>>> right part of the code if anyone has suggestions.
>>>>
>>>> The other thing you pointed out with wext, you should stop using wext
>>>> and instead rely on nl80211. It is true that if you see something on
>>>> /proc/net/wireless/ that was there before but not there now it is a
>>>> regression and it should be addressed. Not sure where the status crap
>>>> comes from on wext.
>>>
>>> I really don't care what API I end up using..I am just looking for some
>>> way to report to users whether the STA is in the various states that
>>> used to be defined as something similar to:
>>>
>>> enum ieee80211_state {
>>>        IEEE80211_UNINITIALIZED = 0,
>>>        IEEE80211_INITIALIZED,
>>>        IEEE80211_ASSOCIATING,
>>>        IEEE80211_ASSOCIATED,
>>>        IEEE80211_AUTHENTICATING,
>>>        IEEE80211_AUTHENTICATED,
>>>        IEEE80211_SHUTDOWN
>>> };
>>>
>>> I have been reading the net/wireless code, but so far I don't see
>>> any state machine type logic where this state might be kept.  Maybe
>>> it would have to be inferred from something else?
>>
>> You can use nl28011 and register for netlink multicast messages which
>> broadcast device state changes like the ones you mentioned. These come
>> in on iw via event.c, see print_event() and see the case statements
>> for NL80211_CMD_ASSOCIATE, NL80211_CMD_DEAUTHENTICATE,
>> NL80211_CMD_DISASSOCIATE, etc, you even get reason codes parsed for
>> you too.
>
> Ahhh, that is the kind of thing I'm looking for.  I'll check out that
> code in detail tomorrow.

:) wext is dead

Re: ath9k: /proc/net/wireless always shows status of 0

[Johannes Berg]

On Mon, 2010-07-26 at 16:36 -0700, Ben Greear wrote:

> > You can use nl28011 and register for netlink multicast messages which
> > broadcast device state changes like the ones you mentioned. These come
> > in on iw via event.c, see print_event() and see the case statements
> > for NL80211_CMD_ASSOCIATE, NL80211_CMD_DEAUTHENTICATE,
> > NL80211_CMD_DISASSOCIATE, etc, you even get reason codes parsed for
> > you too.
> 
> Ahhh, that is the kind of thing I'm looking for.  I'll check out that
> code in detail tomorrow.

Keep in mind though that not all drivers can give you the difference
between AUTH and ASSOC, and will ONLY report "CONNECTED" events. This is
those drivers that do roaming and all that in firmware rather than in
mac80211. Therefore, generally speaking, you cannot get the states
you're after.

johannes

Re: ath9k: /proc/net/wireless always shows status of 0

[Luis R. Rodriguez]

On Mon, Jul 26, 2010 at 11:48 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2010-07-26 at 16:36 -0700, Ben Greear wrote:
>
>> > You can use nl28011 and register for netlink multicast messages which
>> > broadcast device state changes like the ones you mentioned. These come
>> > in on iw via event.c, see print_event() and see the case statements
>> > for NL80211_CMD_ASSOCIATE, NL80211_CMD_DEAUTHENTICATE,
>> > NL80211_CMD_DISASSOCIATE, etc, you even get reason codes parsed for
>> > you too.
>>
>> Ahhh, that is the kind of thing I'm looking for.  I'll check out that
>> code in detail tomorrow.
>
> Keep in mind though that not all drivers can give you the difference
> between AUTH and ASSOC, and will ONLY report "CONNECTED" events. This is
> those drivers that do roaming and all that in firmware rather than in
> mac80211. Therefore, generally speaking, you cannot get the states
> you're after.

FWIW I think he's on ath9k.

  Luis

Re: ath9k: /proc/net/wireless always shows status of 0

[Ben Greear]

On 07/26/2010 11:54 PM, Luis R. Rodriguez wrote:
> On Mon, Jul 26, 2010 at 11:48 PM, Johannes Berg
> <johannes@sipsolutions.net>  wrote:
>> On Mon, 2010-07-26 at 16:36 -0700, Ben Greear wrote:
>>
>>>> You can use nl28011 and register for netlink multicast messages which
>>>> broadcast device state changes like the ones you mentioned. These come
>>>> in on iw via event.c, see print_event() and see the case statements
>>>> for NL80211_CMD_ASSOCIATE, NL80211_CMD_DEAUTHENTICATE,
>>>> NL80211_CMD_DISASSOCIATE, etc, you even get reason codes parsed for
>>>> you too.
>>>
>>> Ahhh, that is the kind of thing I'm looking for.  I'll check out that
>>> code in detail tomorrow.
>>
>> Keep in mind though that not all drivers can give you the difference
>> between AUTH and ASSOC, and will ONLY report "CONNECTED" events. This is
>> those drivers that do roaming and all that in firmware rather than in
>> mac80211. Therefore, generally speaking, you cannot get the states
>> you're after.
>
> FWIW I think he's on ath9k.

My real goal is to support lots (128+ hopefully) of
virtual stations on ath5k and ath9k.  We had this working
for ath5k in .31 kernel, but too much has changed to make it
a straight-forward upgrade to .34.

As soon as I can get the management logic fixed up (ie, libnl
to listen to wireless events, etc), we should be able to start
on the virtualization work in earnest.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com