From: Karl Beldan <[email protected]>
ATM, specifying the frequency when connecting sends a void 'supported
rates' EID.
Signed-off-by: Karl Beldan <[email protected]>
---
net/wireless/sme.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 8bbeeb3..2ebc54b 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -80,9 +80,16 @@ static int cfg80211_conn_scan(struct wireless_dev *wdev)
if (!request)
return -ENOMEM;
- if (wdev->conn->params.channel)
+ if (wdev->conn->params.channel) {
+ enum ieee80211_band band = wdev->conn->params.channel->band;
+ struct ieee80211_supported_band *sband =
+ wdev->wiphy->bands[band];
+
+ if (!sband)
+ return -EINVAL;
request->channels[0] = wdev->conn->params.channel;
- else {
+ request->rates[band] = (1 << sband->n_bitrates) - 1;
+ } else {
int i = 0, j;
enum ieee80211_band band;
struct ieee80211_supported_band *bands;
--
2.0.1
On Thu, 2014-10-09 at 22:49 +0200, Karl Beldan wrote:
> > Either way - is it worth for 3.18/stable?
> >
> Your call.
I've seen no complaints, and you haven't indicated that you'd like to
see it in older kernels, so I've applied it to mac80211-next.
johannes
On Tue, 2014-10-07 at 11:42 +0200, Karl Beldan wrote:
> From: Karl Beldan <[email protected]>
>
> ATM, specifying the frequency when connecting sends a void 'supported
> rates' EID.
Seems like this should be a stable fix?
johannes
On Fri, Oct 10, 2014 at 05:11:31PM +0200, Johannes Berg wrote:
> On Fri, 2014-10-10 at 17:10 +0200, Johannes Berg wrote:
> > On Thu, 2014-10-09 at 22:49 +0200, Karl Beldan wrote:
> >
> > > > Either way - is it worth for 3.18/stable?
> > > >
> > > Your call.
> >
> > I've seen no complaints, and you haven't indicated that you'd like to
> > see it in older kernels, so I've applied it to mac80211-next.
>
> With a memory leak fix :)
>
Arf yes, thanks !
Karl
On Fri, 2014-10-10 at 17:10 +0200, Johannes Berg wrote:
> On Thu, 2014-10-09 at 22:49 +0200, Karl Beldan wrote:
>
> > > Either way - is it worth for 3.18/stable?
> > >
> > Your call.
>
> I've seen no complaints, and you haven't indicated that you'd like to
> see it in older kernels, so I've applied it to mac80211-next.
With a memory leak fix :)
johannes
On Thu, 2014-10-09 at 18:26 +0200, Karl Beldan wrote:
> > Then again, maybe you can make a bit more verbose commit log, and check
> > what broke it?
> >
> After a glimpse before leaving FWIU :
>
> - 6829c878 Jul 2009 - "cfg80211: emulate connect with auth/assoc"
> original code for 'cmd'
> ieee80211_build_preq_ies takes supported rates from sband->bitrates[].
> - 8dcb2003 Aug 2010 - "mac80211: Filter ProbeReq SuppRates based on TX
> rate mask"
> ieee80211_build_preq_ies takes a rate mask, hw_scan uses -1/sw_scan uses
> sdata->rc_rateidx_mask.
> - 34850ab2 Jul 2011 - "cfg80211: allow userspace to control supported
> rates in scan" add a "bitmap of rates to advertise" in the scan request.
> - 85a237fe Jul 2011 - "mac80211: implement scan supported rates"
> take the rate mask from 'cmd'
> - 3965ac00 Sep 2011 - "wireless: Fix rate mask for scan request"
> fix rate mask when 'cmd' has params.channel
>
>
> .. and rate mask remains unset when 'cmd' has params.channel
> So I guess it started showing after 85a237fe, but the original cmd never
> filled a rate mask which started existing only after 34850ab ..
Heh, so I guess this goes way back ... what does it actually affect
really though? only connections with iw, which should really not be done
that much? potentially wpa_s with wext, though I'm not even sure that
works?
Either way - is it worth for 3.18/stable?
johannes
On Thu, 2014-10-09 at 15:00 +0200, Karl Beldan wrote:
> On Thu, Oct 09, 2014 at 11:32:57AM +0200, Johannes Berg wrote:
> > On Tue, 2014-10-07 at 11:42 +0200, Karl Beldan wrote:
> > > From: Karl Beldan <[email protected]>
> > >
> > > ATM, specifying the frequency when connecting sends a void 'supported
> > > rates' EID.
> >
> > Seems like this should be a stable fix?
> >
> Indeed, I forgot to Cc stable.
Ok, I guess I can just add it.
Then again, maybe you can make a bit more verbose commit log, and check
what broke it?
johannes
On Thu, Oct 09, 2014 at 11:32:57AM +0200, Johannes Berg wrote:
> On Tue, 2014-10-07 at 11:42 +0200, Karl Beldan wrote:
> > From: Karl Beldan <[email protected]>
> >
> > ATM, specifying the frequency when connecting sends a void 'supported
> > rates' EID.
>
> Seems like this should be a stable fix?
>
Indeed, I forgot to Cc stable.
Karl
On Thu, Oct 09, 2014 at 03:26:02PM +0200, Johannes Berg wrote:
> On Thu, 2014-10-09 at 15:00 +0200, Karl Beldan wrote:
> > On Thu, Oct 09, 2014 at 11:32:57AM +0200, Johannes Berg wrote:
> > > On Tue, 2014-10-07 at 11:42 +0200, Karl Beldan wrote:
> > > > From: Karl Beldan <[email protected]>
> > > >
> > > > ATM, specifying the frequency when connecting sends a void 'supported
> > > > rates' EID.
> > >
> > > Seems like this should be a stable fix?
> > >
> > Indeed, I forgot to Cc stable.
>
> Ok, I guess I can just add it.
>
> Then again, maybe you can make a bit more verbose commit log, and check
> what broke it?
>
After a glimpse before leaving FWIU :
- 6829c878 Jul 2009 - "cfg80211: emulate connect with auth/assoc"
original code for 'cmd'
ieee80211_build_preq_ies takes supported rates from sband->bitrates[].
- 8dcb2003 Aug 2010 - "mac80211: Filter ProbeReq SuppRates based on TX
rate mask"
ieee80211_build_preq_ies takes a rate mask, hw_scan uses -1/sw_scan uses
sdata->rc_rateidx_mask.
- 34850ab2 Jul 2011 - "cfg80211: allow userspace to control supported
rates in scan" add a "bitmap of rates to advertise" in the scan request.
- 85a237fe Jul 2011 - "mac80211: implement scan supported rates"
take the rate mask from 'cmd'
- 3965ac00 Sep 2011 - "wireless: Fix rate mask for scan request"
fix rate mask when 'cmd' has params.channel
.. and rate mask remains unset when 'cmd' has params.channel
So I guess it started showing after 85a237fe, but the original cmd never
filled a rate mask which started existing only after 34850ab ..
Karl
On Thu, Oct 09, 2014 at 08:36:33PM +0200, Johannes Berg wrote:
> Heh, so I guess this goes way back ... what does it actually affect
> really though? only connections with iw, which should really not be done
> that much? potentially wpa_s with wext, though I'm not even sure that
> works?
>
For wext I wouldn't know.
> Either way - is it worth for 3.18/stable?
>
Your call.
Karl