Re: [PATCH] cfg80211: Handle bss expiry during connection

[Krishna Chaitanya]

On Fri, Apr 26, 2019 at 3:44 PM Johannes Berg  wrote:
>
> On Fri, 2019-04-26 at 15:24 +0530, chaitanya.m...@gmail.com wrote:
> > From: Chaitanya Tata 
> >
> > If the BSS is expired during connection, the connect result will
> > trigger a kernel warning. Ideally cfg80211 should hold the BSS
> > before the connection is attempted, but as the BSSID is not known
> > in case of auth/assoc MLME offload (connect op) it doesn't.
> >
> > For those drivers without the connect op cfg80211 holds down the
> > reference so it wil not be removed from list.
> >
> > Fix this by removing the warning and silently adding the BSS back to
> > the bss list which is return by the driver (with proper BSSID set).
> > The requirements for drivers are documented in the API's.
>
> This looks good, mostly :-)
>
> >   * @bssid: The BSSID of the AP (may be %NULL)
> >   * @bss: Entry of bss to which STA got connected to, can be obtained 
> > through
> > - *   cfg80211_get_bss() (may be %NULL). Only one parameter among @bssid and
> > - *   @bss needs to be specified.
> > + *   cfg80211_get_bss() (may be %NULL) but it is recommended to store the
> > + *   bss from the connect_request and hold a reference to it and return
> > + *   through this param to avoid warning if the bss is expired during the
> > + *   connection, esp. for those drivers implementing connect op.
> > + *   Only one parameter among @bssid and @bss needs to be specified.
>
> So while we're at it, we should probably amend the documentation to say
> that the reference to the BSS passes from the driver to cfg80211, right?
Yes
>
> > + /* bss is not NULL, so even though bss might have expired, the driver
> > +  * is still holding a reference to it.
> > +  */
>
> is -> was? It's our reference now.
Yes
>
> >   if (params->bss) {
> > - /* Make sure the bss entry provided by the driver is valid. */
> >   struct cfg80211_internal_bss *ibss = 
> > bss_from_pub(params->bss);
> >
> > - if (WARN_ON(list_empty(&ibss->list))) {
> > - cfg80211_put_bss(wdev->wiphy, params->bss);
>
> That's why we had a put_bss() here.
I will add a change to put bss after we update.
>
> > + /* Meanwhile if BSS is expired then add it back to the list as
> > +  * we have just connected with it.
> > +  */
> > + if (list_empty(&ibss->list))
> > + cfg80211_bss_update(rdev, ibss, ibss->pub.signal);
>
> But I think this adds *another* reference, which is wrong? We do need
> one reference (the original one the driver gave us) but not a second
> one?
This was assuming found will be false so refcnt will be reset and a fresh ref
is taken.
> Also, not sure the last argument (signal_valid) is right?
>
> Basically all that really just means that cfg80211_bss_update() is
> probably not the right function to call. It also updates the timestamp,
> which is not true, we haven't received updated information we just used
> it and thus held on to it.
>
> I think we should probably just instead of a "cfg80211_bss_relink()"
> function exposed, and that just does something like
>
> list_add_tail(&new->list, &rdev->bss_list);
> rdev->bss_entries++;
> rb_insert_bss(rdev, new);
>
> rdev->bss_generation++;
>
> though I'm not - off the top of my head - sure about
> cfg80211_combine_bsses() being needed or not.
>
> Maybe the copy we do in cfg80211_bss_update() isn't so bad, but then I'd
> probably expose it without the signal_valid part and signal/timestamp
> updates, and just copy the information raw there? However, the "if
> (found)" part should never be possible here, right? Actually, maybe it
> is, if we got a *new* entry in the meantime, but then we'd override the
> newer information with the older, which is kinda bad?

If we get new information (scan during connection) the bss would not have
expired right? so this code will not be triggered.

My initial stab was in similar lines, something like below: But as the
bss is expired
we need to udpate ts, signal and other fields anyway, so I went ahead
with full update.
+void cfg80211_add_expired_bss(struct cfg80211_registered_device *rdev,
+struct cfg80211_internal_bss *new)
+{
+   if (!new)
+   return;
+
+   spin_lock_bh(&rdev->bss_lock);
+   new->ts = jiffies
+   list_add_tail(&new->list, &rdev->bss_list);
+   rdev->bss_entries++;
+
+   rb_insert_bss(rdev, new);
+   rdev->bss_generation++;
+
+   bss_ref_get(rdev, new);
+
+   spin_unlock_bh(&rdev->bss_lock);
+}


> johannes
>


-- 
Thanks,
Regards,
Chaitanya T K.

Re: [PATCH] cfg80211: Handle bss expiry during connection

[Krishna Chaitanya]

On Fri, Apr 26, 2019 at 4:15 PM Johannes Berg  wrote:
>
> On Fri, 2019-04-26 at 16:05 +0530, Krishna Chaitanya wrote:
>
> > > > + /* Meanwhile if BSS is expired then add it back to the 
> > > > list as
> > > > +  * we have just connected with it.
> > > > +  */
> > > > + if (list_empty(&ibss->list))
> > > > + cfg80211_bss_update(rdev, ibss, ibss->pub.signal);
> > >
> > > But I think this adds *another* reference, which is wrong? We do need
> > > one reference (the original one the driver gave us) but not a second
> > > one?
> >
> > This was assuming found will be false so refcnt will be reset and a fresh 
> > ref
> > is taken.
>
> Yes, it actually adds a new entry entirely, not refs the old entry. But
> then you have a new entry returned from cfg80211_bss_update() with a
> reference, and leak that reference in the code as written.
>
> You probably need to unref the old one, and keep the new one to pass on
> to the next function etc.
>

Right, we should unref after the update.

> > > Maybe the copy we do in cfg80211_bss_update() isn't so bad, but then I'd
> > > probably expose it without the signal_valid part and signal/timestamp
> > > updates, and just copy the information raw there? However, the "if
> > > (found)" part should never be possible here, right? Actually, maybe it
> > > is, if we got a *new* entry in the meantime, but then we'd override the
> > > newer information with the older, which is kinda bad?
> >
> > If we get new information (scan during connection) the bss would not have
> > expired right? so this code will not be triggered.
>
> It could have expired and been re-added, no? Ok, I'll admit that's a
> stretch since the driver is busy connecting and not scanning, but I
> suppose it could happen with multiple VIFs etc?

Yes, it might be possible with multiple VIF's, when one VIF is connecting
and other VIF is scanning, it can find the connecting bssid in its scan results.

> > My initial stab was in similar lines, something like below: But as the
> > bss is expired
> > we need to udpate ts, signal and other fields anyway, so I went ahead
> > with full update.
>
> Why would we want to update ts, signal etc.? We just keep the old
> information, and then the entry will be held for the duration of the
> connection, presumably it'll get new updates while you're connected.

If we are holding it, then we will not be using ts anyway, so updating or
not should not matter. But as its old info better to leave it that way, and
update these fields only from scan results.

> > +void cfg80211_add_expired_bss(struct cfg80211_registered_device *rdev,
> > +struct cfg80211_internal_bss *new)
> > +{
> > +   if (!new)
> > +   return;
> > +
> > +   spin_lock_bh(&rdev->bss_lock);
> > +   new->ts = jiffies
> > +   list_add_tail(&new->list, &rdev->bss_list);
> > +   rdev->bss_entries++;
> > +
> > +   rb_insert_bss(rdev, new);
> > +   rdev->bss_generation++;
> > +
> > +   bss_ref_get(rdev, new);
> > +
> > +   spin_unlock_bh(&rdev->bss_lock);
> > +}
>
> Yeah, I was thinking along those lines too, except there's a bit of an
> issue with the hidden and non-transmitting lists?
Ok, let me think for a bit and will send you V2. Thanks for quick review.
> johannes
>


-- 
Thanks,
Regards,
Chaitanya T K.

Re: mac80211_hwsim (kernel 4.18+): wmediumd + 2.4Ghz

[Krishna Chaitanya]

On Thu, Aug 29, 2019 at 10:55 PM Johannes Berg
 wrote:
>
> On Thu, 2019-08-29 at 14:04 -0300, Ramon Fontes wrote:
> > Yes, that's what I (we?) expect.
> >
> > Yes, wmediumd has some log files, but they don't help me to identify
> > the reason of the problem. I also unsuccessfully tried to modified the
> > wmediumd code. Both wmediumd and mac80211_hwsim work fine up to kernel
> > version 4.17. The problem comes only from kernel 4.18. Since there are
> > some wmediumd related-codes in mac80211_hwsim, I was wondering whether
> > something wasn't missing in mac80211_hwsim (or even some needed
> > changes in wmediumd) that is causing such problem.
>
> Hmm, but are there? There's basically no change in hwsim between 4.17
> and 4.18, only a few error path cleanups/fixes and the SUPPORTS_PS
> change which also shouldn't matter for this?
>
> > Another weird thing
> > is the channel, since the channel is the same as defined in hostapd
> > and doesn't match 5Ghz channels.
>
> You mean the DS element? That's just from the frame itself.
Is this supposed to work at all? AFAICS, in hwsim channel matching
checks are only done in non-mediumd path (no_nl), and wmediumd also
doesn't have any checks? So, hostapd responds to all probe requests in all
channels. Am I missing something?

Re: mac80211_hwsim (kernel 4.18+): wmediumd + 2.4Ghz

[Krishna Chaitanya]

On Fri, Aug 30, 2019 at 1:02 PM Johannes Berg  wrote:
>
> On Fri, 2019-08-30 at 00:35 +0530, Krishna Chaitanya wrote:
> >
> > Is this supposed to work at all? AFAICS, in hwsim channel matching
> > checks are only done in non-mediumd path (no_nl), and wmediumd also
> > doesn't have any checks? So, hostapd responds to all probe requests in all
> > channels. Am I missing something?
>
> Hmm. Interesting observation, I wasn't aware of that.
>
> That certainly explains the situation though - on 2.4 GHz we'd prefer
> using the DS Element, and thus not use the scan result, while on 5 GHz
> we assume that the reported RX frequency is correct (there's no channel
> overlap).
>
> Still doesn't explain why it should work in 4.17 and not in 4.18, there
> aren't a lot of wifi changes there at all.
Yes the git log also doesn't show any changes in this area.
>
> I guess we should fix that in hwsim, anyone esle want to? :-)
I can give it a try to move the channel matching logic to common
code for both nl and no_nl.

Re: Linux wireless times out at Google Starbucks location

[Krishna Chaitanya]

On Wed, Sep 18, 2019 at 6:22 AM David Ho  wrote:
>
> On Tue, Sep 17, 2019 at 2:01 PM Dan Williams  wrote:
> >
> > If you're able to get the wpa_supplicant logs, that would be useful as
> > well.
> >
>
> I captured 2 minutes of log in /var/log/syslog, based on my crude
> judgment of where the connection request began.
>
> I appreciate if someone can update me on this issue; I hope my effort
> is not going to waste (I'm just an ML researcher trying to make Ubuntu
> work at my favorite coffee shop =)
Is this a new issue probably after some update? The only thing we can
see from the
kernel logs are that Auth/Assoc are getting timed-out, no info as to why?

You can probably try disabling the powersave using below command or
using `iw` utils.
sudo sed -i "s/wifi.powersave = 3/wifi.powersave = 2/g"
/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

Re: mac80211_hwsim (kernel 4.18+): wmediumd + 2.4Ghz

[Krishna Chaitanya]

On Sun, Sep 29, 2019 at 10:50 PM Ramon Fontes  wrote:
>
> > Still doesn't explain why it should work in 4.17 and not in 4.18, there
> > aren't a lot of wifi changes there at all.
>
> I just tested it with 4.15 and it didn't work. However, It works in
> 4.15 in other PC. At first these 2 PCs have the same packages with
> apparently the same version. The only thing I can highlight about the
> difference between them is that: (i) Ubuntu has been upgraded from
> 16.04 to 18.04 (it works fine up to 4.17) and (ii) Ubuntu 18.04 has
> been installed from scratch (it doesn't work at all - tested from
> 4.15).

Based on this info, looks like hostapd/wpa_s versions might be causing
the difference,
can you please confirm the versions on both?

Re: Linux wireless times out at Google Starbucks location

[Krishna Chaitanya]

On Thu, Oct 10, 2019 at 11:14 PM David Ho  wrote:
>
> Hi Dan, Steve,
>
> The issue was fixed by booting the latest 5.0.x upstream kernel !!!  I
> guess this has something to do with 5.0.0 and seems to have been fixed
> since then.   It appears I put too much faith in an LTS kernel...
>
> $ uname -a
> Linux mumble15 5.0.21-050021-generic #201906040731 SMP Tue Jun 4
> 07:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Did you also updated to corresponding linux-firmware, that might have
solved the problem?

Re: Undocumented Sleep Requirements for ieee80211_ops

[Krishna Chaitanya]

On Fri, Oct 30, 2015 at 3:07 PM, Johannes Berg
 wrote:
> On Thu, 2015-10-29 at 12:16 +0530, Krishna Chaitanya wrote:
>> Hi,
>>
>> From the documentation:(mac80211.h) For the ieee80211_ops
>> (un)assign_vif_chanctx, there is no mention of explicit sleep
>> requirements (allowed/disallwoed) for the callback.
>
> Same goes for drv_switch_vif_chanctx().
Yes.
>
>> From a quick glance at the code calling the OP, looks like we can
>> sleep (mutexes are used). So how should we handle such OPS? is it ok
>> to sleep in the callback?
>>
>
> You can sleep, and I'd appreciate if you sent a patch to add
> might_sleep() to the code and the appropriate documentation.
Sure, will send a patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] offchannel: Cancel the pending_action TX wait, before starting new one.

[Krishna Chaitanya]

On Mon, Nov 2, 2015 at 8:40 PM, Chaitanya T K  wrote:
> From: tkc 
>
> Before the tx_status is received for the action frame, if we
> get another request, we respond to that by freeing the memory
> for pending_action_tx, but we don't cancel the TX wait, so
> in the kernel the ROC will not be cancelled.
>
> Due to above issue, wpa_supplicant assumes that all pending
> RoC's are cancelled and proceeds with interface creation and
> connection, where as state in mac80211/driver will be roc_in_progress.
>
> This is leading to issues at driver level.
>
> Signed-off-by: Chaitanya T K 
> ---
> V2: Fix 2 from's.
> Remove the unnecessary braces.
> ---
>  wpa_supplicant/offchannel.c |   12 +++-
>  1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/wpa_supplicant/offchannel.c b/wpa_supplicant/offchannel.c
> index 6b3f83c..581c5f6 100644
> --- a/wpa_supplicant/offchannel.c
> +++ b/wpa_supplicant/offchannel.c
> @@ -253,15 +253,9 @@ int offchannel_send_action(struct wpa_supplicant *wpa_s, 
> unsigned int freq,
>
> wpa_s->pending_action_tx_status_cb = tx_cb;
>
> -   if (wpa_s->pending_action_tx) {
> -   wpa_printf(MSG_DEBUG, "Off-channel: Dropped pending Action "
> -  "frame TX to " MACSTR " (pending_action_tx=%p)",
> -  MAC2STR(wpa_s->pending_action_dst),
> -  wpa_s->pending_action_tx);

I think we should retain this print to identify if its a proper complete
or dropping pending. Anyways will wait for comments before sending V3.

.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] offchannel: Cancel the pending_action TX wait, before starting new one.

[Krishna Chaitanya]

On Mon, Nov 23, 2015 at 12:45 AM, Jouni Malinen  wrote:
>
> On Mon, Nov 02, 2015 at 08:40:28PM +0530, Chaitanya T K wrote:
> > From: tkc 
> >
> > Before the tx_status is received for the action frame, if we
> > get another request, we respond to that by freeing the memory
> > for pending_action_tx, but we don't cancel the TX wait, so
> > in the kernel the ROC will not be cancelled.
> >
> > Due to above issue, wpa_supplicant assumes that all pending
> > RoC's are cancelled and proceeds with interface creation and
> > connection, where as state in mac80211/driver will be roc_in_progress.
> >
> > This is leading to issues at driver level.
> >
> > Signed-off-by: Chaitanya T K 
> > ---
> > V2: Fix 2 from's.
> > Remove the unnecessary braces.
>
> I'm not sure I'd call that "From:" in the message body fixed (i.e., it
> should have been the second one, not the first one; alternatively, it
> would be fine to remove that From: line from the message body since the
> one in the message header has a value matching that SOB).
>
Sure will remove From.

>
> > diff --git a/wpa_supplicant/offchannel.c b/wpa_supplicant/offchannel.c
> > @@ -253,15 +253,9 @@ int offchannel_send_action(struct wpa_supplicant 
> > *wpa_s, unsigned int freq,
> >
> >   wpa_s->pending_action_tx_status_cb = tx_cb;
> >
> > - if (wpa_s->pending_action_tx) {
> > - wpa_printf(MSG_DEBUG, "Off-channel: Dropped pending Action "
> > -"frame TX to " MACSTR " (pending_action_tx=%p)",
> > -MAC2STR(wpa_s->pending_action_dst),
> > -wpa_s->pending_action_tx);
> > - wpa_hexdump_buf(MSG_MSGDUMP, "Pending TX frame",
> > - wpa_s->pending_action_tx);
> > - wpabuf_free(wpa_s->pending_action_tx);
> > - }
> > + if (wpa_s->pending_action_tx)
> > + offchannel_send_action_done(wpa_s);
>
> As noted in your reply to this, those debug prints should not be
> removed.
>
> As far as the change to offchannel_send_action_done() is concerned, I'm
> not sure it is the correct thing to do in all cases. Why would we cancel
> Action frame TX wait or remain-on-channel if the new frame is for the
> same channel?
>
I think wpa_supplicant can start the RoC, the FSM in mac80211
will check whether to start a new or continue the old depending on
the channel and time.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/9] mac80211: handle width changes from opmode notification IE in beacon

[Krishna Chaitanya]

On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
 wrote:
>
> From: Eyal Shapira 
>
> An AP can send an operating channel width change in a beacon
> opmode notification IE as long as there's a change in the nss as
> well (See 802.11ac-2013 section 10.41).
> So don't limit updating to nss only from an opmode notification IE.
>
> Signed-off-by: Eyal Shapira 
> Signed-off-by: Emmanuel Grumbach 
> ---
>  net/mac80211/cfg.c |  3 +--
>  net/mac80211/ieee80211_i.h |  4 ++--
>  net/mac80211/mlme.c|  2 +-
>  net/mac80211/rx.c  |  3 +--
>  net/mac80211/vht.c | 10 +++---
>  5 files changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index b9e2c2f..a90d875 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -1198,8 +1198,7 @@ static int sta_apply_parameters(struct ieee80211_local 
> *local,
>  * rc isn't initialized here yet, so ignore it
>  */
> __ieee80211_vht_handle_opmode(sdata, sta,
> - params->opmode_notif,
> - band, false);
> + params->opmode_notif, band);
> }
>
> if (ieee80211_vif_is_mesh(&sdata->vif))
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index 582ea86..747402d 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -1718,10 +1718,10 @@ void ieee80211_process_mu_groups(struct 
> ieee80211_sub_if_data *sdata,
>  struct ieee80211_mgmt *mgmt);
>  u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
>struct sta_info *sta, u8 opmode,
> -  enum ieee80211_band band, bool nss_only);
> + enum ieee80211_band band);
>  void ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
>  struct sta_info *sta, u8 opmode,
> -enum ieee80211_band band, bool nss_only);
> +enum ieee80211_band band);
>  void ieee80211_apply_vhtcap_overrides(struct ieee80211_sub_if_data *sdata,
>   struct ieee80211_sta_vht_cap *vht_cap);
>  void ieee80211_get_vht_mask_from_cap(__le16 vht_cap,
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 1e6b337..62c8e4f 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -3584,7 +3584,7 @@ static void ieee80211_rx_mgmt_beacon(struct 
> ieee80211_sub_if_data *sdata,
>
> if (sta && elems.opmode_notif)
> ieee80211_vht_handle_opmode(sdata, sta, *elems.opmode_notif,
> -   rx_status->band, true);
> +   rx_status->band);
> mutex_unlock(&local->sta_mtx);
>
> changed |= ieee80211_handle_pwr_constr(sdata, chan, mgmt,
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 901c72b..fe675d7 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -2738,8 +2738,7 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
> opmode = 
> mgmt->u.action.u.vht_opmode_notif.operating_mode;
>
> ieee80211_vht_handle_opmode(rx->sdata, rx->sta,
> -   opmode, status->band,
> -   false);
> +   opmode, status->band);
> goto handled;
> }
> case WLAN_VHT_ACTION_GROUPID_MGMT: {
> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
> index d2f2ff6..a02525a 100644
> --- a/net/mac80211/vht.c
> +++ b/net/mac80211/vht.c
> @@ -399,7 +399,7 @@ void ieee80211_sta_set_rx_nss(struct sta_info *sta)
>
>  u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
>   struct sta_info *sta, u8 opmode,
> - enum ieee80211_band band, bool nss_only)
> + enum ieee80211_band band)
>  {
> struct ieee80211_local *local = sdata->local;
> struct ieee80211_supported_band *sband;
> @@ -422,9 +422,6 @@ u32 __ieee80211_vht_handle_opmode(struct 
> ieee80211_sub_if_data *sdata,
> changed |= IEEE80211_RC_NSS_CHANGED;
> }
>
> -   if (nss_only)
> -   return changed;
> -
> switch (opmode & IEEE80211_OPMODE_NOTIF_CHANWIDTH_MASK) {
> case IEEE80211_OPMODE_NOTIF_CHANWIDTH_20MHZ:
> sta->cur_max_bandwidth = IEEE80211_STA_RX_BW_20;
> @@ -473,13 +470,12 @@ void ieee80211_process_mu_groups(struct 
> ieee80211_sub_if_data *sdata,
>
>  void ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
>  struct sta_info *st

Re: [PATCH 6/9] mac80211: handle width changes from opmode notification IE in beacon

[Krishna Chaitanya]

On Tue, Dec 8, 2015 at 9:12 PM, Johannes Berg  wrote:
> On Tue, 2015-12-08 at 21:08 +0530, Krishna Chaitanya wrote:
>>
>> >  void ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data
>> > *sdata,
>> >  struct sta_info *sta, u8 opmode,
>> > -enum ieee80211_band band, bool
>> > nss_only)
>> > +enum ieee80211_band band)
>> >  {
>> > struct ieee80211_local *local = sdata->local;
>> > struct ieee80211_supported_band *sband = local->hw.wiphy-
>> > >bands[band];
>> >
>> > -   u32 changed = __ieee80211_vht_handle_opmode(sdata, sta,
>> > opmode,
>> > -   band,
>> > nss_only);
>> > +   u32 changed = __ieee80211_vht_handle_opmode(sdata, sta,
>> > opmode, band);
>> >
>> > if (changed > 0)
>> > rate_control_rate_update(local, sband, sta,
>> > changed);
>>
>> Not related to current change.
>>
>> I was looking at this code a while ago and found that
>> rate_control_rate_update
>> doesn't update the rates from rx_nss, rather it updates from HT/VHT
>> capabilities.
>>
>> So how does the NSS update from OP MODE IE work?
>>
>
> Huh? You just quoted the code that does this?
MLME is updating the rx_nss.

> If the rate control algorithm doesn't look at sta->sta.rx_nss then
> that's their bug.

Yes, it looks like it. Only BW is handled, not the NSS change, and
without this patch OP MODE IE in beacon updates neither NSS nor BW.

For Action frame OP MODE IE, NSS will be updated.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/9] mac80211: handle width changes from opmode notification IE in beacon

[Krishna Chaitanya]

On Tue, Dec 8, 2015 at 9:23 PM, Johannes Berg  wrote:
> On Tue, 2015-12-08 at 21:17 +0530, Krishna Chaitanya wrote:
>>
>> > If the rate control algorithm doesn't look at sta->sta.rx_nss then
>> > that's their bug.
>>
>> Yes, it looks like it. Only BW is handled, not the NSS change, and
>> without this patch OP MODE IE in beacon updates neither NSS nor BW.
>>
>> For Action frame OP MODE IE, NSS will be updated.
Typo BW will be updated.
>
> I don't see how that would happen - they end up in exactly the same
> code path.

As nss_only is false, BW will be update in case of action frame.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

[Krishna Chaitanya]

On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
 wrote:
> index 7a76ce6..f4a5287 100644
> --- a/net/mac80211/ht.c
> +++ b/net/mac80211/ht.c
> @@ -230,6 +230,11 @@ bool ieee80211_ht_cap_ie_to_sta_ht_cap(struct 
> ieee80211_sub_if_data *sdata,
> /* set Rx highest rate */
> ht_cap.mcs.rx_highest = ht_cap_ie->mcs.rx_highest;
>
> +   if (ht_cap.cap & IEEE80211_HT_CAP_MAX_AMSDU)
> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_7935;
> +   else
> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_3839;
> +
>   apply:
> changed = memcmp(&sta->sta.ht_cap, &ht_cap, sizeof(ht_cap));
>
> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
> index 92c9843..d2f2ff6 100644
> --- a/net/mac80211/vht.c
> +++ b/net/mac80211/vht.c
> @@ -281,6 +281,24 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct 
> ieee80211_sub_if_data *sdata,
> }
>
> sta->sta.bandwidth = ieee80211_sta_cur_vht_bw(sta);
> +
> +   /* If HT IE reported 3839 bytes only, stay with that size. */
> +   if (sta->sta.max_amsdu_len == IEEE80211_MAX_MPDU_LEN_HT_3839)
> +   return;
> +
> +   switch (vht_cap->cap & IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_11454;
> +   break;
> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_7991;
> +   break;
> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895:
> +   default:
> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_3895;
> +   break;
> +   }
Ideally speaking shouldn't we use different variables for HT and VHT
and depending on
rate HT/VHT we should aggregate accordingly? of course that will be
tricky as we dont
have the rate control info at the time of aggregation. Standard is
clear about usage of
independent lengths depending on whether its an VHT/HT PPDU.

If we use the same variable to arrive at max_amsdu_len for both VHT
and HT, we might
end up sending 11454 sized MSDU in a HT rate.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/9] mac80211: handle width changes from opmode notification IE in beacon

