This allows user-space monitoring of BSS parameters for the associated
station. This is useful for debugging and verifying that the paramaters
are as expected.
Paul Stewart (4):
nl80211: Add station info flags and intervals
cfg80211: Add station info to station struct
nl80211: Add bss info to station message
mac80211: Add bss info to that exported to station
include/linux/nl80211.h | 35 ++++++++++++++++++++++++++++++++++-
include/net/cfg80211.h | 34 ++++++++++++++++++++++++++++++++++
net/mac80211/cfg.c | 13 ++++++++++++-
net/wireless/nl80211.c | 21 ++++++++++++++++++++-
4 files changed, 100 insertions(+), 3 deletions(-)
--
1.7.3.1
On Tue, Mar 22, 2011 at 6:37 AM, Johannes Berg
<[email protected]> wrote:
> On Mon, 2011-03-21 at 14:32 -0700, Paul Stewart wrote:
>
>> Paul Stewart (4):
>> ? nl80211: Add station info flags and intervals
>> ? cfg80211: Add station info to station struct
>> ? nl80211: Add bss info to station message
>> ? mac80211: Add bss info to that exported to station
>
> Also, FWIW, I wouldn't mind if the first three patches were rolled up
> into one, or even all of them for such a fairly simple thing. Not saying
> you need to change it either though.
Thanks for all the good input. In the future I'll adjust my threshold
for patch breakup accordingly. :-)
--
Paul
On Tue, Mar 22, 2011 at 6:35 AM, Johannes Berg
<[email protected]> wrote:
> On Mon, 2011-03-21 at 14:32 -0700, Paul Stewart wrote:
>> This allows user-space monitoring of BSS parameters for the associated
>> station. ?This is useful for debugging and verifying that the paramaters
>> are as expected.
>
> Nice set of patches, but I'm wondering if the station info really is the
> best place to put this information? It's not really strictly information
> about the station, but rather about the BSS that it created. OTOH, I'm
> not sure if we need to distinguish?
I think it makes sense in a way. This is the station's view of the
BSS once it is associated. In fact, the primary use intended for this
is to verify that the station's view of the BSS parameters matches
that of the AP. After looking a little closer, it looks more for iw,
it should show up in the output of "iw link", as part of the output of
the hidden "iw link get_sta" command, but from the kernel perspective,
the API would be the same.
--
Paul
On Mon, 2011-03-21 at 14:32 -0700, Paul Stewart wrote:
> Paul Stewart (4):
> nl80211: Add station info flags and intervals
> cfg80211: Add station info to station struct
> nl80211: Add bss info to station message
> mac80211: Add bss info to that exported to station
Also, FWIW, I wouldn't mind if the first three patches were rolled up
into one, or even all of them for such a fairly simple thing. Not saying
you need to change it either though.
johannes
On Tue, 2011-03-22 at 07:33 -0700, Paul Stewart wrote:
> > Nice set of patches, but I'm wondering if the station info really is the
> > best place to put this information? It's not really strictly information
> > about the station, but rather about the BSS that it created. OTOH, I'm
> > not sure if we need to distinguish?
>
> I think it makes sense in a way. This is the station's view of the
> BSS once it is associated.
Yeah but it's tell you the view of the BSS as if it was its view of the
peer station. The BSS and the AP station aren't quite the same.
> In fact, the primary use intended for this
> is to verify that the station's view of the BSS parameters matches
> that of the AP.
Right, but the station info is the local station's view of the remote
station, not the local station's view on anything else directly.
> After looking a little closer, it looks more for iw,
> it should show up in the output of "iw link", as part of the output of
> the hidden "iw link get_sta" command, but from the kernel perspective,
> the API would be the same.
I think the problem is that we haven't really defined any "view of the
BSS while connected" at all. We have used the scan data, which is a more
generic view of the BSS that anyone could have (almost, think hidden
SSID), and we have the view of the station which contains counters such
as the number of packets which works because that's the only station we
ever communicate with (ignoring things like (T)DLS.)
But frankly I'm not sure what to do. We could introduce a concept of an
associated BSS, but it wouldn't make sense as a separate object because
there can be only one. That reminds me of database normalisation for the
sake of it. Or we could put it in the station, like you did. Another
alternative I could think of would be putting it into the interface
information, since it's really specific to that interface as well. But
then again stations are already per interface too, so there's no
correctness issue either way.
I'm not sure. From a "less confusion" POV I might very slightly prefer
putting it into the interface data (i.e. nl80211_send_iface) but that
will obviously complicate iw and other tools using it, and also you've
already implemented the other approach.
Anyone else want to voice their opinion?
johannes
On Mon, 2011-03-21 at 14:32 -0700, Paul Stewart wrote:
> This allows user-space monitoring of BSS parameters for the associated
> station. This is useful for debugging and verifying that the paramaters
> are as expected.
Nice set of patches, but I'm wondering if the station info really is the
best place to put this information? It's not really strictly information
about the station, but rather about the BSS that it created. OTOH, I'm
not sure if we need to distinguish?
johannes