[Krishna Chaitanya]

On Tue, Dec 8, 2015 at 9:28 PM, Johannes Berg  wrote:
> On Tue, 2015-12-08 at 21:25 +0530, Krishna Chaitanya wrote:
>> On Tue, Dec 8, 2015 at 9:23 PM, Johannes Berg > net> wrote:
>> > On Tue, 2015-12-08 at 21:17 +0530, Krishna Chaitanya wrote:
>> > >
>> > > > If the rate control algorithm doesn't look at sta->sta.rx_nss
>> > > > then
>> > > > that's their bug.
>> > >
>> > > Yes, it looks like it. Only BW is handled, not the NSS change,
>> > > and
>> > > without this patch OP MODE IE in beacon updates neither NSS nor
>> > > BW.
>> > >
>> > > For Action frame OP MODE IE, NSS will be updated.
>> Typo BW will be updated.
>
> Ok.
>
>> > I don't see how that would happen - they end up in exactly the same
>> > code path.
>>
>> As nss_only is false, BW will be update in case of action frame.
>
> Well, this patch removes that since the whole concept of nss_only was
> wrong.
>
> So basically you're just saying that minstrel should be fixed to look
> at rx_nss (and the relevant change bit, perhaps)...
>
Exactly :-).
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

[Krishna Chaitanya]

On Wed, Dec 9, 2015 at 12:52 AM, Grumbach, Emmanuel
 wrote:
>
>
> On 12/08/2015 09:11 PM, Krishna Chaitanya wrote:
>>
>>
>> On Dec 9, 2015 12:37 AM, "Grumbach, Emmanuel"
>> mailto:emmanuel.grumb...@intel.com>> wrote:
>> >
>> >
>> >
>> > On 12/08/2015 07:49 PM, Krishna Chaitanya wrote:
>> > >
>> > >
>> > > On Dec 8, 2015 10:13 PM, "Grumbach, Emmanuel"
>> > > mailto:emmanuel.grumb...@intel.com>
>> <mailto:emmanuel.grumb...@intel.com
>> <mailto:emmanuel.grumb...@intel.com>>> wrote:
>> > > >
>> > > >
>> > > >
>> > > > On 12/08/2015 06:35 PM, Krishna Chaitanya wrote:
>> > > > >
>> > > > >
>> > > > > On Dec 8, 2015 10:01 PM, "Grumbach, Emmanuel"
>> > > > > > <mailto:emmanuel.grumb...@intel.com>
>> <mailto:emmanuel.grumb...@intel.com <mailto:emmanuel.grumb...@intel.com>>
>> > > <mailto:emmanuel.grumb...@intel.com
>> <mailto:emmanuel.grumb...@intel.com>
>> > > <mailto:emmanuel.grumb...@intel.com
>> <mailto:emmanuel.grumb...@intel.com>>>> wrote:
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On 12/08/2015 06:03 PM, Krishna Chaitanya wrote:
>> > > > > > > On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
>> > > > > > > > <mailto:emmanuel.grumb...@intel.com>
>> > > <mailto:emmanuel.grumb...@intel.com
>> <mailto:emmanuel.grumb...@intel.com>>
>> > > <mailto:emmanuel.grumb...@intel.com
>> <mailto:emmanuel.grumb...@intel.com>
>> <mailto:emmanuel.grumb...@intel.com
>> <mailto:emmanuel.grumb...@intel.com>>>>
>> > > > > wrote:
>> > > > > > >> index 7a76ce6..f4a5287 100644
>> > > > > > >> --- a/net/mac80211/ht.c
>> > > > > > >> +++ b/net/mac80211/ht.c
>> > > > > > >> @@ -230,6 +230,11 @@ bool
>> > > > > ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_sub_if_data
>> *sdata,
>> > > > > > >> /* set Rx highest rate */
>> > > > > > >> ht_cap.mcs.rx_highest = ht_cap_ie->mcs.rx_highest;
>> > > > > > >>
>> > > > > > >> +   if (ht_cap.cap & IEEE80211_HT_CAP_MAX_AMSDU)
>> > > > > > >> +   sta->sta.max_amsdu_len =
>> > > > > IEEE80211_MAX_MPDU_LEN_HT_7935;
>> > > > > > >> +   else
>> > > > > > >> +   sta->sta.max_amsdu_len =
>> > > > > IEEE80211_MAX_MPDU_LEN_HT_3839;
>> > > > > > >> +
>> > > > > > >>   apply:
>> > > > > > >> changed = memcmp(&sta->sta.ht_cap, &ht_cap,
>> > > sizeof(ht_cap));
>> > > > > > >>
>> > > > > > >> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
>> > > > > > >> index 92c9843..d2f2ff6 100644
>> > > > > > >> --- a/net/mac80211/vht.c
>> > > > > > >> +++ b/net/mac80211/vht.c
>> > > > > > >> @@ -281,6 +281,24 @@
>> ieee80211_vht_cap_ie_to_sta_vht_cap(struct
>> > > > > ieee80211_sub_if_data *sdata,
>> > > > > > >> }
>> > > > > > >>
>> > > > > > >> sta->sta.bandwidth = ieee80211_sta_cur_vht_bw(sta);
>> > > > > > >> +
>> > > > > > >> +   /* If HT IE reported 3839 bytes only, stay with that
>> > > size. */
>> > > > > > >> +   if (sta->sta.max_amsdu_len ==
>> > > IEEE80211_MAX_MPDU_LEN_HT_3839)
>> > > > > > >> +   return;
>> > > > > > >> +
>> > > > > > >> +   switch (vht_cap->cap &
>> IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
>> > > > > > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
>> > > > > > >> +   sta->sta.max_amsdu_len =
>> > > > > IEEE80211_MAX_MPDU_LEN_VHT_11454;
>> > > > > > >> +   break;
>> > > 

Re: lost connectivity until "wpa_cli reassociate" is issued

[Krishna Chaitanya]

On Thu, Jan 7, 2016 at 9:59 PM, David Mosberger  wrote:
>
> Ben,
>
> On Thu, Jan 7, 2016 at 9:24 AM, Ben Greear  wrote:
> > On 01/07/2016 08:19 AM, David Mosberger wrote:
> >>
> >> We are seeing a curious issue where WLAN connectivity sometimes
> >> gets stuck until a "wpa_cli reassociate" command is issued.
> >>
> >> At the WPA level, everything appears to be working fine)
> >> (see thread starting at
> >> http://lists.infradead.org/pipermail/hostap/2016-January/034454.html).
> >
> > I don't remember seeing you mention the driver and NIC you are using.
> >
> > I think this is likely a driver bug, so please provide that info.
>
> Sure, we're using rtl8192cu.  I started out suspecting a driver bug as
> well, but since we're processing management frames during those
> "stuck" periods just fine (see
> debug output in
> http://lists.infradead.org/pipermail/hostap/2016-January/034459.html),
> I'm not so sure anymore.  Like mac80211, we have patched rtl8192cu
> driver with current
> bug-fixes already.

Management frames use a different queue (VO)
from the logs it looks like a data path issue in driver/FW.

The re-association might be clearing/triggering TX in driver
solving the issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: lost connectivity until "wpa_cli reassociate" is issued

[Krishna Chaitanya]

On Thu, Jan 7, 2016 at 10:17 PM, David Mosberger  wrote:
> On Thu, Jan 7, 2016 at 9:32 AM, Krishna Chaitanya
>  wrote:
>
>> Management frames use a different queue (VO)
>> from the logs it looks like a data path issue in driver/FW.
>>
>> The re-association might be clearing/triggering TX in driver
>> solving the issue.
>
> That sounds plausible to me.  Is there an easy way to see the queues?
> I haven't tried debugfs yet.
We can check pending packets per queue at mac80211, but first
we need some info from driver level. Someone familiar with RTL
should help.

cat /sys/kernel/debug/ieee80211/phy*/queues

If you see non-zero packets here (or) if the queue is stopped
that might explain this behavior...
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

mac80211_hwsim + iperf + netns

[Krishna Chaitanya]

Hi All,

I am trying to run some iperf tests using mac80211_hwsim b/w AP and STA.
Even after tweaking the routing table, the packets are still not going through
mac80211_hwsim instead they are just looping back.

After a quick search i found that we should use different network namespaces.
Can anyone tell me the exact procedure for this? I have found a procedure
in the below link, but i dont have the lxc-unshare for my embedded box.
Is there any alternate way for this.

https://github.com/bcopeland/wmediumd


-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211_hwsim + iperf + netns

[Krishna Chaitanya]

On Thu, Feb 4, 2016 at 5:02 PM, Michal Kazior  wrote:
> On 4 February 2016 at 12:22, Krishna Chaitanya  
> wrote:
>> Hi All,
>>
>> I am trying to run some iperf tests using mac80211_hwsim b/w AP and STA.
>> Even after tweaking the routing table, the packets are still not going 
>> through
>> mac80211_hwsim instead they are just looping back.
>>
>> After a quick search i found that we should use different network namespaces.
>> Can anyone tell me the exact procedure for this? I have found a procedure
>> in the below link, but i dont have the lxc-unshare for my embedded box.
>> Is there any alternate way for this.
>
> If you have a recent enough iproute2 package you can use:
Unfortunately i dont, will try to get the latest.
>  ip netns add ns1
>  ip netns exec ns1 bash # get the PID in the session and don't close it
>  iw phy phyX set netns $pid_of_that_shell
>  # you can close the bash now; phyX will remain in ns1
>
> Or you could try using ipv6 link-local addresses which will not
> require you to use namespaces at all.
Tried this but still not able to excite mac80211_hwsim TX path.
below are commands and config.

wlan0 Link encap:Ethernet  HWaddr 02:00:00:00:00:00
  inet addr:10.0.0.1  Bcast:10.255.255.255  Mask:255.0.0.0
  inet6 addr: fe80::ff:fe00:0/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:8 errors:0 dropped:1 overruns:0 frame:0
  TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:648 (648.0 B)  TX bytes:3680 (3.5 KiB)

wlan1 Link encap:Ethernet  HWaddr 02:00:00:00:01:00
  inet addr:20.0.0.1  Bcast:20.255.255.255  Mask:255.0.0.0
  inet6 addr: fe80::ff:fe00:100/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:3 errors:0 dropped:0 overruns:0 frame:0
  TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:126 (126.0 B)  TX bytes:808 (808.0 B)

iperf -s  -B fe80::ff:fe00:0 &
iperf -c fe80::ff:fe00:0 -B fe80::ff:fe00:100 -t 60 -i 1

Something wrong?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211_hwsim + iperf + netns

[Krishna Chaitanya]

On Thu, Feb 4, 2016 at 5:23 PM, Michal Kazior  wrote:
> On 4 February 2016 at 12:49, Krishna Chaitanya  
> wrote:
>> On Thu, Feb 4, 2016 at 5:02 PM, Michal Kazior  
>> wrote:
>>> On 4 February 2016 at 12:22, Krishna Chaitanya  
>>> wrote:
>>>> Hi All,
>>>>
>>>> I am trying to run some iperf tests using mac80211_hwsim b/w AP and STA.
>>>> Even after tweaking the routing table, the packets are still not going 
>>>> through
>>>> mac80211_hwsim instead they are just looping back.
>>>>
>>>> After a quick search i found that we should use different network 
>>>> namespaces.
>>>> Can anyone tell me the exact procedure for this? I have found a procedure
>>>> in the below link, but i dont have the lxc-unshare for my embedded box.
>>>> Is there any alternate way for this.
>>>
>>> If you have a recent enough iproute2 package you can use:
>> Unfortunately i dont, will try to get the latest.
>>>  ip netns add ns1
>>>  ip netns exec ns1 bash # get the PID in the session and don't close it
>>>  iw phy phyX set netns $pid_of_that_shell
>>>  # you can close the bash now; phyX will remain in ns1
>>>
>>> Or you could try using ipv6 link-local addresses which will not
>>> require you to use namespaces at all.
>> Tried this but still not able to excite mac80211_hwsim TX path.
>> below are commands and config.
>>
>> wlan0 Link encap:Ethernet  HWaddr 02:00:00:00:00:00
>>   inet addr:10.0.0.1  Bcast:10.255.255.255  Mask:255.0.0.0
>>   inet6 addr: fe80::ff:fe00:0/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:8 errors:0 dropped:1 overruns:0 frame:0
>>   TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:648 (648.0 B)  TX bytes:3680 (3.5 KiB)
>>
>> wlan1 Link encap:Ethernet  HWaddr 02:00:00:00:01:00
>>   inet addr:20.0.0.1  Bcast:20.255.255.255  Mask:255.0.0.0
>>   inet6 addr: fe80::ff:fe00:100/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:3 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:126 (126.0 B)  TX bytes:808 (808.0 B)
>>
>> iperf -s  -B fe80::ff:fe00:0 &
>> iperf -c fe80::ff:fe00:0 -B fe80::ff:fe00:100 -t 60 -i 1
>>
>> Something wrong?
>
> For link-local addresses you must specify interface you want to use them.
>
> Also, there's an iperf switch to understand ipv6 "-V".
>
>  iperf -V -i1 -s
>  iperf -V -i1 -c fe80::ff:fe00:0%wlan1
>  iperf -V -i1 -c fe80::ff:fe00:100%wlan0
>
Thanks a lot Michal. It worked like a charm.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211_hwsim + iperf + netns

[Krishna Chaitanya]

On Thu, Feb 4, 2016 at 5:49 PM, Johannes Berg  wrote:
> On Thu, 2016-02-04 at 12:32 +0100, Michal Kazior wrote:
>>
>>  ip netns add ns1
>>  ip netns exec ns1 bash # get the PID in the session and don't close
>> it
>>  iw phy phyX set netns $pid_of_that_shell
>>
>
> If you also have a recent enough iw version, you can use
>
> iw phy phyX set netns name ns1
>
My iw has this option, but it throws an error.
Does this command have any prerequisites?

# iw phy phy1 set netns name ns1
Invalid parameter: nsname(name)
Usage:  iw [options] phy  set netns {  | name  }

Put this wireless device into a different network namespace:
- change network namespace by process id
 - change network namespace by name from /var/run/netns
   or by absolute path (man ip-netns)


Options:
--debug enable netlink debugging
#
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211_hwsim + iperf + netns

[Krishna Chaitanya]

On Thu, Feb 4, 2016 at 6:05 PM, Johannes Berg  wrote:
> On Thu, 2016-02-04 at 17:58 +0530, Krishna Chaitanya wrote:
>> On Thu, Feb 4, 2016 at 5:49 PM, Johannes Berg > net> wrote:
>> > On Thu, 2016-02-04 at 12:32 +0100, Michal Kazior wrote:
>> > >
>> > >  ip netns add ns1
>> > >  ip netns exec ns1 bash # get the PID in the session and don't
>> > > close
>> > > it
>> > >  iw phy phyX set netns $pid_of_that_shell
>> > >
>> >
>> > If you also have a recent enough iw version, you can use
>> >
>> > iw phy phyX set netns name ns1
>> >
>> My iw has this option, but it throws an error.
>> Does this command have any prerequisites?
>>
>> # iw phy phy1 set netns name ns1
>> Invalid parameter: nsname(name)
>>
>
> This happens if the ns1 doesn't exist.
ok, so we need latest iprotue2 to create the
namespace?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211_hwsim + iperf + netns

[Krishna Chaitanya]

On Thu, Feb 4, 2016 at 5:57 PM, Krishna Chaitanya
 wrote:
> On Thu, Feb 4, 2016 at 5:23 PM, Michal Kazior  wrote:
>> On 4 February 2016 at 12:49, Krishna Chaitanya  
>> wrote:
>>> On Thu, Feb 4, 2016 at 5:02 PM, Michal Kazior  
>>> wrote:
>>>> On 4 February 2016 at 12:22, Krishna Chaitanya  
>>>> wrote:
>>>>> Hi All,
>>>>>
>>>>> I am trying to run some iperf tests using mac80211_hwsim b/w AP and STA.
>>>>> Even after tweaking the routing table, the packets are still not going 
>>>>> through
>>>>> mac80211_hwsim instead they are just looping back.
>>>>>
>>>>> After a quick search i found that we should use different network 
>>>>> namespaces.
>>>>> Can anyone tell me the exact procedure for this? I have found a procedure
>>>>> in the below link, but i dont have the lxc-unshare for my embedded box.
>>>>> Is there any alternate way for this.
>>>>
>>>> If you have a recent enough iproute2 package you can use:
>>> Unfortunately i dont, will try to get the latest.
>>>>  ip netns add ns1
>>>>  ip netns exec ns1 bash # get the PID in the session and don't close it
>>>>  iw phy phyX set netns $pid_of_that_shell
>>>>  # you can close the bash now; phyX will remain in ns1
>>>>
>>>> Or you could try using ipv6 link-local addresses which will not
>>>> require you to use namespaces at all.
>>> Tried this but still not able to excite mac80211_hwsim TX path.
>>> below are commands and config.
>>>
>>> wlan0 Link encap:Ethernet  HWaddr 02:00:00:00:00:00
>>>   inet addr:10.0.0.1  Bcast:10.255.255.255  Mask:255.0.0.0
>>>   inet6 addr: fe80::ff:fe00:0/64 Scope:Link
>>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>   RX packets:8 errors:0 dropped:1 overruns:0 frame:0
>>>   TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
>>>   collisions:0 txqueuelen:1000
>>>   RX bytes:648 (648.0 B)  TX bytes:3680 (3.5 KiB)
>>>
>>> wlan1 Link encap:Ethernet  HWaddr 02:00:00:00:01:00
>>>   inet addr:20.0.0.1  Bcast:20.255.255.255  Mask:255.0.0.0
>>>   inet6 addr: fe80::ff:fe00:100/64 Scope:Link
>>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>   RX packets:3 errors:0 dropped:0 overruns:0 frame:0
>>>   TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
>>>   collisions:0 txqueuelen:1000
>>>   RX bytes:126 (126.0 B)  TX bytes:808 (808.0 B)
>>>
>>> iperf -s  -B fe80::ff:fe00:0 &
>>> iperf -c fe80::ff:fe00:0 -B fe80::ff:fe00:100 -t 60 -i 1
>>>
>>> Something wrong?
>>
>> For link-local addresses you must specify interface you want to use them.
>>
>> Also, there's an iperf switch to understand ipv6 "-V".
>>
>>  iperf -V -i1 -s
>>  iperf -V -i1 -c fe80::ff:fe00:0%wlan1
>>  iperf -V -i1 -c fe80::ff:fe00:100%wlan0
>>
> Thanks a lot Michal. It worked like a charm.
Whenever i use the iperf -c, it starts a bi-directional stream,
How do i limit it to only for single direction?

#  iperf -V -i1 -c fe80::ff:fe00:0%wlan1

Client connecting to fe80::ff:fe00:0%wlan1, TCP port 5001
TCP window size: 43.8 KByte (default)

[  3] local fe80::ff:fe00:100 port 34808 connected with
fe80::ff:fe00:0 port 5001
[  5] local fe80::ff:fe00:0 port 5001 connected with fe80::ff:fe00:100
port 34808
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211_hwsim + iperf + netns

[Krishna Chaitanya]

On Thu, Feb 4, 2016 at 6:21 PM, Michal Kazior  wrote:
> On 4 February 2016 at 13:46, Krishna Chaitanya  
> wrote:
>> On Thu, Feb 4, 2016 at 5:57 PM, Krishna Chaitanya
>>  wrote:
>>> On Thu, Feb 4, 2016 at 5:23 PM, Michal Kazior  
>>> wrote:
>>>> On 4 February 2016 at 12:49, Krishna Chaitanya  
>>>> wrote:
>>>>> On Thu, Feb 4, 2016 at 5:02 PM, Michal Kazior  
>>>>> wrote:
>>>>>> On 4 February 2016 at 12:22, Krishna Chaitanya 
>>>>>>  wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I am trying to run some iperf tests using mac80211_hwsim b/w AP and STA.
>>>>>>> Even after tweaking the routing table, the packets are still not going 
>>>>>>> through
>>>>>>> mac80211_hwsim instead they are just looping back.
>>>>>>>
>>>>>>> After a quick search i found that we should use different network 
>>>>>>> namespaces.
>>>>>>> Can anyone tell me the exact procedure for this? I have found a 
>>>>>>> procedure
>>>>>>> in the below link, but i dont have the lxc-unshare for my embedded box.
>>>>>>> Is there any alternate way for this.
>>>>>>
>>>>>> If you have a recent enough iproute2 package you can use:
>>>>> Unfortunately i dont, will try to get the latest.
>>>>>>  ip netns add ns1
>>>>>>  ip netns exec ns1 bash # get the PID in the session and don't close it
>>>>>>  iw phy phyX set netns $pid_of_that_shell
>>>>>>  # you can close the bash now; phyX will remain in ns1
>>>>>>
>>>>>> Or you could try using ipv6 link-local addresses which will not
>>>>>> require you to use namespaces at all.
>>>>> Tried this but still not able to excite mac80211_hwsim TX path.
>>>>> below are commands and config.
>>>>>
>>>>> wlan0 Link encap:Ethernet  HWaddr 02:00:00:00:00:00
>>>>>   inet addr:10.0.0.1  Bcast:10.255.255.255  Mask:255.0.0.0
>>>>>   inet6 addr: fe80::ff:fe00:0/64 Scope:Link
>>>>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>>>   RX packets:8 errors:0 dropped:1 overruns:0 frame:0
>>>>>   TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
>>>>>   collisions:0 txqueuelen:1000
>>>>>   RX bytes:648 (648.0 B)  TX bytes:3680 (3.5 KiB)
>>>>>
>>>>> wlan1 Link encap:Ethernet  HWaddr 02:00:00:00:01:00
>>>>>   inet addr:20.0.0.1  Bcast:20.255.255.255  Mask:255.0.0.0
>>>>>   inet6 addr: fe80::ff:fe00:100/64 Scope:Link
>>>>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>>>   RX packets:3 errors:0 dropped:0 overruns:0 frame:0
>>>>>   TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
>>>>>   collisions:0 txqueuelen:1000
>>>>>   RX bytes:126 (126.0 B)  TX bytes:808 (808.0 B)
>>>>>
>>>>> iperf -s  -B fe80::ff:fe00:0 &
>>>>> iperf -c fe80::ff:fe00:0 -B fe80::ff:fe00:100 -t 60 -i 1
>>>>>
>>>>> Something wrong?
>>>>
>>>> For link-local addresses you must specify interface you want to use them.
>>>>
>>>> Also, there's an iperf switch to understand ipv6 "-V".
>>>>
>>>>  iperf -V -i1 -s
>>>>  iperf -V -i1 -c fe80::ff:fe00:0%wlan1
>>>>  iperf -V -i1 -c fe80::ff:fe00:100%wlan0
>>>>
>>> Thanks a lot Michal. It worked like a charm.
>> Whenever i use the iperf -c, it starts a bi-directional stream,
>> How do i limit it to only for single direction?
>>
>> #  iperf -V -i1 -c fe80::ff:fe00:0%wlan1
>> 
>> Client connecting to fe80::ff:fe00:0%wlan1, TCP port 5001
>> TCP window size: 43.8 KByte (default)
>> 
>> [  3] local fe80::ff:fe00:100 port 34808 connected with
>> fe80::ff:fe00:0 port 5001
>> [  5] local fe80::ff:fe00:0 port 5001 connected with fe80::ff:fe00:100
>> port 34808
>
> Hmm.. Are you perhaps running `iperf -V -i1 -s &` (i.e. in the
> background) with the same stdout as the client :-) You're probably
> just seeing both the server and the client saying a connection has
> established at their ends.
>
Ok i understand. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iw reg overwritten after connecting to AP

[Krishna Chaitanya]

On Thu, Jun 2, 2016 at 7:34 PM, Belisko Marek  wrote:
>
> Hello,
>
> I'm using kernel 4.1 with option CONFIG_CFG80211_INTERNAL_REGDB
> enabled. I have set one country in db.txt which during startup I set
> via 'iw reg set XX'. When connected to some AP which sends country
> code (e.g. SK) region is overwritten to 00 (in kernel log there is
> some timeout message - I suppose it's communication with crda daemon
> which I'm not using). Is there a way how to override this behavior (to
> keep my regulatory persistent). Many thanks.
>
You need to disable country_ie hints, you driver has to advertise
REGULATORY_WIPHY_SELF_MANAGED in the wiphy.regualtory_flags
to disable beacon and country_ie hints.

Which driver are you using?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iw reg overwritten after connecting to AP

[Krishna Chaitanya]

On Fri, Jun 3, 2016 at 2:02 AM, Belisko Marek  wrote:
>
> Hi Krishna,
>
> On Thu, Jun 2, 2016 at 10:21 PM, Krishna Chaitanya
>  wrote:
> > On Thu, Jun 2, 2016 at 7:34 PM, Belisko Marek  
> > wrote:
> >>
> >> Hello,
> >>
> >> I'm using kernel 4.1 with option CONFIG_CFG80211_INTERNAL_REGDB
> >> enabled. I have set one country in db.txt which during startup I set
> >> via 'iw reg set XX'. When connected to some AP which sends country
> >> code (e.g. SK) region is overwritten to 00 (in kernel log there is
> >> some timeout message - I suppose it's communication with crda daemon
> >> which I'm not using). Is there a way how to override this behavior (to
> >> keep my regulatory persistent). Many thanks.
> >>
> > You need to disable country_ie hints, you driver has to advertise
> > REGULATORY_WIPHY_SELF_MANAGED in the wiphy.regualtory_flags
> > to disable beacon and country_ie hints.
> I would like to keep beacon hinting (maybe disable only country_ie). I
> have same setup but with 3.9 kernel and regulatory isn't overwritten.
>
>
> > Which driver are you using?
> I'm using mwifiex driver

I am not familiar with this driver.

But looks like for any other country except for WORLD mode
 it is disabling both beacon and country_ie hints. But for any
other country these hints are enabled.

may be you can try the below patch (not based on 4.1 so you might have to port)
for your case disabling country_ie for all regulatory domains.

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 6db202f..cb95138 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -4072,8 +4072,9 @@ int mwifiex_register_cfg80211(struct
mwifiex_adapter *adapter)
wiphy->n_cipher_suites = ARRAY_SIZE(mwifiex_cipher_suites);

if (adapter->region_code)
-   wiphy->regulatory_flags |= REGULATORY_DISABLE_BEACON_HINTS |
-  REGULATORY_COUNTRY_IE_IGNORE;
+   wiphy->regulatory_flags |= REGULATORY_DISABLE_BEACON_HINTS;
+
+   wiphy->regulatory_flags |= REGULATORY_COUNTRY_IE_IGNORE;

ether_addr_copy(wiphy->perm_addr, adapter->perm_addr);
wiphy->signal_type = CFG80211_SIGNAL_TYPE_MBM;
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

STBC and LDPC for VHT

[Krishna Chaitanya]

Hi,

What is the background for disabling STBC and LDPC for
VHT rates? The below comment is cryptic :-).

/* TODO tx_flags for vht - ATM the RC API is not fine-grained enough */

Can we just enable these now?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: ensure info->control.vif is set for queued pkts.

[Krishna Chaitanya]

On Tue, Jun 28, 2016 at 8:20 PM, Ben Greear  wrote:
> On 06/28/2016 07:00 AM, Johannes Berg wrote:
>>
>> On Wed, 2016-06-15 at 11:24 -0700, gree...@candelatech.com wrote:
>>>
>>> From: Ben Greear 
>>>
>>> When driving ath10k with a modified pktgen, we see excessive amounts
>>> of these warnings:
>>>
>>> Jun  6 13:47:53 localhost kernel: WARNING: CPU: 1 PID: 1186 at
>>> /home/greearb/git/linux-4.4.dev.y/net/mac80211/tx.c:3
>>> 125 ieee80211_tx_pending+0x9d/0x19e [mac80211]()
>>> Jun  6 13:47:53 localhost kernel: Modules linked in:
>>> nf_conntrack_netlink nfnetlink nf_conntrack_ipv4 iptable_raw xt
>>> _CT nf_conntrack nf_defrag_ipv4 8021q garp mrp stp llc bnep bluetooth
>>> fuse macvlan wanlink(O) pktgen ip6table_filter
>>>   ip6_tables ebtable_nat ebtables snd_hda_codec_hdmi
>>> snd_hda_codec_realtek snd_hda_codec_generic ath10k_pci ath10k_co
>>> re snd_hda_intel snd_hda_codec coretemp hwmon intel_rapl iosf_mbi
>>> x86_pkg_temp_thermal intel_powerclamp kvm_intel sn
>>> d_hda_core ath iTCO_wdt iTCO_vendor_support mac80211 kvm cfg80211
>>> snd_hwdep e1000e snd_seq cdc_acm snd_seq_device sn
>>> d_pcm irqbypass serio_raw pcspkr ptp i2c_i801 pps_core snd_timer snd
>>> soundcore 8250_fintek shpchp fjes lpc_ich tpm_t
>>> is tpm uinput ipv6 i915 i2c_algo_bit drm_kms_helper drm i2c_core
>>> video [last unloaded: nfnetlink]
>>> Jun  6 13:47:53 localhost kernel: CPU: 1 PID: 1186 Comm: kpktgend_1
>>> Tainted: GW  O4.4.11+ #50
>>> Jun  6 13:47:53 localhost kernel: Hardware name: To be filled by
>>> O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.
>>> 5 06/07/2013
>>> Jun  6 13:47:53 localhost kernel:  88021e243e68
>>> 81340d35 
>>> Jun  6 13:47:53 localhost kernel: 0009 88021e243ea0
>>> 810e
>>> a46e a0b1cb0e
>>> Jun  6 13:47:53 localhost kernel: 880213a41600 880213a406e0
>>> 8800c8ac1700 88021e243ed8
>>> Jun  6 13:47:53 localhost kernel: Call Trace:
>>> Jun  6 13:47:53 localhost kernel:  []
>>> dump_stack+0x63/0x7f
>>> Jun  6 13:47:53 localhost kernel: []
>>> warn_slowpath_common+0x94/0xad
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> ieee80211_tx_pending+0x9d/0x19e [mac80211]
>>> Jun  6 13:47:53 localhost kernel: []
>>> warn_slowpath_null+0x15/0x17
>>> Jun  6 13:47:53 localhost kernel: []
>>> ieee80211_tx_pending+0x9d/0x19e [mac80211]
>>> Jun  6 13:47:53 localhost kernel: []
>>> tasklet_action+0xae/0xbf
>>> Jun  6 13:47:53 localhost kernel: []
>>> __do_softirq+0x109/0x26d
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> rcu_irq_exit+0x3d/0x40
>>> Jun  6 13:47:53 localhost kernel: []
>>> do_softirq_own_stack+0x1c/0x30
>>> Jun  6 13:47:53 localhost kernel:  []
>>> do_softirq+0x30/0x3b
>>> Jun  6 13:47:53 localhost kernel: []
>>> __local_bh_enable_ip+0x69/0x83
>>> Jun  6 13:47:53 localhost kernel: []
>>> pktgen_thread_worker+0x1399/0x1f26 [pktgen]
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> __schedule+0x3c1/0x585
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> finish_wait+0x5d/0x5d
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> pktgen_rem_all_ifs+0x6a/0x6a [pktgen]
>>> Jun  6 13:47:53 localhost kernel: []
>>> kthread+0xa0/0xa8
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> kthread_parkme+0x1f/0x1f
>>> Jun  6 13:47:53 localhost kernel: []
>>> ret_from_fork+0x3f/0x70
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> kthread_parkme+0x1f/0x1f
>>> Jun  6 13:47:53 localhost kernel: ---[ end trace a5fa4429cf1b918b ]
>>> ---
>>> Jun  6 13:47:53 localhost kernel: [ cut here ]---
>>> -
>>>
>>> I think the problem is that the logic that inserts the packet into
>>> the pending
>>> queue is not setting the vif in the skb info struct.  This patch
>>> appears to
>>> fix the problem.
>>>
>>> Signed-off-by: Ben Greear 
>>> ---
>>>
>>> Please review this well, looks like this code has been this way for a
>>> long time,
>>> and this was reproduced and tested on a kernel with a lot of wifi,
>>> pktgen, and ath10k
>>> patches.
>>
>>
>> I'm not convinced this patch is correct. control.vif is always set,
>> already since ieee80211_tx_prepare_skb(). It's *changed* to the looked-
>> up interface in case of monitor/VLAN within __ieee80211_tx()
>> and ieee80211_tx_frags(), but otherwise __ieee80211_tx() will leave it
>> completely identical:
>>
>> sdata = vif_to_sdata(info->control.vif);
>> [...]
>> switch (iftype) {
>> [...]
>> default:
>> vif = &sdata->vif;
>> }
>>
>> so the control.vif assignment is a no-op in almost all cases.
>
>
> So, maybe a WARN_ON would be appropriate at the place frames are enqueued
> in the backlog queue?  Since this patch did fix my problem, maybe that
> WARN_ON
> would show the path that allow frames with bad control.vif to be inserted?
>
> I had also found another problem with pktgen using the headroom wrong, so
> possibly
> that would have also fixed my problem..I'm not sure which patch I put in
> first.
>
 A while ago i have observed this issue when running iperf/pktgen
(don't rememb

Re: [PATCH] mac80211: minstrel: Enable STBC and LDPC for VHT Rates

[Krishna Chaitanya]

On Wed, Jun 29, 2016 at 1:41 PM, Karl Beldan  wrote:
> On Mon, Jun 27, 2016 at 9:53 AM, Chaitanya TK 
> wrote:
>>
>> From: Chaitanya T K 
>>
>> If peer support reception of STBC and LDPC, enable them for better
>> performance.
>>
>> Signed-off-by: Chaitanya TK 
>> ---
>>  include/linux/ieee80211.h  |1 +
>>  net/mac80211/rc80211_minstrel_ht.c |   25 +
>>  2 files changed, 18 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
>> index b118744..4d01130 100644
>> --- a/include/linux/ieee80211.h
>> +++ b/include/linux/ieee80211.h
>> @@ -1550,6 +1550,7 @@ struct ieee80211_vht_operation {
>>  #define IEEE80211_VHT_CAP_RXSTBC_3 0x0300
>>  #define IEEE80211_VHT_CAP_RXSTBC_4 0x0400
>>  #define IEEE80211_VHT_CAP_RXSTBC_MASK  0x0700
>> +#define IEEE80211_VHT_CAP_RXSTBC_SHIFT 8
>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE
>> 0x0800
>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE
>> 0x1000
>>  #define IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT  13
>> diff --git a/net/mac80211/rc80211_minstrel_ht.c
>> b/net/mac80211/rc80211_minstrel_ht.c
>> index 30fbabf..e2fcdea 100644
>> --- a/net/mac80211/rc80211_minstrel_ht.c
>> +++ b/net/mac80211/rc80211_minstrel_ht.c
>> @@ -1166,13 +1166,14 @@ minstrel_ht_update_caps(void *priv, struct
>> ieee80211_supported_band *sband,
>> struct minstrel_ht_sta_priv *msp = priv_sta;
>> struct minstrel_ht_sta *mi = &msp->ht;
>> struct ieee80211_mcs_info *mcs = &sta->ht_cap.mcs;
>> -   u16 sta_cap = sta->ht_cap.cap;
>> +   u16 ht_cap = sta->ht_cap.cap;
>> struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
>> int use_vht;
>> int n_supported = 0;
>> int ack_dur;
>> int stbc;
>> int i;
>> +   bool ldpc;
>>
>> /* fall back to the old minstrel for legacy stations */
>> if (!sta->ht_cap.ht_supported)
>> @@ -1210,16 +1211,24 @@ minstrel_ht_update_caps(void *priv, struct
>> ieee80211_supported_band *sband,
>> }
>> mi->sample_tries = 4;
>>
>> -   /* TODO tx_flags for vht - ATM the RC API is not fine-grained
>> enough */
>> if (!use_vht) {
>> -   stbc = (sta_cap & IEEE80211_HT_CAP_RX_STBC) >>
>> +   stbc = (ht_cap & IEEE80211_HT_CAP_RX_STBC) >>
>> IEEE80211_HT_CAP_RX_STBC_SHIFT;
>> -   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>>
>> -   if (sta_cap & IEEE80211_HT_CAP_LDPC_CODING)
>> -   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>> +   if (ht_cap & IEEE80211_HT_CAP_LDPC_CODING)
>> +   ldpc = true;
>> +   } else {
>> +   stbc = (vht_cap->cap & IEEE80211_VHT_CAP_RXSTBC_MASK) >>
>> +   IEEE80211_VHT_CAP_RXSTBC_SHIFT;
>> +
>> +   if (vht_cap->cap & IEEE80211_VHT_CAP_RXLDPC)
>> +   ldpc = true;
>> }
>>
>> +   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>> +   if (ldpc)
>> +   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>> +
>
>
> Here you are using ldpc uninitialized.
>
>
> As for the idea, ldpc and stbc support/enable in HT and VHT being
> independant and tx_flags being shared by all the info.rates, you cannot use
> it as you are trying to (e.g. you might end up asking lower layers to send
> stbc/vht with a hw only supporting stbc/ht or/and trying to send stbc/vht
> with inappropriate advertised vht caps).
The design in minstrel is it checks only for peers capabilities and it doesn't
check local hw capabilities (except for those in MCS_GROUPS), so minstrel
just informs the we can use STBC/LDPC, its HW's decision whether to
actually use or not.
> This stems from the STBC/LDPC CTL flags being a mac80211_tx_info_flags, this
> is what should be changed.
I understand the problem here, if all rates are same then its no problem.
But if some rates are HT and some are VHT, then we might end up in problem.

To solve this, we need to move this to mac80211_rate_control_flags so that
we can convey per rate info.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: minstrel: Enable STBC and LDPC for VHT Rates

[Krishna Chaitanya]

On Wed, Jun 29, 2016 at 1:50 PM, Krishna Chaitanya
 wrote:
> On Wed, Jun 29, 2016 at 1:41 PM, Karl Beldan  wrote:
>> On Mon, Jun 27, 2016 at 9:53 AM, Chaitanya TK 
>> wrote:
>>>
>>> From: Chaitanya T K 
>>>
>>> If peer support reception of STBC and LDPC, enable them for better
>>> performance.
>>>
>>> Signed-off-by: Chaitanya TK 
>>> ---
>>>  include/linux/ieee80211.h  |1 +
>>>  net/mac80211/rc80211_minstrel_ht.c |   25 +
>>>  2 files changed, 18 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
>>> index b118744..4d01130 100644
>>> --- a/include/linux/ieee80211.h
>>> +++ b/include/linux/ieee80211.h
>>> @@ -1550,6 +1550,7 @@ struct ieee80211_vht_operation {
>>>  #define IEEE80211_VHT_CAP_RXSTBC_3 0x0300
>>>  #define IEEE80211_VHT_CAP_RXSTBC_4 0x0400
>>>  #define IEEE80211_VHT_CAP_RXSTBC_MASK  0x0700
>>> +#define IEEE80211_VHT_CAP_RXSTBC_SHIFT 8
>>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE
>>> 0x0800
>>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE
>>> 0x1000
>>>  #define IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT  13
>>> diff --git a/net/mac80211/rc80211_minstrel_ht.c
>>> b/net/mac80211/rc80211_minstrel_ht.c
>>> index 30fbabf..e2fcdea 100644
>>> --- a/net/mac80211/rc80211_minstrel_ht.c
>>> +++ b/net/mac80211/rc80211_minstrel_ht.c
>>> @@ -1166,13 +1166,14 @@ minstrel_ht_update_caps(void *priv, struct
>>> ieee80211_supported_band *sband,
>>> struct minstrel_ht_sta_priv *msp = priv_sta;
>>> struct minstrel_ht_sta *mi = &msp->ht;
>>> struct ieee80211_mcs_info *mcs = &sta->ht_cap.mcs;
>>> -   u16 sta_cap = sta->ht_cap.cap;
>>> +   u16 ht_cap = sta->ht_cap.cap;
>>> struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
>>> int use_vht;
>>> int n_supported = 0;
>>> int ack_dur;
>>> int stbc;
>>> int i;
>>> +   bool ldpc;
>>>
>>> /* fall back to the old minstrel for legacy stations */
>>> if (!sta->ht_cap.ht_supported)
>>> @@ -1210,16 +1211,24 @@ minstrel_ht_update_caps(void *priv, struct
>>> ieee80211_supported_band *sband,
>>> }
>>> mi->sample_tries = 4;
>>>
>>> -   /* TODO tx_flags for vht - ATM the RC API is not fine-grained
>>> enough */
>>> if (!use_vht) {
>>> -   stbc = (sta_cap & IEEE80211_HT_CAP_RX_STBC) >>
>>> +   stbc = (ht_cap & IEEE80211_HT_CAP_RX_STBC) >>
>>> IEEE80211_HT_CAP_RX_STBC_SHIFT;
>>> -   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>>>
>>> -   if (sta_cap & IEEE80211_HT_CAP_LDPC_CODING)
>>> -   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>>> +   if (ht_cap & IEEE80211_HT_CAP_LDPC_CODING)
>>> +   ldpc = true;
>>> +   } else {
>>> +   stbc = (vht_cap->cap & IEEE80211_VHT_CAP_RXSTBC_MASK) >>
>>> +   IEEE80211_VHT_CAP_RXSTBC_SHIFT;
>>> +
>>> +   if (vht_cap->cap & IEEE80211_VHT_CAP_RXLDPC)
>>> +   ldpc = true;
>>> }
>>>
>>> +   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>>> +   if (ldpc)
>>> +   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>>> +
>>
>>
>> Here you are using ldpc uninitialized.
yeah, will fix it.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: minstrel: Enable STBC and LDPC for VHT Rates

[Krishna Chaitanya]

On Wed, Jun 29, 2016 at 1:52 PM, Krishna Chaitanya
 wrote:
> On Wed, Jun 29, 2016 at 1:50 PM, Krishna Chaitanya
>  wrote:
>> On Wed, Jun 29, 2016 at 1:41 PM, Karl Beldan  wrote:
>>> On Mon, Jun 27, 2016 at 9:53 AM, Chaitanya TK 
>>> wrote:
>>>>
>>>> From: Chaitanya T K 
>>>>
>>>> If peer support reception of STBC and LDPC, enable them for better
>>>> performance.
>>>>
>>>> Signed-off-by: Chaitanya TK 
>>>> ---
>>>>  include/linux/ieee80211.h  |1 +
>>>>  net/mac80211/rc80211_minstrel_ht.c |   25 +
>>>>  2 files changed, 18 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
>>>> index b118744..4d01130 100644
>>>> --- a/include/linux/ieee80211.h
>>>> +++ b/include/linux/ieee80211.h
>>>> @@ -1550,6 +1550,7 @@ struct ieee80211_vht_operation {
>>>>  #define IEEE80211_VHT_CAP_RXSTBC_3 0x0300
>>>>  #define IEEE80211_VHT_CAP_RXSTBC_4 0x0400
>>>>  #define IEEE80211_VHT_CAP_RXSTBC_MASK  0x0700
>>>> +#define IEEE80211_VHT_CAP_RXSTBC_SHIFT 8
>>>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE
>>>> 0x0800
>>>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE
>>>> 0x1000
>>>>  #define IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT  13
>>>> diff --git a/net/mac80211/rc80211_minstrel_ht.c
>>>> b/net/mac80211/rc80211_minstrel_ht.c
>>>> index 30fbabf..e2fcdea 100644
>>>> --- a/net/mac80211/rc80211_minstrel_ht.c
>>>> +++ b/net/mac80211/rc80211_minstrel_ht.c
>>>> @@ -1166,13 +1166,14 @@ minstrel_ht_update_caps(void *priv, struct
>>>> ieee80211_supported_band *sband,
>>>> struct minstrel_ht_sta_priv *msp = priv_sta;
>>>> struct minstrel_ht_sta *mi = &msp->ht;
>>>> struct ieee80211_mcs_info *mcs = &sta->ht_cap.mcs;
>>>> -   u16 sta_cap = sta->ht_cap.cap;
>>>> +   u16 ht_cap = sta->ht_cap.cap;
>>>> struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
>>>> int use_vht;
>>>> int n_supported = 0;
>>>> int ack_dur;
>>>> int stbc;
>>>> int i;
>>>> +   bool ldpc;
>>>>
>>>> /* fall back to the old minstrel for legacy stations */
>>>> if (!sta->ht_cap.ht_supported)
>>>> @@ -1210,16 +1211,24 @@ minstrel_ht_update_caps(void *priv, struct
>>>> ieee80211_supported_band *sband,
>>>> }
>>>> mi->sample_tries = 4;
>>>>
>>>> -   /* TODO tx_flags for vht - ATM the RC API is not fine-grained
>>>> enough */
>>>> if (!use_vht) {
>>>> -   stbc = (sta_cap & IEEE80211_HT_CAP_RX_STBC) >>
>>>> +   stbc = (ht_cap & IEEE80211_HT_CAP_RX_STBC) >>
>>>> IEEE80211_HT_CAP_RX_STBC_SHIFT;
>>>> -   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>>>>
>>>> -   if (sta_cap & IEEE80211_HT_CAP_LDPC_CODING)
>>>> -   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>>>> +   if (ht_cap & IEEE80211_HT_CAP_LDPC_CODING)
>>>> +   ldpc = true;
>>>> +   } else {
>>>> +   stbc = (vht_cap->cap & IEEE80211_VHT_CAP_RXSTBC_MASK) >>
>>>> +   IEEE80211_VHT_CAP_RXSTBC_SHIFT;
>>>> +
>>>> +   if (vht_cap->cap & IEEE80211_VHT_CAP_RXLDPC)
>>>> +   ldpc = true;
>>>> }
>>>>
>>>> +   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>>>> +   if (ldpc)
>>>> +   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>>>> +
>>>
>>>
>>> Here you are using ldpc uninitialized.
> yeah, will fix it.
Johannes,

How do you want to proceed? Do you want to
revert this patch and shall i send another patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: minstrel: Enable STBC and LDPC for VHT Rates

[Krishna Chaitanya]

On Wed, Jun 29, 2016 at 1:50 PM, Krishna Chaitanya
 wrote:
> On Wed, Jun 29, 2016 at 1:41 PM, Karl Beldan  wrote:
>> On Mon, Jun 27, 2016 at 9:53 AM, Chaitanya TK 
>> wrote:
>>>
>>> From: Chaitanya T K 
>>>
>>> If peer support reception of STBC and LDPC, enable them for better
>>> performance.
>>>
>>> Signed-off-by: Chaitanya TK 
>>> ---
>>>  include/linux/ieee80211.h  |1 +
>>>  net/mac80211/rc80211_minstrel_ht.c |   25 +
>>>  2 files changed, 18 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
>>> index b118744..4d01130 100644
>>> --- a/include/linux/ieee80211.h
>>> +++ b/include/linux/ieee80211.h
>>> @@ -1550,6 +1550,7 @@ struct ieee80211_vht_operation {
>>>  #define IEEE80211_VHT_CAP_RXSTBC_3 0x0300
>>>  #define IEEE80211_VHT_CAP_RXSTBC_4 0x0400
>>>  #define IEEE80211_VHT_CAP_RXSTBC_MASK  0x0700
>>> +#define IEEE80211_VHT_CAP_RXSTBC_SHIFT 8
>>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE
>>> 0x0800
>>>  #define IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE
>>> 0x1000
>>>  #define IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT  13
>>> diff --git a/net/mac80211/rc80211_minstrel_ht.c
>>> b/net/mac80211/rc80211_minstrel_ht.c
>>> index 30fbabf..e2fcdea 100644
>>> --- a/net/mac80211/rc80211_minstrel_ht.c
>>> +++ b/net/mac80211/rc80211_minstrel_ht.c
>>> @@ -1166,13 +1166,14 @@ minstrel_ht_update_caps(void *priv, struct
>>> ieee80211_supported_band *sband,
>>> struct minstrel_ht_sta_priv *msp = priv_sta;
>>> struct minstrel_ht_sta *mi = &msp->ht;
>>> struct ieee80211_mcs_info *mcs = &sta->ht_cap.mcs;
>>> -   u16 sta_cap = sta->ht_cap.cap;
>>> +   u16 ht_cap = sta->ht_cap.cap;
>>> struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
>>> int use_vht;
>>> int n_supported = 0;
>>> int ack_dur;
>>> int stbc;
>>> int i;
>>> +   bool ldpc;
>>>
>>> /* fall back to the old minstrel for legacy stations */
>>> if (!sta->ht_cap.ht_supported)
>>> @@ -1210,16 +1211,24 @@ minstrel_ht_update_caps(void *priv, struct
>>> ieee80211_supported_band *sband,
>>> }
>>> mi->sample_tries = 4;
>>>
>>> -   /* TODO tx_flags for vht - ATM the RC API is not fine-grained
>>> enough */
>>> if (!use_vht) {
>>> -   stbc = (sta_cap & IEEE80211_HT_CAP_RX_STBC) >>
>>> +   stbc = (ht_cap & IEEE80211_HT_CAP_RX_STBC) >>
>>> IEEE80211_HT_CAP_RX_STBC_SHIFT;
>>> -   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>>>
>>> -   if (sta_cap & IEEE80211_HT_CAP_LDPC_CODING)
>>> -   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>>> +   if (ht_cap & IEEE80211_HT_CAP_LDPC_CODING)
>>> +   ldpc = true;
>>> +   } else {
>>> +   stbc = (vht_cap->cap & IEEE80211_VHT_CAP_RXSTBC_MASK) >>
>>> +   IEEE80211_VHT_CAP_RXSTBC_SHIFT;
>>> +
>>> +   if (vht_cap->cap & IEEE80211_VHT_CAP_RXLDPC)
>>> +   ldpc = true;
>>> }
>>>
>>> +   mi->tx_flags |= stbc << IEEE80211_TX_CTL_STBC_SHIFT;
>>> +   if (ldpc)
>>> +   mi->tx_flags |= IEEE80211_TX_CTL_LDPC;
>>> +
>>
>>
>> Here you are using ldpc uninitialized.
>>
>>
>> As for the idea, ldpc and stbc support/enable in HT and VHT being
>> independant and tx_flags being shared by all the info.rates, you cannot use
>> it as you are trying to (e.g. you might end up asking lower layers to send
>> stbc/vht with a hw only supporting stbc/ht or/and trying to send stbc/vht
>> with inappropriate advertised vht caps).
> The design in minstrel is it checks only for peers capabilities and it doesn't
> check local hw capabilities (except for those in MCS_GROUPS), so minstrel
> just informs the we can use STBC/LDPC, its HW's decision whether to
> actually use or not.
>> This stems from the STBC/LDPC CTL flags being a mac80211_tx_info_flags, this
>> is what should be changed.
> I understand the problem here, if all rates are same then its no problem.
> But if some rates are HT and some are VHT, then we might end up in problem.
>
> To solve this, we need to move this to mac80211_rate_control_flags so that
> we can convey per rate info.
Karl/Johannes,

Any thoughts on this? This impacts all drivers, so it would be good
to finalize on design before submitting patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

Hi,

I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).

But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
no crash is observed but it still uses MCS9.

tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339

1) If i disable HW_RATE_CONTROL, will ath10k honor
the mac80211 rates?

2) Please find below the dmesg after the crash.

[ 3879.419737] ath10k_pci :01:00.0: device successfully recovered
[ 3941.919995] wlan0: deauthenticating from 74:d0:2b:41:e4:b4 by local
choice (Reason: 3=DEAUTH_LEAVING)
[ 3953.665725] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 3955.768675] wlan0: authenticate with 74:d0:2b:41:e4:b4
[ 3955.768688] ieee80211_determine_chantype:306 enter..: cwid:3 vht_cwid:3
[ 3955.776460] wlan0: send auth to 74:d0:2b:41:e4:b4 (try 1/3)
[ 3955.777014] wlan0: authenticated
[ 3955.781060] wlan0: associate with 74:d0:2b:41:e4:b4 (try 1/3)
[ 3955.782124] wlan0: RX AssocResp from 74:d0:2b:41:e4:b4 (capab=0x11
status=0 aid=2)
[ 3955.783147] wlan0: associated
[ 3955.783213] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 3959.053601] wlan0: deauthenticating from 74:d0:2b:41:e4:b4 by local
choice (Reason: 3=DEAUTH_LEAVING)
[ 3964.025669] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 3967.104520] wlan0: authenticate with 74:d0:2b:41:e4:b4
[ 3967.104533] ieee80211_determine_chantype:306 enter..: cwid:3 vht_cwid:3
[ 3967.112366] wlan0: send auth to 74:d0:2b:41:e4:b4 (try 1/3)
[ 3967.112905] wlan0: authenticated
[ 3967.113166] wlan0: associate with 74:d0:2b:41:e4:b4 (try 1/3)
[ 3967.114248] wlan0: RX AssocResp from 74:d0:2b:41:e4:b4 (capab=0x11
status=0 aid=2)
[ 3967.115327] wlan0: associated
[ 3967.115357] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 3976.110218] ath10k_pci :01:00.0: firmware crashed! (uuid
bfab5915-ae19-40b1-be67-544d909779ab)
[ 3976.110226] ath10k_pci :01:00.0: qca988x hw2.0 target
0x4100016c chip_id 0x043222ff sub :
[ 3976.110228] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1
tracing 1 dfs 0 testmode 0
[ 3976.110467] ath10k_pci :01:00.0: firmware ver 10.2.4.70.9-2 api
5 features no-p2p,raw-mode crc32 b8d50af5
[ 3976.110472] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
crc32 bebc7c08
[ 3976.110475] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
cal otp max-sta 128 raw 0 hwcrypto 1
[ 3976.112483] ath10k_pci :01:00.0: firmware register dump:
[ 3976.112485] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3
0x009BF931 0x00955B31
[ 3976.112487] ath10k_pci :01:00.0: [04]: 0x009BF931 0x00060530
0x0010 0x
[ 3976.112490] ath10k_pci :01:00.0: [08]: 0x0044D9B8 0xC001
0x 0x0005
[ 3976.112492] ath10k_pci :01:00.0: [12]: 0x0009 0x
0x00957F04 0x00957F12
[ 3976.112494] ath10k_pci :01:00.0: [16]: 0x00958080 0x0094085D
0x 0x
[ 3976.112496] ath10k_pci :01:00.0: [20]: 0x409BF931 0x0040AA44
0x00420854 0x00440198
[ 3976.112498] ath10k_pci :01:00.0: [24]: 0x809BF9A1 0x0040AAA4
0x00789518 0xC09BF931
[ 3976.112500] ath10k_pci :01:00.0: [28]: 0x809B837F 0x0040AAC4
0x0044D9B8 0x05DC
[ 3976.112502] ath10k_pci :01:00.0: [32]: 0x809B8555 0x0040AAE4
0x0044D9A0 0x0100
[ 3976.112504] ath10k_pci :01:00.0: [36]: 0x809A0DF5 0x0040AB04
0x0043EAA8 0x0040AD14
[ 3976.112506] ath10k_pci :01:00.0: [40]: 0x809896F9 0x0040AB24
0x0043EAA8 0x0040AD14
[ 3976.112508] ath10k_pci :01:00.0: [44]: 0x809B5ACC 0x0040AB44
0x009C575C 0x0043EAA8
[ 3976.112510] ath10k_pci :01:00.0: [48]: 0x809B1C74 0x0040ADA4
0x0040 0x00416DEC
[ 3976.112512] ath10k_pci :01:00.0: [52]: 0x809BFB39 0x0040ADE4
0x0040AE08 0x00411F80
[ 3976.112514] ath10k_pci :01:00.0: [56]: 0x809486FA 0x0040AE04
0x0001 0x
[ 3976.195917] ieee80211 phy0: Hardware restart was requested
[ 3977.561878] ath10k_pci :01:00.0: device successfully recovered
[ 8494.632109] ath10k_pci :01:00.0: firmware crashed! (uuid
5b6f2fe0-1a2c-4485-a7d5-64705ca051a2)
[ 8494.632116] ath10k_pci :01:00.0: qca988x hw2.0 target
0x4100016c chip_id 0x043222ff sub :
[ 8494.632119] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1
tracing 1 dfs 0 testmode 0
[ 8494.632357] ath10k_pci :01:00.0: firmware ver 10.2.4.70.9-2 api
5 features no-p2p,raw-mode crc32 b8d50af5
[ 8494.632362] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
crc32 bebc7c08
[ 8494.632364] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
cal otp max-sta 128 raw 0 hwcrypto 1
[ 8494.634373] ath10k_pci :01:00.0: firmware register dump:
[ 8494.634376] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3
0x009BF931 0x00955B31
[ 8494.634378] ath10k_pci :01:00.0: [04]: 0x009BF931 0x00060530
0x0010 0x
[ 8494.634380] ath10k_pci :01:00.0: [08]: 0x0044D9B8 0xC001
0x 0x0005
[ 8494.634382] ath10k_pci :01:00.0: [12]: 0x0009 0x
0x00957F04 

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Thu, Jul 7, 2016 at 10:19 PM, Krishna Chaitanya
 wrote:
> Hi,
>
> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>
> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
> no crash is observed but it still uses MCS9.
>
> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>
> 1) If i disable HW_RATE_CONTROL, will ath10k honor
> the mac80211 rates?
>
> 2) Please find below the dmesg after the crash.
>
> [ 3879.419737] ath10k_pci :01:00.0: device successfully recovered
> [ 3941.919995] wlan0: deauthenticating from 74:d0:2b:41:e4:b4 by local
> choice (Reason: 3=DEAUTH_LEAVING)
> [ 3953.665725] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 3955.768675] wlan0: authenticate with 74:d0:2b:41:e4:b4
> [ 3955.768688] ieee80211_determine_chantype:306 enter..: cwid:3 vht_cwid:3
> [ 3955.776460] wlan0: send auth to 74:d0:2b:41:e4:b4 (try 1/3)
> [ 3955.777014] wlan0: authenticated
> [ 3955.781060] wlan0: associate with 74:d0:2b:41:e4:b4 (try 1/3)
> [ 3955.782124] wlan0: RX AssocResp from 74:d0:2b:41:e4:b4 (capab=0x11
> status=0 aid=2)
> [ 3955.783147] wlan0: associated
> [ 3955.783213] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 3959.053601] wlan0: deauthenticating from 74:d0:2b:41:e4:b4 by local
> choice (Reason: 3=DEAUTH_LEAVING)
> [ 3964.025669] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 3967.104520] wlan0: authenticate with 74:d0:2b:41:e4:b4
> [ 3967.104533] ieee80211_determine_chantype:306 enter..: cwid:3 vht_cwid:3
> [ 3967.112366] wlan0: send auth to 74:d0:2b:41:e4:b4 (try 1/3)
> [ 3967.112905] wlan0: authenticated
> [ 3967.113166] wlan0: associate with 74:d0:2b:41:e4:b4 (try 1/3)
> [ 3967.114248] wlan0: RX AssocResp from 74:d0:2b:41:e4:b4 (capab=0x11
> status=0 aid=2)
> [ 3967.115327] wlan0: associated
> [ 3967.115357] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 3976.110218] ath10k_pci :01:00.0: firmware crashed! (uuid
> bfab5915-ae19-40b1-be67-544d909779ab)
> [ 3976.110226] ath10k_pci :01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043222ff sub :
> [ 3976.110228] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1
> tracing 1 dfs 0 testmode 0
> [ 3976.110467] ath10k_pci :01:00.0: firmware ver 10.2.4.70.9-2 api
> 5 features no-p2p,raw-mode crc32 b8d50af5
> [ 3976.110472] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [ 3976.110475] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
> cal otp max-sta 128 raw 0 hwcrypto 1
> [ 3976.112483] ath10k_pci :01:00.0: firmware register dump:
> [ 3976.112485] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3
> 0x009BF931 0x00955B31
> [ 3976.112487] ath10k_pci :01:00.0: [04]: 0x009BF931 0x00060530
> 0x0010 0x
> [ 3976.112490] ath10k_pci :01:00.0: [08]: 0x0044D9B8 0xC001
> 0x 0x0005
> [ 3976.112492] ath10k_pci :01:00.0: [12]: 0x0009 0x
> 0x00957F04 0x00957F12
> [ 3976.112494] ath10k_pci :01:00.0: [16]: 0x00958080 0x0094085D
> 0x 0x
> [ 3976.112496] ath10k_pci :01:00.0: [20]: 0x409BF931 0x0040AA44
> 0x00420854 0x00440198
> [ 3976.112498] ath10k_pci :01:00.0: [24]: 0x809BF9A1 0x0040AAA4
> 0x00789518 0xC09BF931
> [ 3976.112500] ath10k_pci :01:00.0: [28]: 0x809B837F 0x0040AAC4
> 0x0044D9B8 0x05DC
> [ 3976.112502] ath10k_pci :01:00.0: [32]: 0x809B8555 0x0040AAE4
> 0x0044D9A0 0x0100
> [ 3976.112504] ath10k_pci :01:00.0: [36]: 0x809A0DF5 0x0040AB04
> 0x0043EAA8 0x0040AD14
> [ 3976.112506] ath10k_pci :01:00.0: [40]: 0x809896F9 0x0040AB24
> 0x0043EAA8 0x0040AD14
> [ 3976.112508] ath10k_pci :01:00.0: [44]: 0x809B5ACC 0x0040AB44
> 0x009C575C 0x0043EAA8
> [ 3976.112510] ath10k_pci :01:00.0: [48]: 0x809B1C74 0x0040ADA4
> 0x0040 0x00416DEC
> [ 3976.112512] ath10k_pci :01:00.0: [52]: 0x809BFB39 0x0040ADE4
> 0x0040AE08 0x00411F80
> [ 3976.112514] ath10k_pci :01:00.0: [56]: 0x809486FA 0x0040AE04
> 0x0001 0x
> [ 3976.195917] ieee80211 phy0: Hardware restart was requested
> [ 3977.561878] ath10k_pci :01:00.0: device successfully recovered
> [ 8494.632109] ath10k_pci :01:00.0: firmware crashed! (uuid
> 5b6f2fe0-1a2c-4485-a7d5-64705ca051a2)
> [ 8494.632116] ath10k_pci :01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043222ff sub :
> [ 8494.632119] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1
> tracing 1 dfs 0 testmode 0
> [ 8494.632357] ath10k_pci :01:00.0: firmware ver 10.2.4.70.9-2 api
> 5 features no-p2p,raw-mode crc32 b8d50af5
> [ 8494.632362] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
> 

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
 wrote:
>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>>
>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>>> no crash is observed but it still uses MCS9.
>>>
>>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>>
>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>>> the mac80211 rates?
>>>
>>
> Thanks for reporting the issue. Could you please try with below change?
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 5e1cc8f4c43c..cfa7e01a6103 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
> return ret;
> }
>
> +   if (vif->type != NL80211_IFTYPE_ADHOC)
> +   peer_arg.peer_reassoc = reassoc;
> +
> ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
> if (ret) {
> ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev 
> %i: %d\n",

Thanks Raj, with this fix the rates are 0-7, if i disable then i am
seeing 0-9, so its
working.

But i am seeing a weird issues, the moment i give bitrates command,
ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
interface up/down
it doesn't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 8:57 PM, Krishna Chaitanya
 wrote:
> On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
>  wrote:
>> I think security failures are due to peer unmap & map upon reassoc. Can you 
>> please try below change?
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
>> b/drivers/net/wireless/ath/ath10k/mac.c
>> index 5e1cc8f4c43c..f7f04bb46fc8 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct 
>> *wk)
>> sta->addr, smps, err);
>> }
>>
>> -   if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
>> -   changed & IEEE80211_RC_NSS_CHANGED) {
>> +   if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
>> +   changed & IEEE80211_RC_NSS_CHANGED) &&
>> +   (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
>> ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp 
>> rates/nss\n",
>>sta->addr);
>
> Bottom posting please. I have tried your change i still see the same issue.
> Right after connecting i see that packets are encrypted but once it
> unset/set "bitrates" plain packets are seen in sniffer.
>
> BTW, i am not rebooting for each driver update, just re-inserting the module,
> do i need to do a reboot for each driver change?

After reboot i dont see the "unencrypted" packet issue, i will do
some more testing on limiting the rates, currently in my setup its
not reaching MCS9 so cannot verify now.

Thanks for the fixes and prompt reply.
  
>> From: Krishna Chaitanya 
>> Sent: Friday, July 8, 2016 5:26 PM
>> To: Manoharan, Rajkumar
>> Cc: linux-wireless; ath10k
>> Subject: Re: ath10k + iw set bitrates is causing FW crash
>>
>> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
>>  wrote:
>>>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>>>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>>>>
>>>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>>>>> no crash is observed but it still uses MCS9.
>>>>>
>>>>> tree: wireless-drivers-next: 
>>>>> commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>>>>
>>>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>>>>> the mac80211 rates?
>>>>>
>>>>
>>> Thanks for reporting the issue. Could you please try with below change?
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
>>> b/drivers/net/wireless/ath/ath10k/mac.c
>>> index 5e1cc8f4c43c..cfa7e01a6103 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
>>> return ret;
>>> }
>>>
>>> +   if (vif->type != NL80211_IFTYPE_ADHOC)
>>> +   peer_arg.peer_reassoc = reassoc;
>>> +
>>> ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
>>> if (ret) {
>>> ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev 
>>> %i: %d\n",
>>
>> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>> seeing 0-9, so its
>> working.
>>
>> But i am seeing a weird issues, the moment i give bitrates command,
>> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>> interface up/down
>> it doesn't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 9:07 PM, Krishna Chaitanya
 wrote:
> On Fri, Jul 8, 2016 at 8:57 PM, Krishna Chaitanya
>  wrote:
>> On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
>>  wrote:
>>> I think security failures are due to peer unmap & map upon reassoc. Can you 
>>> please try below change?
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
>>> b/drivers/net/wireless/ath/ath10k/mac.c
>>> index 5e1cc8f4c43c..f7f04bb46fc8 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct 
>>> work_struct *wk)
>>> sta->addr, smps, err);
>>> }
>>>
>>> -   if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
>>> -   changed & IEEE80211_RC_NSS_CHANGED) {
>>> +   if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
>>> +   changed & IEEE80211_RC_NSS_CHANGED) &&
>>> +   (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
>>> ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp 
>>> rates/nss\n",
>>>sta->addr);
>>
>> Bottom posting please. I have tried your change i still see the same issue.
>> Right after connecting i see that packets are encrypted but once it
>> unset/set "bitrates" plain packets are seen in sniffer.
>>
>> BTW, i am not rebooting for each driver update, just re-inserting the module,
>> do i need to do a reboot for each driver change?
>
> After reboot i dont see the "unencrypted" packet issue, i will do
> some more testing on limiting the rates, currently in my setup its
> not reaching MCS9 so cannot verify now.
>
> Thanks for the fixes and prompt reply.
>   
>>> From: Krishna Chaitanya 
>>> Sent: Friday, July 8, 2016 5:26 PM
>>> To: Manoharan, Rajkumar
>>> Cc: linux-wireless; ath10k
>>> Subject: Re: ath10k + iw set bitrates is causing FW crash
>>>
>>> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
>>>  wrote:
>>>>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>>>>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>>>>>
>>>>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>>>>>> no crash is observed but it still uses MCS9.
>>>>>>
>>>>>> tree: wireless-drivers-next: 
>>>>>> commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>>>>>
>>>>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>>>>>> the mac80211 rates?
>>>>>>
>>>>>
>>>> Thanks for reporting the issue. Could you please try with below change?
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
>>>> b/drivers/net/wireless/ath/ath10k/mac.c
>>>> index 5e1cc8f4c43c..cfa7e01a6103 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>>> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
>>>> return ret;
>>>> }
>>>>
>>>> +   if (vif->type != NL80211_IFTYPE_ADHOC)
>>>> +   peer_arg.peer_reassoc = reassoc;
>>>> +
>>>> ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
>>>> if (ret) {
>>>> ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev 
>>>> %i: %d\n",
>>>
>>> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>>> seeing 0-9, so its
>>> working.
>>>
>>> But i am seeing a weird issues, the moment i give bitrates command,
>>> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>>> interface up/down
>>> it doesn't work.

Also can you please tell me how to make ath10k use minstrel rc, its needed
for comparative purposes? Is disable HW_RATE_CONTROL enough or does
it need more changes?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 9:12 PM, Ben Greear  wrote:
> On 07/08/2016 08:39 AM, Krishna Chaitanya wrote:
>
>> Also can you please tell me how to make ath10k use minstrel rc, its needed
>> for comparative purposes? Is disable HW_RATE_CONTROL enough or does
>> it need more changes?
>
>
> It cannot be done.  You have to use whatever rate-ctrl is baked into the
> firmware.
Ok, its a good feature to have.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 9:17 PM, Ben Greear  wrote:
> On 07/08/2016 08:44 AM, Krishna Chaitanya wrote:
>>
>> On Fri, Jul 8, 2016 at 9:12 PM, Ben Greear 
>> wrote:
>>>
>>> On 07/08/2016 08:39 AM, Krishna Chaitanya wrote:
>>>
>>>> Also can you please tell me how to make ath10k use minstrel rc, its
>>>> needed
>>>> for comparative purposes? Is disable HW_RATE_CONTROL enough or does
>>>> it need more changes?
>>>
>>>
>>>
>>> It cannot be done.  You have to use whatever rate-ctrl is baked into the
>>> firmware.
>>
>> Ok, its a good feature to have.
>>
>
> It is unlikely to happen anytime soon.  It requires significant firmware
> modification (and driver too),
Ok, I understand.
>and probably you would have to add MU-MIMO
> support to minstrel if you wanted to support latest ath10k NICs.
It need not be a full pledged one, but 11ac MIMO works should be
good enough (for now).
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
 wrote:
> I think security failures are due to peer unmap & map upon reassoc. Can you 
> please try below change?
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 5e1cc8f4c43c..f7f04bb46fc8 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct 
> *wk)
> sta->addr, smps, err);
> }
>
> -   if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> -   changed & IEEE80211_RC_NSS_CHANGED) {
> +   if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> +   changed & IEEE80211_RC_NSS_CHANGED) &&
> +   (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
> ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp 
> rates/nss\n",
>sta->addr);

Bottom posting please. I have tried your change i still see the same issue.
Right after connecting i see that packets are encrypted but once it
unset/set "bitrates" plain packets are seen in sniffer.

BTW, i am not rebooting for each driver update, just re-inserting the module,
do i need to do a reboot for each driver change?
 
> From: Krishna Chaitanya 
> Sent: Friday, July 8, 2016 5:26 PM
> To: Manoharan, Rajkumar
> Cc: linux-wireless; ath10k
> Subject: Re: ath10k + iw set bitrates is causing FW crash
>
> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
>  wrote:
>>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>>>
>>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>>>> no crash is observed but it still uses MCS9.
>>>>
>>>> tree: wireless-drivers-next: 
>>>> commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>>>
>>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>>>> the mac80211 rates?
>>>>
>>>
>> Thanks for reporting the issue. Could you please try with below change?
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
>> b/drivers/net/wireless/ath/ath10k/mac.c
>> index 5e1cc8f4c43c..cfa7e01a6103 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
>> return ret;
>> }
>>
>> +   if (vif->type != NL80211_IFTYPE_ADHOC)
>> +   peer_arg.peer_reassoc = reassoc;
>> +
>> ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
>> if (ret) {
>> ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev 
>> %i: %d\n",
>
> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
> seeing 0-9, so its
> working.
>
> But i am seeing a weird issues, the moment i give bitrates command,
> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
> interface up/down
> it doesn't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 8, 2016 at 9:07 PM, Krishna Chaitanya
 wrote:
>
> On Fri, Jul 8, 2016 at 8:57 PM, Krishna Chaitanya
>  wrote:
> > On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
> >  wrote:
> >> I think security failures are due to peer unmap & map upon reassoc. Can 
> >> you please try below change?
> >>
> >> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> >> b/drivers/net/wireless/ath/ath10k/mac.c
> >> index 5e1cc8f4c43c..f7f04bb46fc8 100644
> >> --- a/drivers/net/wireless/ath/ath10k/mac.c
> >> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> >> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct 
> >> work_struct *wk)
> >> sta->addr, smps, err);
> >> }
> >>
> >> -   if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> >> -   changed & IEEE80211_RC_NSS_CHANGED) {
> >> +   if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> >> +   changed & IEEE80211_RC_NSS_CHANGED) &&
> >> +   (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
> >> ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp 
> >> rates/nss\n",
> >>sta->addr);
> >
> > Bottom posting please. I have tried your change i still see the same issue.
> > Right after connecting i see that packets are encrypted but once it
> > unset/set "bitrates" plain packets are seen in sniffer.
> >
> > BTW, i am not rebooting for each driver update, just re-inserting the 
> > module,
> > do i need to do a reboot for each driver change?
>
> After reboot i dont see the "unencrypted" packet issue, i will do
> some more testing on limiting the rates, currently in my setup its
> not reaching MCS9 so cannot verify now.
>
> Thanks for the fixes and prompt reply.



>
>   
> >> From: Krishna Chaitanya 
> >> Sent: Friday, July 8, 2016 5:26 PM
> >> To: Manoharan, Rajkumar
> >> Cc: linux-wireless; ath10k
> >> Subject: Re: ath10k + iw set bitrates is causing FW crash
> >>
> >> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
> >>  wrote:
> >>>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to 
> >>>>> use
> >>>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
> >>>>>
> >>>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
> >>>>> no crash is observed but it still uses MCS9.
> >>>>>
> >>>>> tree: wireless-drivers-next: 
> >>>>> commit#535633a5ba4ea2504fa6c33176633becf0e59339
> >>>>>
> >>>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
> >>>>> the mac80211 rates?
> >>>>>
> >>>>
> >>> Thanks for reporting the issue. Could you please try with below change?
> >>>
> >>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> >>> b/drivers/net/wireless/ath/ath10k/mac.c
> >>> index 5e1cc8f4c43c..cfa7e01a6103 100644
> >>> --- a/drivers/net/wireless/ath/ath10k/mac.c
> >>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> >>> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
> >>> return ret;
> >>> }
> >>>
> >>> +   if (vif->type != NL80211_IFTYPE_ADHOC)
> >>> +   peer_arg.peer_reassoc = reassoc;
> >>> +
> >>> ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
> >>> if (ret) {
> >>> ath10k_warn(ar, "failed to run peer assoc for STA %pM 
> >>> vdev %i: %d\n",
> >>
> >> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
> >> seeing 0-9, so its
> >> working.
> >>
> >> But i am seeing a weird issues, the moment i give bitrates command,
> >> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
> >> interface up/down
> >> it doesn't work.
Rajkumar,

I am still not able to make mcs9 work, so i have tried to change the Nss to 1
using iw, but that is not taking affect. This command is not taking effect.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 22, 2016 at 5:29 PM, Manoharan, Rajkumar
 wrote:
> [...]
>> >> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>> >> seeing 0-9, so its
>> >> working.
>> >>
>> >> But i am seeing a weird issues, the moment i give bitrates command,
>> >> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>> >> interface up/down
>> >> it doesn't work.
>>> After reboot i dont see the "unencrypted" packet issue, i will do
>>> some more testing on limiting the rates, currently in my setup its
>>> not reaching MCS9 so cannot verify now.
>> Rajkumar,
>>
>> I am still not able to make mcs9 work, so i have tried to change the Nss to 1
>> using iw, but that is not taking affect. This command is not taking effect.
>>
> you mean not able to fix VHT rates alone. am i right? By auto rate mode, is 
> firmware selecting
> mcs9? What is the command used for fixing vht rate?
Basically my requirement is to disable MCS8 and 9 for comparison.
to check whether ath10k honors the iw command, i used below
command. changing to 1SS, but i could see that it still transmits
using 2SS. Does your patch ignore these settings except for
adhoc mode?

iw set bitrates vht-mcs-5 1:0-7
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k + iw set bitrates is causing FW crash

[Krishna Chaitanya]

On Fri, Jul 22, 2016 at 7:02 PM, Ben Greear  wrote:
>
>
> On 07/22/2016 05:21 AM, Krishna Chaitanya wrote:
>>
>> On Fri, Jul 22, 2016 at 5:29 PM, Manoharan, Rajkumar
>>  wrote:
>>>
>>> [...]
>>>>>>
>>>>>> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>>>>>> seeing 0-9, so its
>>>>>> working.
>>>>>>
>>>>>> But i am seeing a weird issues, the moment i give bitrates command,
>>>>>> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>>>>>> interface up/down
>>>>>> it doesn't work.
>>>>>
>>>>> After reboot i dont see the "unencrypted" packet issue, i will do
>>>>> some more testing on limiting the rates, currently in my setup its
>>>>> not reaching MCS9 so cannot verify now.
>>>>
>>>> Rajkumar,
>>>>
>>>> I am still not able to make mcs9 work, so i have tried to change the Nss
>>>> to 1
>>>> using iw, but that is not taking affect. This command is not taking
>>>> effect.
>>>>
>>> you mean not able to fix VHT rates alone. am i right? By auto rate mode,
>>> is firmware selecting
>>> mcs9? What is the command used for fixing vht rate?
>>
>> Basically my requirement is to disable MCS8 and 9 for comparison.
>> to check whether ath10k honors the iw command, i used below
>> command. changing to 1SS, but i could see that it still transmits
>> using 2SS. Does your patch ignore these settings except for
>> adhoc mode?
>>
>> iw set bitrates vht-mcs-5 1:0-7
>
>
> You can set the number of spatial streams on the phy device.  Search around
> for a 'chainmask' configurable.
>
> In general, stock ath10k firmware does not have full support for setting
> arbitrary bitrates options.
Yes, i know that option but havent tried that. My intention was to limit to MCS7
so in order to verify that commands i tried to change nss.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFD] mac80211: Handling local operating class in (E)CSA

[Krishna Chaitanya]

Hi,

Some AP's use local operating class in (E)CSA IE's. Currently
mac80211 fails the parsing of those IE's and results in a
disconnection.

What is the best way to add support for local operating classes?

a) Maintaining a per country operating class table in cfg80211

b) Embed operating class info in regdb.txt (crda)

c) Remove the usage of band to calculate frequency? I dont know
of a generic formula to calculate this across bands. So not possible.


-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFD] mac80211: Handling local operating class in (E)CSA

[Krishna Chaitanya]

On Mon, Jul 25, 2016 at 12:56 PM, Krishna Chaitanya
 wrote:
>
> Hi,
>
> Some AP's use local operating class in (E)CSA IE's. Currently
> mac80211 fails the parsing of those IE's and results in a
> disconnection.
>
> What is the best way to add support for local operating classes?
>
> a) Maintaining a per country operating class table in cfg80211
>
> b) Embed operating class info in regdb.txt (crda)
>
> c) Remove the usage of band to calculate frequency? I dont know
> of a generic formula to calculate this across bands. So not possible.
>
Any ideas?

Undocumented Sleep Requirements for ieee80211_ops

[Krishna Chaitanya]

Hi,

>From the documentation:(mac80211.h) For the ieee80211_ops
(un)assign_vif_chanctx, there is no mention of explicit sleep
requirements (allowed/disallwoed) for the callback.

>From a quick glance at the code calling the OP, looks like we can
sleep (mutexes are used). So how should we handle such OPS? is it ok
to sleep in the callback?

We have a requirement where we need to wait for channel programming to
be done, before we allow data packets and it might take a while.

-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "iw": two small questions

[Krishna Chaitanya]

On Fri, Jan 30, 2015 at 2:44 AM, Stefano Cappa
 wrote:
>
> Hi, i've two question about iw
>
> 1) It's possibile that "iw phy phy0 info" said that i can use a particular 
> combination of interfaces in "Valid interface combinations" but on my device 
> i can't use this combination? If yes, the problem is with the driver of this 
> device?
>
> 2) How iw obtains the information to print "Valid interface combinations"? iw 
> asks this information to the driver/hardware/or something else ?
>

Yes, it talks to the device driver and gets the combinations which the
device supports.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Connection issues with BW Tracking in mac80211

[Krishna Chaitanya]

Hi Johannes,

The BW tracking feature in mac80211 is causing connection problems and
operating mode/bw problems when switching b/w modes and bw's in AP.

For Eg. Initially if AP is operating in VHT-80MHz, and then we changed
in to HT-40MHz, mac80211 cannot handle it because the VHT capability
is mismatched b/w stored info (ifmgd->flags).

I have tried your DISABLE_BW_TRACK patch, that helps making the
connection but it doesn't update the chipset causing issues.

Ideally we should be able to handle all the config changes right?


-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connection issues with BW Tracking in mac80211

[Krishna Chaitanya]

On Fri, Feb 20, 2015 at 1:00 AM, Krishna Chaitanya
 wrote:
> Hi Johannes,
>
> The BW tracking feature in mac80211 is causing connection problems and
> operating mode/bw problems when switching b/w modes and bw's in AP.
>
> For Eg. Initially if AP is operating in VHT-80MHz, and then we changed
> in to HT-40MHz, mac80211 cannot handle it because the VHT capability
> is mismatched b/w stored info (ifmgd->flags).
>
> I have tried your DISABLE_BW_TRACK patch, that helps making the
> connection but it doesn't update the chipset causing issues.
>
> Ideally we should be able to handle all the config changes right?

Before that i have a basic question? Should we reset our tracking after
the connection is lost, in my case above the connection was lost (Config
change in A triggers a reboot), still mac80211 is tracking the BW changes?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connection issues with BW Tracking in mac80211

[Krishna Chaitanya]

On Fri, Feb 20, 2015 at 2:58 AM, Krishna Chaitanya
 wrote:
> On Fri, Feb 20, 2015 at 1:00 AM, Krishna Chaitanya
>  wrote:
>> Hi Johannes,
>>
>> The BW tracking feature in mac80211 is causing connection problems and
>> operating mode/bw problems when switching b/w modes and bw's in AP.
>>
>> For Eg. Initially if AP is operating in VHT-80MHz, and then we changed
>> in to HT-40MHz, mac80211 cannot handle it because the VHT capability
>> is mismatched b/w stored info (ifmgd->flags).
>>
>> I have tried your DISABLE_BW_TRACK patch, that helps making the
>> connection but it doesn't update the chipset causing issues.
>>
>> Ideally we should be able to handle all the config changes right?
>
> Before that i have a basic question? Should we reset our tracking after
> the connection is lost, in my case above the connection was lost (Config
> change in A triggers a reboot), still mac80211 is tracking the BW changes?

Any ideas johannes? Currenlty we kind-of disabled BW tracking as a work around
for this issue.

mlme.c: Removed the capability checks.

if (!cfg80211_chandef_valid(&chandef)) {
sdata_info(sdata,
"AP %pM chandef invalid - disconnect\n",
ifmgd->bssid);
return -EINVAL;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connection issues with BW Tracking in mac80211

[Krishna Chaitanya]

On Tue, Feb 24, 2015 at 3:39 PM, Johannes Berg
 wrote:
> On Fri, 2015-02-20 at 02:58 +0530, Krishna Chaitanya wrote:
>
>> Before that i have a basic question? Should we reset our tracking after
>> the connection is lost, in my case above the connection was lost (Config
>> change in A triggers a reboot), still mac80211 is tracking the BW changes?
>
> Huh??
>
> So the AP does restart, but mac80211 tries to stay connected to it? That
> seems pretty unlikely. The tracking *shouldn't* have any knowledge of
> what happened before the association, but there could be bugs in the
> flags assignment I guess.
Let me explain the sequences.

STA (mac80211) connects to AP in VHT-80.
AP is reconfigured to 11n40 (stops beaconing for about 30secs and then
starts again).
STA loses connection (HW_CONN_TRACK), iee80211_connection_loss is called.
STA see's AP again and tries to connect, but due to BW tracking in
mac80211 it doesn't connect.

So i guess we are not resetting the tracking after losing connection.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connection issues with BW Tracking in mac80211

[Krishna Chaitanya]

On Tue, Feb 24, 2015 at 4:05 PM, Johannes Berg
 wrote:
> On Tue, 2015-02-24 at 15:58 +0530, Krishna Chaitanya wrote:
>
>> STA (mac80211) connects to AP in VHT-80.
>> AP is reconfigured to 11n40 (stops beaconing for about 30secs and then
>> starts again).
>> STA loses connection (HW_CONN_TRACK), iee80211_connection_loss is called.
>> STA see's AP again and tries to connect,
>
> But this goes through the supplicant, right? You actually get a full
> connection loss (which I certainly would expect after 30 seconds)

Our HW N/W lost event timeout is 5secs.

>>  but due to BW tracking in
>> mac80211 it doesn't connect.
>>
>> So i guess we are not resetting the tracking after losing connection.
>
> Right, some flag is not getting reset correctly I suppose. I thought we
> had pretty robust code for this, but I guess not.
>
> Easiest might be to print the flags and other state for during all
> connection attempts, and then compare
>  * VHT connection
>  * subsequent HT connection
>  * HT connection after reloading the driver
Sure Johannes, will share the info.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connection issues with BW Tracking in mac80211

[Krishna Chaitanya]

On Tue, Feb 24, 2015 at 4:59 PM, Krishna Chaitanya
 wrote:
> On Tue, Feb 24, 2015 at 4:05 PM, Johannes Berg
>  wrote:
>> On Tue, 2015-02-24 at 15:58 +0530, Krishna Chaitanya wrote:
>>
>>> STA (mac80211) connects to AP in VHT-80.
>>> AP is reconfigured to 11n40 (stops beaconing for about 30secs and then
>>> starts again).
>>> STA loses connection (HW_CONN_TRACK), iee80211_connection_loss is called.
>>> STA see's AP again and tries to connect,
>>
>> But this goes through the supplicant, right? You actually get a full
>> connection loss (which I certainly would expect after 30 seconds)
>
> Our HW N/W lost event timeout is 5secs.
>
>>>  but due to BW tracking in
>>> mac80211 it doesn't connect.
>>>
>>> So i guess we are not resetting the tracking after losing connection.
>>
>> Right, some flag is not getting reset correctly I suppose. I thought we
>> had pretty robust code for this, but I guess not.
>>
>> Easiest might be to print the flags and other state for during all
>> connection attempts, and then compare
>>  * VHT connection
>>  * subsequent HT connection
>>  * HT connection after reloading the driver
> Sure Johannes, will share the info.

Before you spend time on this, my tests are based on older kernel
3.10.36 but the code in this ares looks pretty much same (At least the
parts i am working on :-) ).  If time permits, i will try the same
with latest kernel as well.

Usecase1: When changing from VHT80-HT40. STA disconnect but sometimes
unable to reconnect.

I have digged in to this issue further, and observed that whenever
issue happens the bss_list in the scan list is having old information
even though we are doing a new scan as BSS info is not found (even
without new scan it should have been flushed). Sometimes "iw wlan0
scan dump" shows empty/VHT info (which is old).

So while doing assoc, cfg80211 gets the bss information from bss_list
(get_ie(VHT)) and passes to mac80211, which has VHT but AP's
beacon/probe resp/assoc resp is HT only causing the issue.

Event multiple connection attempts doesn't resolve this, but if i do
repeated scan's i am able to connect.

Use case2: When changing from HT40-VHT80, the connection goes through
but it still connected as HT40 (vht_ie from cfg80211 is returned
null).

Can you think of any reason why the bss_list is not updated cfg80211?
Note: iwconfig and wpa_supplicant both show same behavior.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connection issues with BW Tracking in mac80211

[Krishna Chaitanya]

On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg
 wrote:
> On Wed, 2015-02-25 at 02:03 +0530, Krishna Chaitanya wrote:
>
>> Use case2: When changing from HT40-VHT80, the connection goes through
>> but it still connected as HT40 (vht_ie from cfg80211 is returned
>> null).
>>
>> Can you think of any reason why the bss_list is not updated cfg80211?
>> Note: iwconfig and wpa_supplicant both show same behavior.
>
> Well, there's no flushing, only overwriting by new results - but if you
> previuosly got both beacons and probe responses each one will stick
> around until you get them again.
We do have the scan results expiry time of 30secs, that will flush the
results from bss_list right? Even the get_bss checks for aging?
>
> This sounds synthetic - just run your test scripts with "iw wlan0 scan
> flush".
Sure, will give it a shot.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: disable u-APSD queues by default

[Krishna Chaitanya]

On Tue, Mar 3, 2015 at 2:46 PM, Johannes Berg  wrote:
> On Tue, 2015-02-10 at 12:48 +0100, Michal Kazior wrote:
>> Some APs experience problems when working with
>> U-APSD. Decreasing the probability of that
>> happening by using legacy mode for all ACs but VO
>> isn't enough.
>>
>> Cisco 4410N originally forced us to enable VO by
>> default only because it treated non-VO ACs as
>> legacy.
>>
>> However some APs (notably Netgear R7000) silently
>> reclassify packets to different ACs. Since u-APSD
>> ACs require trigger frames for frame retrieval
>> clients would never see some frames (e.g. ARP
>> responses) or would fetch them accidentally after
>> a long time.
>
> This makes me a little sad, but I've applied this and even added a Cc
> stable tag due to the interoperability issues.
>
Mixed mode (uapsd + legacy) is not really the optimal
configuration, where we expect STA to send trigger frames periodically
to retrieve the DL packets (especially very first packet).

But still if we want power save, i suggest going for
All u-apsd (0xF), so that AP will inform us by setting the TIM bit
and we can retrieve the first frame.
(We have this patch internally and it works well).
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: disable u-APSD queues by default

[Krishna Chaitanya]

On Tue, Mar 3, 2015 at 3:06 PM, Johannes Berg  wrote:
>
>> >> Cisco 4410N originally forced us to enable VO by
>> >> default only because it treated non-VO ACs as
>> >> legacy.
>
>> Mixed mode (uapsd + legacy) is not really the optimal
>> configuration, where we expect STA to send trigger frames periodically
>> to retrieve the DL packets (especially very first packet).
>>
>> But still if we want power save, i suggest going for
>> All u-apsd (0xF), so that AP will inform us by setting the TIM bit
>> and we can retrieve the first frame.
>> (We have this patch internally and it works well).
>
> Except where it doesn't work, like on the Cisco 4410N - see above.
But for that single AP, we are forced to lose efficient power savings
unless user configured explicitly.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: disable u-APSD queues by default

[Krishna Chaitanya]

On Tue, Mar 3, 2015 at 3:58 PM, Michal Kazior  wrote:
> On 3 March 2015 at 11:15, Krishna Chaitanya  wrote:
>> On Tue, Mar 3, 2015 at 3:06 PM, Johannes Berg  
>> wrote:
>>>
>>>> >> Cisco 4410N originally forced us to enable VO by
>>>> >> default only because it treated non-VO ACs as
>>>> >> legacy.
>>>
>>>> Mixed mode (uapsd + legacy) is not really the optimal
>>>> configuration, where we expect STA to send trigger frames periodically
>>>> to retrieve the DL packets (especially very first packet).
>>>>
>>>> But still if we want power save, i suggest going for
>>>> All u-apsd (0xF), so that AP will inform us by setting the TIM bit
>>>> and we can retrieve the first frame.
>>>> (We have this patch internally and it works well).
>>>
>>> Except where it doesn't work, like on the Cisco 4410N - see above.
>> But for that single AP, we are forced to lose efficient power savings
>> unless user configured explicitly.
>
> Correct me if I'm wrong, but u-APSD makes sense only if you have
> userspace apps aware of it. I don't know any. VoIP traffic uses and it
> works just because it generate bi-directional traffic in most cases so
> you have implicit trigger frames generated when you Tx, but that's
> probably as far as the practical use-case goes, no? You'd still need
> netfilter rules to reclassify your traffic anyway, wouldn't you? If
> you mainly wait for data you need to send trigger frames periodically
> and only userspace app knows what Rx latency is tolerated (that's why
> relying on driver/firmware auto-trigger generation doesn't cut it).

Agree u-apsd is tightly coupled with the applications. But there is a
provision in the protocol to deliver buffered frames without sending
explicit triggers (which is quite waste of tx power). So it might be
optimized for each application, but overall it will not break the
functionality for those drivers who do not send explicit triggers
frames periodically.

Even for unidirectional protocol has a provison when All AC's are
delivery enabled, it will still set the TIM bit, so using which we can
start sending trigger frames. So either disabling/enabling u-apsd is
fine aslong as we do it for all AC's together, mixed mode is useless.

>
> Anyway I don't think you can ask users to do the opposite (i.e.
> disable u-APSD if they experience problems with APs). Wi-Fi should
> Just Work. Joys of IOT..
May be in utopia ;-).




-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connection issues with BW Tracking in mac80211

[Krishna Chaitanya]

On Wed, Mar 11, 2015 at 9:50 PM, Johannes Berg
 wrote:
> On Wed, 2015-03-11 at 21:45 +0530, Krishna Chaitanya wrote:
>
>> I did some experiments on this and found the root cause.
>>
>> We are using 5GHz in WORLD Mode, so only passive scan is allowed.
>> So when connecting the very first time, the mac80211 MLME sees that
>> there are no probe_resp ies (only beacon_ies are present) and it sends
>> a directed probe and updates the probe_resp ies. (and also the "ies").
>>
>> But when config is changed and we get disconnected, beacon_ies are updated
>> with the new config, but the probe_resp ies are not.
>> cfg80211_bss_update assigns
>> probe_resp ies to "ies' and mac80211 updates its bss info based on the
>> probe_resp
>> ies which have old config causing the issue.
>>
>> Solution:
>>
>> 1) Make the directed probe mandatory.
>> 2) As you suggested maintain timestamps for probe_resp_ies and beacon_ies
>> and use the latest.
>>
>> Any takes?
>
> What's the operational problem here? I don't really see it. Are you
> afraid users will reconfigure their APs often enough for this to be an
> issue?
Use case point of view, i understand that this doesn't happen often.
But from functional point of view, it can still happen and even
after disconnect mac80211 will not allow connection.

Also solution: would be to flush scan results up on disconnection.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connection issues with BW Tracking in mac80211

[Krishna Chaitanya]

On Wed, Feb 25, 2015 at 1:32 PM, Johannes Berg
 wrote:
>
> On Wed, 2015-02-25 at 02:41 +0530, Krishna Chaitanya wrote:
> > On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg
> >  wrote:
> > > On Wed, 2015-02-25 at 02:03 +0530, Krishna Chaitanya wrote:
> > >
> > >> Use case2: When changing from HT40-VHT80, the connection goes through
> > >> but it still connected as HT40 (vht_ie from cfg80211 is returned
> > >> null).
> > >>
> > >> Can you think of any reason why the bss_list is not updated cfg80211?
> > >> Note: iwconfig and wpa_supplicant both show same behavior.
> > >
> > > Well, there's no flushing, only overwriting by new results - but if you
> > > previuosly got both beacons and probe responses each one will stick
> > > around until you get them again.
> > We do have the scan results expiry time of 30secs, that will flush the
> > results from bss_list right? Even the get_bss checks for aging?
>
> Yes but if you scan in the meantime the scan result is marked as recent
> again, even if some old data might be kept. Perhaps we should split that
> into timestamps for probe and beacons separately, but that'd certainly
> complicate the code significantly for little gain.

I did some experiments on this and found the root cause.

We are using 5GHz in WORLD Mode, so only passive scan is allowed.
So when connecting the very first time, the mac80211 MLME sees that
there are no probe_resp ies (only beacon_ies are present) and it sends
a directed probe and updates the probe_resp ies. (and also the "ies").

But when config is changed and we get disconnected, beacon_ies are updated
with the new config, but the probe_resp ies are not.
cfg80211_bss_update assigns
probe_resp ies to "ies' and mac80211 updates its bss info based on the
probe_resp
ies which have old config causing the issue.

Solution:

1) Make the directed probe mandatory.
2) As you suggested maintain timestamps for probe_resp_ies and beacon_ies
and use the latest.

Any takes?

Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connection issues with BW Tracking in mac80211

[Krishna Chaitanya]

On Wed, Mar 11, 2015 at 10:05 PM, Krishna Chaitanya
 wrote:
> On Wed, Mar 11, 2015 at 9:50 PM, Johannes Berg
>  wrote:
>> On Wed, 2015-03-11 at 21:45 +0530, Krishna Chaitanya wrote:
>>
>>> I did some experiments on this and found the root cause.
>>>
>>> We are using 5GHz in WORLD Mode, so only passive scan is allowed.
>>> So when connecting the very first time, the mac80211 MLME sees that
>>> there are no probe_resp ies (only beacon_ies are present) and it sends
>>> a directed probe and updates the probe_resp ies. (and also the "ies").
>>>
>>> But when config is changed and we get disconnected, beacon_ies are updated
>>> with the new config, but the probe_resp ies are not.
>>> cfg80211_bss_update assigns
>>> probe_resp ies to "ies' and mac80211 updates its bss info based on the
>>> probe_resp
>>> ies which have old config causing the issue.
>>>
>>> Solution:
>>>
>>> 1) Make the directed probe mandatory.
>>> 2) As you suggested maintain timestamps for probe_resp_ies and beacon_ies
>>> and use the latest.
>>>
>>> Any takes?
>>
>> What's the operational problem here? I don't really see it. Are you
>> afraid users will reconfigure their APs often enough for this to be an
>> issue?
> Use case point of view, i understand that this doesn't happen often.
> But from functional point of view, it can still happen and even
> after disconnect mac80211 will not allow connection.
>
> Also solution: would be to flush scan results up on disconnection.
Johannes,

Assuming that this problem needs to be solved in spite of
low probability of the occurrence. What do you think is the
best way, which has low impact on other features out of these?

1.  Make the directed probe mandatory:
 a. Check for successful probe resp without depending on proberesp_ies.
 b. remove the proberesp_ies from the auth_data to trigger
directed probe.

2. Timestamps for proberesp and beacons and update the latest one to "ies".

3. while update "ies" check only for beacon as its supposed to have latest
information (This will trigger #1 automatically).

As a quick and minimal impact solution i am thinking 1-b.

Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cfg80211: Beacon hints for DFS channels

[Krishna Chaitanya]

Hi,

In the Regulatory and DFS wiki it is mentioned that
beacon hints are not processed for DFS channels.
But i could not find the related piece of code which
does this.

So in DFS channels can we process beacon hints?
Assuming that if AP is beaconing then there is no
RADAR in that channel. But how do we handle
channel switch (if we dont disconnect) then that
channel is enabled for active scan?
  (or)
should be we have something like this:

---

 net/wireless/reg.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 8c6cf52..25b3173 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1384,7 +1384,8 @@ static void handle_reg_beacon(struct wiphy
*wiphy, unsigned int chan_idx,
chan_before.center_freq = chan->center_freq;
chan_before.flags = chan->flags;

-   if (chan->flags & IEEE80211_CHAN_NO_IR) {
+   if (!(chan->flags & IEEE80211_CHAN_RADAR) &&
+ (chan->flags & IEEE80211_CHAN_NO_IR)) {
chan->flags &= ~IEEE80211_CHAN_NO_IR;
channel_changed = true;
}


-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: informations about Linux wifi driver's architecture today

[Krishna Chaitanya]

On Mon, Mar 23, 2015 at 2:51 AM, Stefano Cappa
 wrote:
> Hi
> I prefer a generic version, without specific things, like this one: 
> h**p://postimg.org/image/hfkpjt3ux/ created by Johannes Berg.
A while ago, i have written about the generic linux wireless
architecture for my blog. It might be helpful.
http://wire-less-comm.blogspot.in/2013/01/wireless-lan-and-linux-together.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: fix failed to set smps

[Krishna Chaitanya]

On Mon, Mar 30, 2015 at 2:13 PM, Johannes Berg
 wrote:
> On Fri, 2015-03-27 at 13:21 +0800, miaoq...@qti.qualcomm.com wrote:
>> From: Miaoqing Pan 
>>
>> Signed-off-by: Miaoqing Pan 
>
> Since you give no commit log, I can only guess what you're trying to do,
> but I suppose you need to use "echo -n" instead of "echo".
Johannes,

We had this discussion earlier also, i still strongly feel all cases
must work with "echo" by default, as people are not that familiar
to use "echo -n".
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mac80211_hwsim: Set VHT capabilities only for the 5.2 GHz band

[Krishna Chaitanya]

On Thu, Apr 9, 2015 at 1:05 PM, Jouni Malinen  wrote:
> On Wed, Apr 08, 2015 at 06:29:38PM +, Peer, Ilan wrote:
>> According to the 802.11ac amendment: "The IEEE 802.11 VHT STA operates in 
>> frequency bands below 6 GHz excluding the 2.4 GHz band", so at least the 
>> spec. is clear about it. However, I guess it would be possible to enable VHT 
>> for 2.4 as well to enjoy some of benefits, but do you see a reason/use case 
>> to enable it also for hwsim?
>
> It does not matter what the standard says on VHT in general; there are
> clearly already products out there that allow some capabilities defined
> in 802.11ac (mainly, 256-QAM) to be used on the 2.4 GHz band.
Can you name a few for reference?
>As far as
> hwsim is concerned, I'm already using it to verify the negotiation part
> for this (see ap_vht_on_24ghz test case). The main remaining question
> for cfg80211/nl80211 is on whether we can come up with a clean way of
> advertising driver capability for doing this.
In order to properly utilize these we need to incorporate these capabilities
 in to minstrel RC as well. Any plans for that?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bcmdhd: Strange Power Save messages

[Krishna Chaitanya]

On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
 wrote:
>
>
> On 29-09-16 13:32, Gucea Doru wrote:
>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru  wrote:
>>> What is the decision triggering the exit from the PS mode immediately
>>> after the ping request? I am asking this because 802.11 PS legacy
>>> specifies that the client should wait for a beacon with TIM set in
>>> order to wake up: in my case, there is no beacon between the ping
>>> request message and the Null frame that announces the exit from the PS
>>> mode.
>>
>>
>> Any help would be highly appreciated :)
>
> Actually though I already sent you are reply, but alas here it is.
>
> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
> drivers. Regardless your question is more for firmware running on the
> device. So like the same behavior would be observed when using brcmfmac
> with same firmware.
>
>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>> shall issue a PS Poll". In my capture there are cases when the STA
>> exits the PS mode without waiting for a beacon.
>
> It is a bit tricky, but the standard does not explicitly say the STA
> should be in power-save at any other time. So it is difficult to say
> what event occurred on the STA side to exit PS mode. Also STA means
> P2P-Client as you say. That means that you have multiple interfaces:
> regular STA and P2P-Client. So is the STA connected to some other AP or
> just not connected. wpa_supplicant will do intermittent scan or initiate
> scheduled scan by which firmware will scan at a certain interval. That
> is just some things I can come up with and I am sure there are more.
Keeping the STA aside, as far as AP is concerned the STA is still in PS,
so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
Because the STA might be in power-off mode things seem to work.

Re: bcmdhd: Strange Power Save messages

[Krishna Chaitanya]

On Tue, Oct 4, 2016 at 5:09 PM, Gucea Doru  wrote:
> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>  wrote:
>>>
>>>
>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru  wrote:
>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>> request message and the Null frame that announces the exit from the PS
>>>>> mode.
>>>>
>>>>
>>>> Any help would be highly appreciated :)
>>>
>>> Actually though I already sent you are reply, but alas here it is.
>>>
>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>> drivers. Regardless your question is more for firmware running on the
>>> device. So like the same behavior would be observed when using brcmfmac
>>> with same firmware.
>>>
>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>> exits the PS mode without waiting for a beacon.
>>>
>>> It is a bit tricky, but the standard does not explicitly say the STA
>>> should be in power-save at any other time. So it is difficult to say
>>> what event occurred on the STA side to exit PS mode. Also STA means
>>> P2P-Client as you say. That means that you have multiple interfaces:
>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>> just not connected. wpa_supplicant will do intermittent scan or initiate
>>> scheduled scan by which firmware will scan at a certain interval. That
>>> is just some things I can come up with and I am sure there are more.
>
> I agree that there may be some events belonging to the regular STA
> interface that could trigger the Null Frame (which includes the exit
> from PS Mode). However, I would expect to see some management frames
> in the air before/after the Null Packet (e.g.: a Probe request in case
> of a scheduled scan). But in my case the trigger for the Null frame
> seems to be the ping request packet, the scenario is the same every
> time: ping request -> Block ACK -> Null Frame (Wireshark trace
> confirms this behavior).
>
> I thought that you had a power save optimization algorithm that keeps
> the card on a few milliseconds just to see if we can have a fast reply
> from the peer. Does this ring a bell? :)
>
> On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
>  wrote:
>> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
>> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
>
> Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
> "When an AP is informed that a STA has changed to the Active mode,
> then the AP shall send buffered BUs (if any exist) to the STA without
> waiting for a PS Poll"
Yes, but in this case the STA did not inform AP (as per sniffer captures)?
so AP should set TIM/DTIM...

Re: bcmdhd: Strange Power Save messages

[Krishna Chaitanya]

On Tue, Oct 4, 2016 at 11:57 PM, Gucea Doru  wrote:
> On Tue, Oct 4, 2016 at 3:37 PM, Krishna Chaitanya
>  wrote:
>> On Tue, Oct 4, 2016 at 5:09 PM, Gucea Doru  wrote:
>>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>>>  wrote:
>>>>>
>>>>>
>>>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru  
>>>>>> wrote:
>>>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>>>> request message and the Null frame that announces the exit from the PS
>>>>>>> mode.
>>>>>>
>>>>>>
>>>>>> Any help would be highly appreciated :)
>>>>>
>>>>> Actually though I already sent you are reply, but alas here it is.
>>>>>
>>>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>>>> drivers. Regardless your question is more for firmware running on the
>>>>> device. So like the same behavior would be observed when using brcmfmac
>>>>> with same firmware.
>>>>>
>>>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>>>> exits the PS mode without waiting for a beacon.
>>>>>
>>>>> It is a bit tricky, but the standard does not explicitly say the STA
>>>>> should be in power-save at any other time. So it is difficult to say
>>>>> what event occurred on the STA side to exit PS mode. Also STA means
>>>>> P2P-Client as you say. That means that you have multiple interfaces:
>>>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>>>> just not connected. wpa_supplicant will do intermittent scan or initiate
>>>>> scheduled scan by which firmware will scan at a certain interval. That
>>>>> is just some things I can come up with and I am sure there are more.
>>>
>>> I agree that there may be some events belonging to the regular STA
>>> interface that could trigger the Null Frame (which includes the exit
>>> from PS Mode). However, I would expect to see some management frames
>>> in the air before/after the Null Packet (e.g.: a Probe request in case
>>> of a scheduled scan). But in my case the trigger for the Null frame
>>> seems to be the ping request packet, the scenario is the same every
>>> time: ping request -> Block ACK -> Null Frame (Wireshark trace
>>> confirms this behavior).
>>>
>>> I thought that you had a power save optimization algorithm that keeps
>>> the card on a few milliseconds just to see if we can have a fast reply
>>> from the peer. Does this ring a bell? :)
>>>
>>> On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
>>>  wrote:
>>>> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
>>>> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
>>>
>>> Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
>>> "When an AP is informed that a STA has changed to the Active mode,
>>> then the AP shall send buffered BUs (if any exist) to the STA without
>>> waiting for a PS Poll"
>> Yes, but in this case the STA did not inform AP (as per sniffer captures)?
>> so AP should set TIM/DTIM...
>
> The STA _did_ inform the AP.
>
> If you take a look at the packet traces you'll see that the STA sends
> a NULL frame saying that it will exit Power Save Mode. According to
> the specification the AP can send the buffered frames.
Yeah, sorry i thought AP is sending the ping request.
But still as STA is sending "ping request" with PM=0, the state at
AP should be updated treating STA as active, so sending NULL data +
PM=0 is redundant.





-- 
Thanks,
Regards,
Chaitanya T K.

Re: [RFC v4] mac80211: add A-MSDU tx support

[Krishna Chaitanya]

On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  wrote:
> On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
>> Requires software tx queueing support. frag_list support (for zero-copy)
>> is optional.
>>
>> Signed-off-by: Felix Fietkau 
>> ---
>
>
> Ok - looks fine, but... and here comes the hard stuff.
> The frame size in the PLCP is limited in a way that you can't - from a
> spec POV - enable A-MSDU for low rates. Of course, you don't want to
> do that for low rates at all regardless of the spec.
> Since you build the A-MSDU in the mac80211 Tx queue which is not aware
> of the link quality, how do we prevent A-MSDU if the rate is low /
> dropping.
> I'd even argue that when the rates get lower, you'll  have more
> packets piling up in the software queue and ... even more chance to
> get A-MSDU in the exact case where you really want to avoid it?

Similar to triggering AMPDU setup, we should put this control
in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
drop below a pre-defined MCS (or) only for best-throughput rates.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v4] mac80211: add A-MSDU tx support

[Krishna Chaitanya]

On Mon, Feb 8, 2016 at 4:34 PM, Felix Fietkau  wrote:
> On 2016-02-08 10:54, Krishna Chaitanya wrote:
>> On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  
>> wrote:
>>> On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
>>>> Requires software tx queueing support. frag_list support (for zero-copy)
>>>> is optional.
>>>>
>>>> Signed-off-by: Felix Fietkau 
>>>> ---
>>>
>>>
>>> Ok - looks fine, but... and here comes the hard stuff.
>>> The frame size in the PLCP is limited in a way that you can't - from a
>>> spec POV - enable A-MSDU for low rates. Of course, you don't want to
>>> do that for low rates at all regardless of the spec.
>>> Since you build the A-MSDU in the mac80211 Tx queue which is not aware
>>> of the link quality, how do we prevent A-MSDU if the rate is low /
>>> dropping.
>>> I'd even argue that when the rates get lower, you'll  have more
>>> packets piling up in the software queue and ... even more chance to
>>> get A-MSDU in the exact case where you really want to avoid it?
>>
>> Similar to triggering AMPDU setup, we should put this control
>> in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
>> drop below a pre-defined MCS (or) only for best-throughput rates.
> I think starting/stopping A-MSDU based on the rate is a bad idea.
> Even with low rates, using A-MSDU can be a good thing (especially for
> TCP ACKs), it just needs different size limits.

By low rates, i was referring to bad channel conditions (more
retries/crc errors)
so using AMSDU might trigger more TCP level retries and for case
of TCP ACK's its still worse in that it triggers TCP data retires from the
peer.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v4] mac80211: add A-MSDU tx support

[Krishna Chaitanya]

On Mon, Feb 8, 2016 at 3:56 PM, Emmanuel Grumbach  wrote:
> On Mon, Feb 8, 2016 at 11:54 AM, Krishna Chaitanya
>  wrote:
>> On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  
>> wrote:
>>> On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
>>>> Requires software tx queueing support. frag_list support (for zero-copy)
>>>> is optional.
>>>>
>>>> Signed-off-by: Felix Fietkau 
>>>> ---
>>>
>>>
>>> Ok - looks fine, but... and here comes the hard stuff.
>>> The frame size in the PLCP is limited in a way that you can't - from a
>>> spec POV - enable A-MSDU for low rates. Of course, you don't want to
>>> do that for low rates at all regardless of the spec.
>>> Since you build the A-MSDU in the mac80211 Tx queue which is not aware
>>> of the link quality, how do we prevent A-MSDU if the rate is low /
>>> dropping.
>>> I'd even argue that when the rates get lower, you'll  have more
>>> packets piling up in the software queue and ... even more chance to
>>> get A-MSDU in the exact case where you really want to avoid it?
>>
>> Similar to triggering AMPDU setup, we should put this control
>> in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
>> drop below a pre-defined MCS (or) only for best-throughput rates.
>
> Ok - but the size of A-MPDU is determined in the firmware / hardware
> typically (at least for Intel devices and I have to admit my ignorance
> about other designs...). So that if you get bad link conditions, the
> firmware can play for that size. A-MSDU built in the host is a
> different story. I remember that athXk devices attach the rate on the
> Tx packet itself so that the rate control is serialized with the data
> path.
> iwlwifi works differently: we have a map of rates in the firmware.
> This map is maintained in the driver updated based on the feedback we
> get from the device. When an update is needed, iwlwifi sends a command
> to the firmware and that command bypasses all the Tx packets currently
> queue so that a packet that is already waiting in the queue will be
> sent with the updated map. This allows iwlwifi to react downgrade
> faster when needed.
> So - for athXk (and maybe the MediaTek devices Felix is working on),
> this may not be a big problem: you'd need to add another input to the
> A-MSDU building code coming from the rate control.
> FWIW: in iwlwifi I simply decided to be on the safe side and allowed
> the driver to build A-MSDUs only if the rate is fairly high and we are
> not downgrading. But you saw (and commented on) that patch already I
> think :)

Yes, this approach is going to be tough for those devices with HW RC.
We might need something like amsdu_action to get some feedback from
device about using of amsdu?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath9k(?): AP stops sending traffic to iPhone 4S until another 802.11n-capable STA joins

[Krishna Chaitanya]

On Wed, Feb 17, 2016 at 10:02 AM, Avery Pennarun  wrote:
>
> On Tue, Feb 16, 2016 at 5:05 PM, Johannes Berg
>  wrote:
> > On Tue, 2016-02-16 at 16:28 -0500, Avery Pennarun wrote:
> >> Changing default_agg_timeout to zero (as it is on most non-ath9k
> >> drivers) makes the problem pretty much go away.  However, I think
> >> it's because I'm just dodging the code path that triggers a race
> >> condition.
> >
> > That does seem likely. Perhaps you could reproduce it while running
> > mac80211 tracing? There should be a fair amount of information about
> > aggregation and queue stops in there, though as you note queue stops
> > aren't really happening, only aggregation related things. Perhaps the
> > tracepoints for that aren't quite sufficient.
>
> So far that hasn't seemed to help, although maybe you can read traces
> better than I can.  The big problem is that the actual queue doesn't
> seem to have stopped; it might be an ath9k bug.
>
> >> Notes:
> >>
> >> - I'm using exactly the same ath9k driver (currently 20150525, but
> >> we've   tried newer ones with no difference) on two totally different
> >> platforms: a dual-core mindspeed c2k host CPU (ARMv7) with separate
> >> ath9k, and a single-core QCA9531 (MIPS) with on-chip ath9k.
> >>
> >> - I've been unable to trigger the problem on the QCA9531, but I have
> >> on MIPS.
> >
> > That's ... not what I would have expected, especially since the MIPS is
> > single core. That makes the races stranger than expected.
>
> Oops, typo.  The QCA9531 *is* MIPS.  The one where it triggers is the
> dual-core ARM.
>
> >> The aggregation code is... a little hairy.  Does anyone have any
> >> guesses where I might look for the race condition?  Or better still,
> >> a patch I can try?
> >
> > I'm not aware of any race conditions in the code right now :)
>
> Aw.  That would have made it a lot easier!


>From a quick glance of symptoms, i think the below patch is worth a
try, even though
i don't see you are doing any background scans for which this applies.

https://patchwork.kernel.org/patch/8015321/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RFC: Handling DL only traffic when already in Powersave

[Krishna Chaitanya]

Hi,

When using HW_PS and running Downlink only traffic like UDP-RX, mac80211
has the mechanism to not to enter power-save (postpone the dynamic ps
timer).

But if we are already in power-save it continues to stay in PS
and retrieves the frames, for large traffic this is not acceptable.

The standard doesn't say anything, its left to vendor to implement their
own mechanism.

I have the below questions

1) Are any other vendors seeing this issue?

2) Are they using proprietary algorithms to solve this,
implemented in their HW/FW?

3) If yes, how are they keeping the mac80211 and FW FSM in sync,
as the driver cannot request/indicate the power save state to mac80211.
(no feedback path).

IMHO,

a) we should implemented a feedback path, where the vendor
can implement proprietary mechanism to handle this and inform/request
mac80211 for a specific power save state.

b) mac80211 just conveys the user/system preferences to the driver
and driver handles the FSM on when to enter/exit PS? (true HW_PS).


Any suggestions/comments?

-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: Handling DL only traffic when already in Powersave

[Krishna Chaitanya]

On Fri, Apr 8, 2016 at 1:37 AM, Johannes Berg  wrote:
> On Thu, 2016-04-07 at 18:31 +0530, Krishna Chaitanya wrote:
>> Hi,
>>
>> When using HW_PS and running Downlink only traffic like UDP-RX,
>> mac80211 has the mechanism to not to enter power-save (postpone the
>> dynamic ps timer).
>>
>> But if we are already in power-save it continues to stay in PS
>> and retrieves the frames, for large traffic this is not acceptable.
>>
>> The standard doesn't say anything, its left to vendor to implement
>> their own mechanism.
>>
>> I have the below questions
>>
>> 1) Are any other vendors seeing this issue?
>
> No. Nobody else really relies on the mac80211 powersave any more.
>
>> 2) Are they using proprietary algorithms to solve this,
>> implemented in their HW/FW?
>
> Yes. "Proprietary" is such a big word.
>
>> 3) If yes, how are they keeping the mac80211 and FW FSM in sync,
>> as the driver cannot request/indicate the power save state to
>> mac80211.
>> (no feedback path).
>
> No need, don't use the mac80211 implementation! Tell mac80211 you
> implement PS and DYNAMIC_PS, and it will not do anything whatsoever.

I have forgotten abut disabling DYNAMIC_PS flag, thanks, Will try that.

>> IMHO,
>>
>> a) we should implemented a feedback path, where the vendor
>> can implement proprietary mechanism to handle this and inform/request
>> mac80211 for a specific power save state.
>
> No.
>
>> b) mac80211 just conveys the user/system preferences to the driver
>> and driver handles the FSM on when to enter/exit PS? (true HW_PS).
>>
> Done when you have PS and DYNAMIC_PS advertised to mac80211.
>
> The mac80211 powersave code is pretty much beyond salvaging anyway.
>
> What really should happen is that there should be some kind of library
> functionality that drivers that need host powersave management can hook
> into, *per interface*, and then do the right thing.

Agree, this gives devices more control, with common code implemented
by mac80211.

> Then eventually we can remove all the powersave handling code from
> mac80211, it's seriously broken anyway (doesn't support more than one
> virtual interface, has problems like you describe above, etc.)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: General VHT rate-ctrl question

[Krishna Chaitanya]

On Wed, Apr 13, 2016 at 10:31 PM, Dave Taht  wrote:
>
> On Wed, Apr 13, 2016 at 6:18 AM, Ben Greear  wrote:
> >
> >
> > On 04/13/2016 01:01 AM, Johannes Berg wrote:
> >>
> >> On Tue, 2016-04-12 at 16:48 -0700, Ben Greear wrote:
> >>>
> >>> If a station and it's peer can both do VHT, is there ever a good
> >>> reason to even try HT rates?
> >>>
> >>
> >> Not really; perhaps if you could do HT greenfield preamble (which VHT
> >> doesn't have) you could get something out of it, beyond that I don't
> >> see a reason to try.
> >>
> >> Unless, for some strange reason, it supports only single stream VHT and
> >> dual-stream HT or something really weird?
> >
> >
> > I was wondering if there was ever a reason that, say 450Mbps HT
> > would work better than MCS-1 for VHT.  Or, maybe a mid-rate HT MCS would
> > have more range than VHT, or something like that.
I dont think so. basically if you remove 256 QAM out of picture,
it just boils down to choosing a modulation scheme which would
be same for VHT and HT. (assuming same BW)

Only advantage is as Johannes pointed, VHT doesn't have greenfield,
so using HT greenfield preamble might be marginally good. Similarly we can
use RIFS for HT(not recommended), But again who uses RIFS/greenfield?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Debug prints mac80211 drivers

[Krishna Chaitanya]

Hi,

What is the recommended method for adding
debug prints in mac80211 based drivers.

1) -DDEBUG + pr_debug ==> used by mac80211, brcm80211
2) -DDEBUG + dev_dbg ==> zd1201
3) dev_printk(KERN_DEBUG) ==> used by iwlwifi
4) printk(KERN_DEBUG) ==> Just to complete the list.

-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug prints mac80211 drivers

[Krishna Chaitanya]

On Sat, Apr 23, 2016 at 12:59 AM, Joe Perches  wrote:
>
> On Fri, 2016-04-22 at 17:51 +0530, Krishna Chaitanya wrote:
> > What is the recommended method for adding
> > debug prints in mac80211 based drivers.
> >
> > 1) -DDEBUG + pr_debug ==> used by mac80211, brcm80211
> > 2) -DDEBUG + dev_dbg ==> zd1201
> > 3) dev_printk(KERN_DEBUG) ==> used by iwlwifi
> > 4) printk(KERN_DEBUG) ==> Just to complete the list.
>
> wiphy_dbg -> netif_dbg -> netdev_dbg -> dev_dbg -> pr_debug
Ok, thats what checpatch --strict throws. but still different vendors follow
different standards, so wanted to check if we should go strictly with
checkpatch (or) is there any rationale behind choose each of the variant.

> and CONFIG_DYNAMIC_DEBUG, no -DDEBUG required
Yes, i understand. Till now we had this enabled, so pr_debug
works just fine, but now it is disabled hence the question.

Also there are pros and cons to having control using dyndbg,
user can disable dyndbg, there be missing imp debugs, in this case
having module level (-DDEBUG) helps but if we want entire system
to run in non-debug mode, disabling dyndbg helps.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug prints mac80211 drivers

[Krishna Chaitanya]

On Sat, Apr 23, 2016 at 3:48 AM, Joe Perches  wrote:
> On Sat, 2016-04-23 at 02:32 +0530, Krishna Chaitanya wrote:
>> On Sat, Apr 23, 2016 at 12:59 AM, Joe Perches  wrote:
>> >
>> >
>> > On Fri, 2016-04-22 at 17:51 +0530, Krishna Chaitanya wrote:
>> > >
>> > > What is the recommended method for adding
>> > > debug prints in mac80211 based drivers.
>> > >
>> > > 1) -DDEBUG + pr_debug ==> used by mac80211, brcm80211
>> > > 2) -DDEBUG + dev_dbg ==> zd1201
>> > > 3) dev_printk(KERN_DEBUG) ==> used by iwlwifi
>> > > 4) printk(KERN_DEBUG) ==> Just to complete the list.
>> > wiphy_dbg -> netif_dbg -> netdev_dbg -> dev_dbg -> pr_debug
>> Ok, thats what checpatch --strict throws. but still different vendors
>> follow
>> different standards, so wanted to check if we should go strictly with
>> checkpatch (or) is there any rationale behind choose each of the
>> variant.
>
> Generally the variants are used to produce sufficient
> logging information to identify the appropriate device.
>
> Most all debugging printks shouldn't be emitted unless
> actually debugging.
>
>> > and CONFIG_DYNAMIC_DEBUG, no -DDEBUG required
>> Yes, i understand. Till now we had this enabled, so pr_debug
>> works just fine, but now it is disabled hence the question.
>>
>> Also there are pros and cons to having control using dyndbg,
>> user can disable dyndbg, there be missing imp
>
> imp?
Sorry, important.
>>  debugs, in this case
>> having module level (-DDEBUG) helps but if we want entire system
>> to run in non-debug mode, disabling dyndbg helps.
>
> Confused:
>
> dynamic debug printks aren't emitted by default
> unless DEBUG is also defined or specifically
> enabled by the user.
I don't think so, enabling dynamic debug should suffice.

280 #if defined(CONFIG_DYNAMIC_DEBUG)
281 /* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */
282 #define pr_debug(fmt, ...) \
283 dynamic_pr_debug(fmt, ##__VA_ARGS__)
284 #elif defined(DEBUG)
285 #define pr_debug(fmt, ...) \
286 printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
287 #else
288 #define pr_debug(fmt, ...) \
289 no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
290 #endif



-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug prints mac80211 drivers

[Krishna Chaitanya]

On Sat, Apr 23, 2016 at 1:35 PM, Joe Perches  wrote:
> On Sat, 2016-04-23 at 13:11 +0530, Krishna Chaitanya wrote:
>> On Sat, Apr 23, 2016 at 3:48 AM, Joe Perches  wrote:
>> >
>> > On Sat, 2016-04-23 at 02:32 +0530, Krishna Chaitanya wrote:
>> > >
>> > > On Sat, Apr 23, 2016 at 12:59 AM, Joe Perches 
>> > > wrote:
>> > > >
>> > > >
>> > > >
>> > > > On Fri, 2016-04-22 at 17:51 +0530, Krishna Chaitanya wrote:
>> > > > >
>> > > > >
>> > > > > What is the recommended method for adding
>> > > > > debug prints in mac80211 based drivers.
>> > > > >
>> > > > > 1) -DDEBUG + pr_debug ==> used by mac80211, brcm80211
>> > > > > 2) -DDEBUG + dev_dbg ==> zd1201
>> > > > > 3) dev_printk(KERN_DEBUG) ==> used by iwlwifi
>> > > > > 4) printk(KERN_DEBUG) ==> Just to complete the list.
>> > > > wiphy_dbg -> netif_dbg -> netdev_dbg -> dev_dbg -> pr_debug
>> > > Ok, thats what checpatch --strict throws. but still different
>> > > vendors
>> > > follow
>> > > different standards, so wanted to check if we should go strictly
>> > > with
>> > > checkpatch (or) is there any rationale behind choose each of the
>> > > variant.
>> > Generally the variants are used to produce sufficient
>> > logging information to identify the appropriate device.
>> >
>> > Most all debugging printks shouldn't be emitted unless
>> > actually debugging.
>> >
>> > >
>> > > >
>> > > > and CONFIG_DYNAMIC_DEBUG, no -DDEBUG required
>> > > Yes, i understand. Till now we had this enabled, so pr_debug
>> > > works just fine, but now it is disabled hence the question.
>> > >
>> > > Also there are pros and cons to having control using dyndbg,
>> > > user can disable dyndbg, there be missing imp
>> > imp?
>> Sorry, important.
>> >
>> > >
>> > >  debugs, in this case
>> > > having module level (-DDEBUG) helps but if we want entire system
>> > > to run in non-debug mode, disabling dyndbg helps.
>> > Confused:
>> >
>> > dynamic debug printks aren't emitted by default
>> > unless DEBUG is also defined or specifically
>> > enabled by the user.
>> I don't think so, enabling dynamic debug should suffice.
>>
>> 280 #if defined(CONFIG_DYNAMIC_DEBUG)
>> 281 /* dynamic_pr_debug() uses pr_fmt() internally so we don't need it
>> here */
>> 282 #define pr_debug(fmt, ...) \
>> 283 dynamic_pr_debug(fmt, ##__VA_ARGS__)
>> 284 #elif defined(DEBUG)
>> 285 #define pr_debug(fmt, ...) \
>> 286 printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
>> 287 #else
>> 288 #define pr_debug(fmt, ...) \
>> 289 no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
>> 290 #endif
>>
>
> Nope.
>
> Look at dynamic_debug.h
>
> #if defined DEBUG
> #define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
> #else
> #define _DPRINTK_FLAGS_DEFAULT 0
> #endif
>
> and
>
>   .flags =  _DPRINTK_FLAGS_DEFAULT,
>
> and
>
> #define DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt)\
> static struct _ddebug  __aligned(8) \
> __attribute__((section("__verbose"))) name = {  \
> .modname = KBUILD_MODNAME,  \
> .function = __func__,   \
> .filename = __FILE__,   \
> .format = (fmt),\
> .lineno = __LINE__, \
> .flags =  _DPRINTK_FLAGS_DEFAULT,   \
> }
>
> and
>
> #define dynamic_pr_debug(fmt, ...)  \
> do {\
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT))  \
> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>##__VA_ARGS__);  \
> } while (0)
>
> So by default, it's not enabled to be output
Ok, i understand. We did not advertise -DDEBUG but pr_debug still
works, need to check if we are enabling it through some other option.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug prints mac80211 drivers

[Krishna Chaitanya]

On Sat, Apr 23, 2016 at 1:53 PM, Krishna Chaitanya
 wrote:
> On Sat, Apr 23, 2016 at 1:35 PM, Joe Perches  wrote:
>> On Sat, 2016-04-23 at 13:11 +0530, Krishna Chaitanya wrote:
>>> On Sat, Apr 23, 2016 at 3:48 AM, Joe Perches  wrote:
>>> >
>>> > On Sat, 2016-04-23 at 02:32 +0530, Krishna Chaitanya wrote:
>>> > >
>>> > > On Sat, Apr 23, 2016 at 12:59 AM, Joe Perches 
>>> > > wrote:
>>> > > >
>>> > > >
>>> > > >
>>> > > > On Fri, 2016-04-22 at 17:51 +0530, Krishna Chaitanya wrote:
>>> > > > >
>>> > > > >
>>> > > > > What is the recommended method for adding
>>> > > > > debug prints in mac80211 based drivers.
>>> > > > >
>>> > > > > 1) -DDEBUG + pr_debug ==> used by mac80211, brcm80211
>>> > > > > 2) -DDEBUG + dev_dbg ==> zd1201
>>> > > > > 3) dev_printk(KERN_DEBUG) ==> used by iwlwifi
>>> > > > > 4) printk(KERN_DEBUG) ==> Just to complete the list.
>>> > > > wiphy_dbg -> netif_dbg -> netdev_dbg -> dev_dbg -> pr_debug
>>> > > Ok, thats what checpatch --strict throws. but still different
>>> > > vendors
>>> > > follow
>>> > > different standards, so wanted to check if we should go strictly
>>> > > with
>>> > > checkpatch (or) is there any rationale behind choose each of the
>>> > > variant.
>>> > Generally the variants are used to produce sufficient
>>> > logging information to identify the appropriate device.
>>> >
>>> > Most all debugging printks shouldn't be emitted unless
>>> > actually debugging.
>>> >
>>> > >
>>> > > >
>>> > > > and CONFIG_DYNAMIC_DEBUG, no -DDEBUG required
>>> > > Yes, i understand. Till now we had this enabled, so pr_debug
>>> > > works just fine, but now it is disabled hence the question.
>>> > >
>>> > > Also there are pros and cons to having control using dyndbg,
>>> > > user can disable dyndbg, there be missing imp
>>> > imp?
>>> Sorry, important.
>>> >
>>> > >
>>> > >  debugs, in this case
>>> > > having module level (-DDEBUG) helps but if we want entire system
>>> > > to run in non-debug mode, disabling dyndbg helps.
>>> > Confused:
>>> >
>>> > dynamic debug printks aren't emitted by default
>>> > unless DEBUG is also defined or specifically
>>> > enabled by the user.
>>> I don't think so, enabling dynamic debug should suffice.
>>>
>>> 280 #if defined(CONFIG_DYNAMIC_DEBUG)
>>> 281 /* dynamic_pr_debug() uses pr_fmt() internally so we don't need it
>>> here */
>>> 282 #define pr_debug(fmt, ...) \
>>> 283 dynamic_pr_debug(fmt, ##__VA_ARGS__)
>>> 284 #elif defined(DEBUG)
>>> 285 #define pr_debug(fmt, ...) \
>>> 286 printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
>>> 287 #else
>>> 288 #define pr_debug(fmt, ...) \
>>> 289 no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
>>> 290 #endif
>>>
>>
>> Nope.
>>
>> Look at dynamic_debug.h
>>
>> #if defined DEBUG
>> #define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
>> #else
>> #define _DPRINTK_FLAGS_DEFAULT 0
>> #endif
>>
>> and
>>
>>   .flags =  _DPRINTK_FLAGS_DEFAULT,
>>
>> and
>>
>> #define DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt)\
>> static struct _ddebug  __aligned(8) \
>> __attribute__((section("__verbose"))) name = {  \
>> .modname = KBUILD_MODNAME,  \
>> .function = __func__,   \
>> .filename = __FILE__,   \
>> .format = (fmt),\
>> .lineno = __LINE__, \
>> .flags =  _DPRINTK_FLAGS_DEFAULT,   \
>> }
>>
>> and
>>
>> #define dynamic_pr_debug(fmt, ...)  \
>> do {\
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT))  \
>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>##__VA_ARGS__);  \
>> } while (0)
>>
>> So by default, it's not enabled to be output
> Ok, i understand. We did not advertise -DDEBUG but pr_debug still
> works, need to check if we are enabling it through some other option.
To conclude, for a device driver using option#2: -DDEBUG + dev_dbg should
suffice?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Krishna Chaitanya]

On Tue, Apr 26, 2016 at 4:20 PM, Kalle Valo  wrote:
>
> Radu P  writes:
>
> > iw list|grep -i VHT  <- still nothing
>
> Maybe your iw is too old? I didn't see anything either (using stock iw
> from Ubuntu 14.04) but then I upgraded to the latest one from git and
> now I see:
>
>VHT Capabilities (0x338001b2):
> Max MPDU length: 11454
> Supported Channel Width: neither 160 nor 80+80
> RX LDPC
> short GI (80 MHz)
> TX STBC
> RX antenna pattern consistency
> TX antenna pattern consistency
> VHT RX MCS set:
> 1 streams: MCS 0-9
> 2 streams: MCS 0-9
> 3 streams: MCS 0-9
> 4 streams: not supported
> 5 streams: not supported
> 6 streams: not supported
> 7 streams: not supported
> 8 streams: not supported
> VHT RX highest supported: 0 Mbps
> VHT TX MCS set:
> 1 streams: MCS 0-9
> 2 streams: MCS 0-9
> 3 streams: MCS 0-9
> 4 streams: not supported
> 5 streams: not supported
> 6 streams: not supported
> 7 streams: not supported
> 8 streams: not supported
> VHT TX highest supported: 0 Mbps
>
> And please don't top post.
>
> --
"iw phy " should give necessary info.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] Sampling Holes in Minstrel when VHT is enabled

[Krishna Chaitanya]

Hi,

With the current design, occasionally we are seeing issues
where minstrel sends 3x3 rates for our 2x2 chip.

IMHO, couple of things can cause this

1) update_caps doesn't take local HW capabilities in to account

2) While calculating sample_idx, we use MCS_GROUP_RATES
which can cause a sampling hole.

For eg: if sample_idx: 78, group will be 7 it is HT
so rate_idx will be : 8  +  (2-1) * 8 = 16 = 3x3 MCS0 20 MHz.

ideally we should add

a) local hw_checks and update groups.supported accordingly.

b) use the formula index % get_max_group_rates (or) replace all
instances of MCS_GROUP_RATES for HT with 8.
(in set_rate, get_sampling_rate etc..)


-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Krishna Chaitanya]

On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle  wrote:
> Johannes Berg  writes:
>
>> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:
>>
>>> The thing is, it actually works just fine with the patch I posted
>>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>>> applied, the ath10k driver works just fine in HT mode.
>>
>> This patch has no implications on HT, and I wasn't planning on applying
>> the mac80211 patch.
>
> Yeah, makes sense. I'm planning to apply this soon.
>
>> As I said, I have no objections to doing the (Broadcom) vendor specific
>> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
>> the spec IEs when they're explicitly specified to be used only in the
>> 5.2 GHz band.
>
> But we really should have this, any volunteers? :) I think it shouldn't
> be too hard to do so this would be a good project for someone looking
> for a simple, but useful, task on wireless stack.
Are these Broadcom IEs documented somewhere? If yes,
then its a matter of parsing them and adding support to
minstrel_ht, isn't it? major work would be in minstrel.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Krishna Chaitanya]

On Wed, Apr 27, 2016 at 1:40 AM, Ben Greear  wrote:
> On 04/26/2016 01:07 PM, Krishna Chaitanya wrote:
>>
>> On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle 
>> wrote:
>>>
>>> Johannes Berg  writes:
>>>
>>>> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:
>>>>
>>>>> The thing is, it actually works just fine with the patch I posted
>>>>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>>>>> applied, the ath10k driver works just fine in HT mode.
>>>>
>>>>
>>>> This patch has no implications on HT, and I wasn't planning on applying
>>>> the mac80211 patch.
>>>
>>>
>>> Yeah, makes sense. I'm planning to apply this soon.
>>>
>>>> As I said, I have no objections to doing the (Broadcom) vendor specific
>>>> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
>>>> the spec IEs when they're explicitly specified to be used only in the
>>>> 5.2 GHz band.
>>>
>>>
>>> But we really should have this, any volunteers? :) I think it shouldn't
>>> be too hard to do so this would be a good project for someone looking
>>> for a simple, but useful, task on wireless stack.
>>
>> Are these Broadcom IEs documented somewhere? If yes,
>> then its a matter of parsing them and adding support to
>> minstrel_ht, isn't it? major work would be in minstrel.
>>
>
> For ath10k, rate-ctrl is done in the firmware, so
> no work at all in minstrel-ht.

Right, i think this might become more common.
So may we need to change minstrel_ht as well?

> The end result, as far as I can tell,
> is you would just have to tell mac80211 to allow
> VHT on 2.4Ghz, and revert this patch that Kalle is proposing.

Ideally as this is vendor specific it makes sense to implement this
at Driver/FW level rather than implementing it at a common stack
like mac80211.

> Maybe someone that actually knows about these IEs can explain why
> they are worth using?

These IE's can be parsed in the driver without any mac80211 involvement.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Krishna Chaitanya]

On Wed, Apr 27, 2016 at 2:46 PM, Jouni Malinen  wrote:
> On Wed, Apr 27, 2016 at 12:13:46PM +0530, Krishna Chaitanya wrote:
>> On Wed, Apr 27, 2016 at 1:40 AM, Ben Greear  wrote:
>> > On 04/26/2016 01:07 PM, Krishna Chaitanya wrote:
>> >> Are these Broadcom IEs documented somewhere? If yes,
>> >> then its a matter of parsing them and adding support to
>> >> minstrel_ht, isn't it? major work would be in minstrel.
>
>> > The end result, as far as I can tell,
>> > is you would just have to tell mac80211 to allow
>> > VHT on 2.4Ghz, and revert this patch that Kalle is proposing.
>>
>> Ideally as this is vendor specific it makes sense to implement this
>> at Driver/FW level rather than implementing it at a common stack
>> like mac80211.
>>
>> > Maybe someone that actually knows about these IEs can explain why
>> > they are worth using?
>>
>> These IE's can be parsed in the driver without any mac80211 involvement.
>
> Sure, these are vendor specific elements, but they are simply
> encapsulating the standard VHT elements that we already handle within
> mac80211 for STA functionality and hostapd for AP functionality. I don't
> see why we would make this any more complex for 2.4 GHz 256-QAM support
> than extending the existing locations that support the VHT elements.
>
> The main reason for me in using these particular vendor specific
> elements is in them being already supported by number of deployed
> devices. There is also support for these in hostapd (vendor_vht=1 in
> hostapd.conf) and as far as I know, this used to work with ath10k for AP
> mode (and this patch we discuss here may break that). The main missing
> functionality is for the matching STA side support with mac80211 and
> that's where the changes, IMHO, would fit in nicely in mac80211 next to
> the places where we handle the matching standard VHT elements in the 5
> GHz band.
If many vendors need this support, then mac80211 appraoch would be good.
If not, we should stick to driver approach.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

dynamic ps + offchannel mgmt_tx + HW RoC

[Krishna Chaitanya]

Hi,

When the HW is in PS and Dynamic PS is enabled we are dropping
all the offchannel frames. Sequence is as below

if hw is in PS: stop_queues reason=PS, queue dynamic_ps_disable_work
send Offchannel mgmt_tx
drop the packet because offchanel + stop_reasons[q] !=0

How should we handle this? SW RoC is handling this
by checking for offchannel and bringing the HW out of PS before
handing the packet to TX path, so it works fine.

-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dynamic ps + offchannel mgmt_tx + HW RoC

[Krishna Chaitanya]

On Tue, May 3, 2016 at 6:44 PM, Johannes Berg  wrote:
> On Tue, 2016-05-03 at 18:23 +0530, Krishna Chaitanya wrote:
>> Hi,
>>
>> When the HW is in PS and Dynamic PS is enabled we are dropping
>> all the offchannel frames. Sequence is as below
>>
>> if hw is in PS: stop_queues reason=PS, queue dynamic_ps_disable_work
>> send Offchannel mgmt_tx
>> drop the packet because offchanel + stop_reasons[q] !=0
>>
>> How should we handle this? SW RoC is handling this
>> by checking for offchannel and bringing the HW out of PS before
>> handing the packet to TX path, so it works fine.
>
> You should handle this by not doing such a non-sensical thing and
> finally implementing powersave properly in the driver :)
i don't see any issues in the powersave w.r.t driver. Isn't it a
valid case? you meant implementing dynamic_ps?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dynamic ps + offchannel mgmt_tx + HW RoC

[Krishna Chaitanya]

On Tue, May 3, 2016 at 7:46 PM, Krishna Chaitanya
 wrote:
> On Tue, May 3, 2016 at 6:44 PM, Johannes Berg  
> wrote:
>> On Tue, 2016-05-03 at 18:23 +0530, Krishna Chaitanya wrote:
>>> Hi,
>>>
>>> When the HW is in PS and Dynamic PS is enabled we are dropping
>>> all the offchannel frames. Sequence is as below
>>>
>>> if hw is in PS: stop_queues reason=PS, queue dynamic_ps_disable_work
>>> send Offchannel mgmt_tx
>>> drop the packet because offchanel + stop_reasons[q] !=0
>>>
>>> How should we handle this? SW RoC is handling this
>>> by checking for offchannel and bringing the HW out of PS before
>>> handing the packet to TX path, so it works fine.
>>
>> You should handle this by not doing such a non-sensical thing and
>> finally implementing powersave properly in the driver :)
> i don't see any issues in the powersave w.r.t driver. Isn't it a
> valid case? you meant implementing dynamic_ps?
If it advertise HW_SUPPORTS_DYNAMIC_PS it works fine.
so may be we should queue those frames and send it to
HW once it is out of powersave?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dynamic ps + offchannel mgmt_tx + HW RoC

[Krishna Chaitanya]

On Tue, May 3, 2016 at 9:31 PM, Johannes Berg  wrote:
> On Tue, 2016-05-03 at 20:02 +0530, Krishna Chaitanya wrote:
>
>> > i don't see any issues in the powersave w.r.t driver. Isn't it a
>> > valid case? you meant implementing dynamic_ps?
>
> No, I really did mean implementing the entire PS logic in the driver,
> instead of having mac80211 do it.
>
>> If it advertise HW_SUPPORTS_DYNAMIC_PS it works fine.
>> so may be we should queue those frames and send it to
>> HW once it is out of powersave?
>
> We could, but I *really* don't want to patch over the messy and broken
> powersave code in mac80211 now.
>
> I really do think that the only way out of this mess is to implement
> powersave entirely outside of mac80211; perhaps mac80211 could provide
> helpers for it, but tying it into the MLME implementation and having
> all the PS-Poll stuff be global etc. is simply wrong today.
Okay, i understand. This again points to our discussion about mac80211
ps a while ago. May be we should document this somewhere so that
device driver developers are aware of this?



-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dynamic ps + offchannel mgmt_tx + HW RoC

[Krishna Chaitanya]

On Wed, May 4, 2016 at 1:05 AM, Johannes Berg  wrote:
> There is, btw, perhaps a different way - just fix the damn stuff.
>
> Requires moving everything into ifmgd rather than local, and then
> perhaps if only a single managed interface exists mirroring its state
> into the existing driver calls etc.
>
> It'd still be a big task, and I don't see much advantage over just
> reimplementing it.

Yes, requires quite an effort and also need to handle lot of cases.
Instead, why don't we make the default as complete PS offload
and force the drivers who need to use mac80211 PS negate these
in the register_hw? That way we are clear about the intentions.

-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dynamic ps + offchannel mgmt_tx + HW RoC

[Krishna Chaitanya]

On Wed, May 4, 2016 at 1:33 AM, Johannes Berg  wrote:
> On Wed, 2016-05-04 at 01:20 +0530, Krishna Chaitanya wrote:
>> On Wed, May 4, 2016 at 1:05 AM, Johannes Berg > net> wrote:
>> >
>> > There is, btw, perhaps a different way - just fix the damn stuff.
>> >
>> > Requires moving everything into ifmgd rather than local, and then
>> > perhaps if only a single managed interface exists mirroring its
>> > state
>> > into the existing driver calls etc.
>> >
>> > It'd still be a big task, and I don't see much advantage over just
>> > reimplementing it.
>> Yes, requires quite an effort and also need to handle lot of cases.
>> Instead, why don't we make the default as complete PS offload
>> and force the drivers who need to use mac80211 PS negate these
>> in the register_hw? That way we are clear about the intentions.
>
> I don't really see a big advantage, and it'd create churn in a lot of
> drivers. Maybe documenting it with the flags that we really think you
> should set them or something, or making the powersave DOC section
> mention this would be good, but beyond that I don't think it'd be a
> good idea.
that's fine with me.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] cfg80211: allow to configure dynamic PS timeout

[Krishna Chaitanya]

On Tue, Oct 7, 2014 at 5:35 PM, Johannes Berg  wrote:
>
> On Tue, 2014-10-07 at 13:03 +0200, Stanislaw Gruszka wrote:
> > On Mon, Oct 06, 2014 at 05:00:40PM +0200, Johannes Berg wrote:
> > > On Wed, 2014-10-01 at 11:27 +0200, Stanislaw Gruszka wrote:
> > > > Dynamic power save timeout value is suppose to be configurable via
> > > > wext, but due to iwconfig bug is not possible to set using that tool.
> > >
> > > That's interesting, what's that bug?
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532713
> >
> > Parsing problem. After reading bug report more detailed I found out it
> > is fixed on pre beta version v30, but it was not released i.e. on Fedora
> > we use wireless-tools v29.
>
> Curious. I have version 30 on Debian, but all of this is *years* old.
> Hah.
>
> > > > Allow to configure PS timeout via nl80211 - add NL80211_ATTR_PS_TIMEOUT
> > > > attribute which become timeout stated in ms.
> > >
> > > Why do you want to be able to set it at all though? I remember having
> > > this discussion years ago, and we said that it wasn't really useful
> > > since the user has no idea when and why this should be changed. I'm not
> > > convinced that changed?
> > >
> > > We had to keep the wext for compatibility - maybe that can now be
> > > removed if you say it's broken - but I'm not sure I see much value in
> > > adding it (and you're doing nothing to convince me otherwise, so far)
> >
> > Zdenek (CCed) reported to me 40% download performance degradation when
> > PS is used. I think this happen because of delay between packets, but
> > it is not confirmed yet (I did not provide patches to Zdenek for
> > testing), hence perhaps problem lies somewere else. I can not reproduce
> > this issue - I have the same download performance with PS on and off,
> > I have quite bad performance when set dynamic PS timeout value less
> > than 20ms, with default 100ms things are fine.
> >
> > I assume we can provide that setting to user space, if it allow to
> > fixup performance with PS ?
>
> I'm not convinced - that'll give you a way to have the bug reporter test
> it, or whatever, but that can also be achieved with debugfs or similar,
> no?
>
> "Regular" users will never even get there, they'll either give up on
> Linux, the machine, the wifi NIC, or live with the low speeds. They'll
> never manipulate things here, and this isn't anything that a userspace
> tool could automatically manipulate either.

iw/iwconfig tools are not only used by regular users but also used by
developers/
engineers. We use it heavily for all our wifi testing, and when
debugging performance
related issue having a configurable ps timeout is of value. We had to
hack the kernel
to change that value (did not had enough time to work on iw/iwconfig).

So IMHO we need to have this configurable either through iw/mac80211 debugfs.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/4] add VHT support to minstrel_ht

[Krishna Chaitanya]

On Sat, Oct 18, 2014 at 10:43 PM, Karl Beldan  wrote:
>
> From: Karl Beldan 
>
>
> Karl Beldan (4):
>   mac80211: minstrel_ht: Increase the range of handled rate indexes
>   mac80211: minstrel_ht: macros adjustments for future VHT_GROUPs
>   mac80211: minstrel_ht: include type (cck/ht) in rates flag
>   mac80211: minstrel_ht: add basic support for VHT rates <= 3SS@80MHz
> v2:
> - typo in Kconfig
> - adjust room in debugfs rc_stats buffer
> - add a module param to mix ht rates with vht ones
> - default to 3SS instead of 2SS (with "mac80211: minstrel_ht: macros
>   adjustments for future VHT_GROUPs")
> - use common MINSTREL_MAX_STREAMS both for VHT and HT so that we can get
>   rid of the 'MINSTREL_MAX_STREAMS >= 3' checks for minstrel_mcs_groups
> v3:
> - put module param *vht_only* under CONFIG_MAC80211_RC_MINSTREL_VHT
>
>  net/mac80211/Kconfig   |   7 +
>  net/mac80211/rc80211_minstrel_ht.c | 292 
> +++--
>  net/mac80211/rc80211_minstrel_ht.h |  38 +++-
>  net/mac80211/rc80211_minstrel_ht_debugfs.c |  32 ++--
>  4 files changed, 290 insertions(+), 79 deletions(-)
>
> --
>
We have been using you patches for some time and they do the work well.
Except for the sampling holes, where we were needed to add some
supported checks.
Thanks for sharing them early.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

SMPS for AP mode confoguration

[Krishna Chaitanya]

Hi,

We are testing SMPS functionality for AP mode. The driver conveys its
capabilities through setting the HT capability which can be set to 0-3.

I wanted to convey support for both Dynamic and Static Powersave
and then control the config through hostapd.conf file. Currently this is
not possible.From driver i can only advertize support for static (or) dynamic
not both (HW_SUPPORTS_* is a different thing which is used in
doing checks at debugfs level).

So if i wanted to configure different modes from hostapd.conf, i
have to change the driver settings as well.

Shouldn't it be the other way around, based on driver's _HW_ flags
we should convey the capabilities to user-space  (currently we use
ht_cap for this) and it will configure the mode from the configuration
file.  I think the design of SMPS configuration should be changed.


-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SMPS for AP mode confoguration

[Krishna Chaitanya]

On Sun, Oct 19, 2014 at 6:51 PM, Eliad Peller  wrote:
> hi,
>
> On Sun, Oct 19, 2014 at 2:50 PM, Krishna Chaitanya
>  wrote:
>> We are testing SMPS functionality for AP mode. The driver conveys its
>> capabilities through setting the HT capability which can be set to 0-3.
>>
>> I wanted to convey support for both Dynamic and Static Powersave
>> and then control the config through hostapd.conf file. Currently this is
>> not possible.From driver i can only advertize support for static (or) dynamic
>> not both (HW_SUPPORTS_* is a different thing which is used in
>> doing checks at debugfs level).
>>
>> So if i wanted to configure different modes from hostapd.conf, i
>> have to change the driver settings as well.
>>
>> Shouldn't it be the other way around, based on driver's _HW_ flags
>> we should convey the capabilities to user-space  (currently we use
>> ht_cap for this) and it will configure the mode from the configuration
>> file.  I think the design of SMPS configuration should be changed.
>>
> this was recently changed. take a look at this patchset:
> http://www.spinics.net/lists/linux-wireless/msg126749.html
>
> we also have a matching supplicant patchset that will probably be
> upstreamed soon.

Thanks Ellad, it looks good to me, will try out them once they are up stream.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi: Reason 7 periodic disconnect

[Krishna Chaitanya]

On Tue, Oct 21, 2014 at 11:01 AM, Emmanuel Grumbach  wrote:
> On Tue, Oct 21, 2014 at 8:02 AM, Emmanuel Grumbach  
> wrote:
>> On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola  wrote:
>>> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
>>> my DHCP client. I also tried various suggestions found on the internet,
>>> but nothing helped.
>>>
>>
>> Can you please try to have another device in monitor mode to sniff the
>> traffic going on?
>> Felix, can you please tell me when DD-WRT can send a deauth with reason code 
>> 7?
>>
>> thanks.
>
> Can you please disable power save?
> For this, please make sure you have
> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=f8dfc607b2b460e8e8adfdfb3c5f5bba3a4ad01b
> or at least have the module parameter.
> I am wondering if the firmware is not sending frames because of power
> save toggling.
>
> I you could get more extensive logs from the AP it'd be great.
> Running tracing on the AP would let us know why it thinks we are not 
> associated.
>
I have faced the same issue before it happens when DUT is in powersave
and for some reason AP authenticates (in this case probably due to
inactivity) but as DUT is in power save we don't Rx the deauth (some
AP's don't wait
for STA to wakeup and retrieve the deauth frame).

So after that if DUT tries to sent any data frame, as it still thinks
that it is connected
(network lost also will not trigger because it still Rx beacon) and in
that case AP deauthenticates
us by Reason:7.

May be if we enable tx status report ACK we can pass the inactivity
check as some AP's
wont reset inactivity timer for probe's.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi: Reason 7 periodic disconnect

[Krishna Chaitanya]

On Tue, Oct 21, 2014 at 12:06 PM, Krishna Chaitanya
 wrote:
> On Tue, Oct 21, 2014 at 11:01 AM, Emmanuel Grumbach  
> wrote:
>> On Tue, Oct 21, 2014 at 8:02 AM, Emmanuel Grumbach  
>> wrote:
>>> On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola  wrote:
>>>> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
>>>> my DHCP client. I also tried various suggestions found on the internet,
>>>> but nothing helped.
>>>>
>>>
>>> Can you please try to have another device in monitor mode to sniff the
>>> traffic going on?
>>> Felix, can you please tell me when DD-WRT can send a deauth with reason 
>>> code 7?
>>>
>>> thanks.
>>
>> Can you please disable power save?
>> For this, please make sure you have
>> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=f8dfc607b2b460e8e8adfdfb3c5f5bba3a4ad01b
>> or at least have the module parameter.
>> I am wondering if the firmware is not sending frames because of power
>> save toggling.
>>
>> I you could get more extensive logs from the AP it'd be great.
>> Running tracing on the AP would let us know why it thinks we are not 
>> associated.
>>
> I have faced the same issue before it happens when DUT is in powersave
> and for some reason AP authenticates (in this case probably due to
*typo: deuauthenticates.

> inactivity) but as DUT is in power save we don't Rx the deauth (some
> AP's don't wait
> for STA to wakeup and retrieve the deauth frame).
>
> So after that if DUT tries to sent any data frame, as it still thinks
> that it is connected
> (network lost also will not trigger because it still Rx beacon) and in
> that case AP deauthenticates
> us by Reason:7.
>
> May be if we enable tx status report ACK we can pass the inactivity
> check as some AP's
> wont reset inactivity timer for probe's.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi: Reason 7 periodic disconnect

[Krishna Chaitanya]

On Tue, Oct 21, 2014 at 12:34 PM, Emmanuel Grumbach  wrote:
> On Tue, Oct 21, 2014 at 9:37 AM, Krishna Chaitanya
>  wrote:
>> On Tue, Oct 21, 2014 at 12:06 PM, Krishna Chaitanya
>>  wrote:
>>> On Tue, Oct 21, 2014 at 11:01 AM, Emmanuel Grumbach  
>>> wrote:
>>>> On Tue, Oct 21, 2014 at 8:02 AM, Emmanuel Grumbach  
>>>> wrote:
>>>>> On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola  
>>>>> wrote:
>>>>>> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
>>>>>> my DHCP client. I also tried various suggestions found on the internet,
>>>>>> but nothing helped.
>>>>>>
>>>>>
>>>>> Can you please try to have another device in monitor mode to sniff the
>>>>> traffic going on?
>>>>> Felix, can you please tell me when DD-WRT can send a deauth with reason 
>>>>> code 7?
>>>>>
>>>>> thanks.
>>>>
>>>> Can you please disable power save?
>>>> For this, please make sure you have
>>>> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=f8dfc607b2b460e8e8adfdfb3c5f5bba3a4ad01b
>>>> or at least have the module parameter.
>>>> I am wondering if the firmware is not sending frames because of power
>>>> save toggling.
>>>>
>>>> I you could get more extensive logs from the AP it'd be great.
>>>> Running tracing on the AP would let us know why it thinks we are not 
>>>> associated.
>>>>
>>> I have faced the same issue before it happens when DUT is in powersave
>>> and for some reason AP authenticates (in this case probably due to
>> *typo: deuauthenticates.
>>
>>> inactivity) but as DUT is in power save we don't Rx the deauth (some
>>> AP's don't wait
>>> for STA to wakeup and retrieve the deauth frame).
>>>
>>> So after that if DUT tries to sent any data frame, as it still thinks
>>> that it is connected
>>> (network lost also will not trigger because it still Rx beacon) and in
>>> that case AP deauthenticates
>>> us by Reason:7.
>>>
>>> May be if we enable tx status report ACK we can pass the inactivity
>>> check as some AP's
>>> wont reset inactivity timer for probe's.
>
> That seems unlikely - we are kicked out after 1 minute?
> Let's check, Laurentiu - can you please ping in the background and see
> what happens?

Yeah, but some Ap's do that :-)
Quote from Laurentiu:

"What I found out in the meanwhile, however, is that active traffic will
prevent the issue from occurring. This happened with the Fedora Live CD,
but pinging the AP is also sufficient. I noticed iwconfig reports that
the power saving mode is off."

So when traffic is there the issue doesn't happen, so it points to inactivity.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi: Reason 7 periodic disconnect

[Krishna Chaitanya]

On Tue, Oct 21, 2014 at 2:05 PM, Felix Fietkau  wrote:
> On 2014-10-21 10:23, Laurențiu Nicola wrote:
>> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
> This is a Broadcom based device, so it should behave in the same way as
> other APs/Routers running the Broadcom drivers.
> The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
> BlockAckReq or Action frame from a station that's not associated, so
> probably it has already kicked out your iwlwifi client earlier. Not sure
> why that doesn't show up in the log though.
>
May be iwlwifi is dozing and did not Rx that frame?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi: Reason 7 periodic disconnect

[Krishna Chaitanya]

On Tue, Oct 21, 2014 at 2:46 PM, Emmanuel Grumbach  wrote:
> On Tue, Oct 21, 2014 at 12:05 PM, Krishna Chaitanya
>  wrote:
>> On Tue, Oct 21, 2014 at 2:05 PM, Felix Fietkau  wrote:
>>> On 2014-10-21 10:23, Laurențiu Nicola wrote:
>>>> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
>>> This is a Broadcom based device, so it should behave in the same way as
>>> other APs/Routers running the Broadcom drivers.
>>> The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
>>> BlockAckReq or Action frame from a station that's not associated, so
>>> probably it has already kicked out your iwlwifi client earlier. Not sure
>>> why that doesn't show up in the log though.
>>>
>> May be iwlwifi is dozing and did not Rx that frame?
>
> yep - this is most probably what happens. iwlwifi goes to sleep and it
> get a deauth that it doesn't hear. Then it wakes up with an NDP and
> gets kicked out.
> But shouldn't the deauth be buffered and indicated through the TIM IE?

Yes, but not all AP's do that, at least the one i faced the issue was
not doing that.



-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html