* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Johannes Berg @ 2013-06-11 12:12 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: Jouni Malinen, Peer, Ilan, linux-wireless@vger.kernel.org,
Rodriguez, Luis, John W . Linville
In-Reply-To: <1894431.CPHELQbCIP@lx-vladimir>
> > ---
> > When probe response offload it supported, the device should not report
> > probe requests to the host that it already responded to. It must report
> > (and therefore not respond to) probe requests that indicate the sending
> > device is in active PBC mode (specifically, <...add more details...>).
> > It may also drop invalid or malformed probe requests or ones that would
> > not be replied to for other reasons.
> > ---
>
> >
> > I think this would be a reasonable tradeoff. It means that if a probe
> > request is actually reported, wpa_supplicant must reply to it, and we
> > don't have to get into the business of having to decide whether or not
> > it needs to respond.
> >
> > Alternatively, we could specify that the device _must_ respond if
> > offload is supported, and then report it.
>
> I like this alternative. Except, reporting is accordingly to the rx filter.
> wpa_s may be not interesting in probes at all, or want only ones with PBC.
> If device answer probes in firmware, this would reduce CPU wake-ups.
Well, wpa_s is always going to be interested, and it can't really
specify in the subscription filter that it only wants PBC ones. The
filters aren't expressive enough for that.
This isn't really my favourite alternative because it means the device
can't just "chicken out" and treat this as a best effort thing, it means
that it always has to reply. I fear that for some devices this might
mean having to reply in software in certain circumstances, which seems
like a bad idea.
> > However, we need to clearly specify this so that we don't get two
> > responses, one from the device and one from wpa_s. If there's no way to
> > specify this, we need to introduce a "reply already sent" flag into the
> > frame reporting.
>
> Said above translates to all-or-nothing approach w.r.t. responses:
>
> - If device indicate probe-resp offload, it must reply all probes, supplicant
> must not send probe-resp.
> - If device does not indicate probe-resp offload, it should never send
> probe-resp by itself; it should report all matching probes
> and supplicant will generate probe-resp.
Right. I guess I can live with this, though see above.
> Regarding what probes to report, I'd specify relaxed requirements
> for the driver:
>
> - in non-offload case, driver must report all matching probes
> (but may just report all, and wpa_s will filter)
> - in offload case, must report matching probes if rx filter says so. It is not
> neccessary to report all probes that device replied to.
see above -- the filters aren't expressive enough to allow specifying "I
want PBC". For probe requests, the filter is going to be all or nothing,
so this won't really do anything useful.
> I don't want to force firmware or driver to parse probes to detect PBC; if we
> got frame to the host, from power perspective there is no much difference who
> will filter it - driver or wpa_s; and wpa_s already do this parsing.
Firmware should parse it, obviously.
> For PBC - can one specify "probes with PBC" using existing rx filter mechanism?
No.
> Also, I feel this explanation get large, it deserves separate comment block,
> it is overkill for start_p2p_find comment. Maybe do it in another patch?
I think we need to nail this down before we merge the API. I have a
feeling we may end up having to implement the third alternative (report
whether a response was sent or not)
johannes
^ permalink raw reply
* Re: [PATCHv4 1/4] mac80211: make mgmt_tx accept a NULL channel
From: Antonio Quartulli @ 2013-06-11 12:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1370952437.8356.26.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]
On Tue, Jun 11, 2013 at 02:07:17PM +0200, Johannes Berg wrote:
> On Tue, 2013-06-11 at 13:57 +0200, Antonio Quartulli wrote:
> > On Tue, Jun 11, 2013 at 01:58:07PM +0200, Johannes Berg wrote:
> > > On Tue, 2013-06-11 at 13:55 +0200, Johannes Berg wrote:
> > > > On Wed, 2013-06-05 at 17:09 +0200, Antonio Quartulli wrote:
> > > >
> > > > > + if (need_offchan && !chan)
> > > > > + return -EINVAL;
> > > >
> > > > > @@ -2847,10 +2853,14 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
> > > > > rcu_read_lock();
> > > > > chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
> > > > >
> > > > > - if (chanctx_conf)
> > > > > - need_offchan = chan != chanctx_conf->def.chan;
> > > > > - else
> > > > > + if (chanctx_conf) {
> > > > > + need_offchan = chan && (chan != chanctx_conf->def.chan);
> > > > > + } else if (!chan) {
> > > > > + ret = -EINVAL;
> > > > > + goto out_unlock;
> > > > > + } else {
> > > > > need_offchan = true;
> > > > > + }
> > > > > rcu_read_unlock();
> > > >
> > > > It seems this would be clearer?
> > > > http://p.sipsolutions.net/b8a03c85f0e8b89f.txt
> > >
> > > Actually, no, I like your version better.
> >
> > uhm, having one else less looks better..why did you change your mind?
> > Maybe you version is not entirely equivalent?
>
> It's not, but that wouldn't matter, it's different I think only if you
> have input from cfg80211 as "!chan && offchan".
>
> It just seems to me that your version is clearer, first you check if you
> need offchan, and if you do but don't have a channel you abort. Then you
> check if you might need offchan for another reason, etc.
yeah. Ok I'll keep my version.
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv4 1/4] mac80211: make mgmt_tx accept a NULL channel
From: Johannes Berg @ 2013-06-11 12:07 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <20130611115722.GD1466@ritirata.org>
On Tue, 2013-06-11 at 13:57 +0200, Antonio Quartulli wrote:
> On Tue, Jun 11, 2013 at 01:58:07PM +0200, Johannes Berg wrote:
> > On Tue, 2013-06-11 at 13:55 +0200, Johannes Berg wrote:
> > > On Wed, 2013-06-05 at 17:09 +0200, Antonio Quartulli wrote:
> > >
> > > > + if (need_offchan && !chan)
> > > > + return -EINVAL;
> > >
> > > > @@ -2847,10 +2853,14 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
> > > > rcu_read_lock();
> > > > chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
> > > >
> > > > - if (chanctx_conf)
> > > > - need_offchan = chan != chanctx_conf->def.chan;
> > > > - else
> > > > + if (chanctx_conf) {
> > > > + need_offchan = chan && (chan != chanctx_conf->def.chan);
> > > > + } else if (!chan) {
> > > > + ret = -EINVAL;
> > > > + goto out_unlock;
> > > > + } else {
> > > > need_offchan = true;
> > > > + }
> > > > rcu_read_unlock();
> > >
> > > It seems this would be clearer?
> > > http://p.sipsolutions.net/b8a03c85f0e8b89f.txt
> >
> > Actually, no, I like your version better.
>
> uhm, having one else less looks better..why did you change your mind?
> Maybe you version is not entirely equivalent?
It's not, but that wouldn't matter, it's different I think only if you
have input from cfg80211 as "!chan && offchan".
It just seems to me that your version is clearer, first you check if you
need offchan, and if you do but don't have a channel you abort. Then you
check if you might need offchan for another reason, etc.
johannes
^ permalink raw reply
* Re: [PATCHv4 1/4] mac80211: make mgmt_tx accept a NULL channel
From: Antonio Quartulli @ 2013-06-11 11:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1370951887.8356.23.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]
On Tue, Jun 11, 2013 at 01:58:07PM +0200, Johannes Berg wrote:
> On Tue, 2013-06-11 at 13:55 +0200, Johannes Berg wrote:
> > On Wed, 2013-06-05 at 17:09 +0200, Antonio Quartulli wrote:
> >
> > > + if (need_offchan && !chan)
> > > + return -EINVAL;
> >
> > > @@ -2847,10 +2853,14 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
> > > rcu_read_lock();
> > > chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
> > >
> > > - if (chanctx_conf)
> > > - need_offchan = chan != chanctx_conf->def.chan;
> > > - else
> > > + if (chanctx_conf) {
> > > + need_offchan = chan && (chan != chanctx_conf->def.chan);
> > > + } else if (!chan) {
> > > + ret = -EINVAL;
> > > + goto out_unlock;
> > > + } else {
> > > need_offchan = true;
> > > + }
> > > rcu_read_unlock();
> >
> > It seems this would be clearer?
> > http://p.sipsolutions.net/b8a03c85f0e8b89f.txt
>
> Actually, no, I like your version better.
uhm, having one else less looks better..why did you change your mind?
Maybe you version is not entirely equivalent?
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv4 1/4] mac80211: make mgmt_tx accept a NULL channel
From: Antonio Quartulli @ 2013-06-11 11:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1370951718.8356.22.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 979 bytes --]
On Tue, Jun 11, 2013 at 01:55:18PM +0200, Johannes Berg wrote:
> On Wed, 2013-06-05 at 17:09 +0200, Antonio Quartulli wrote:
>
> > + if (need_offchan && !chan)
> > + return -EINVAL;
>
> > @@ -2847,10 +2853,14 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
> > rcu_read_lock();
> > chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
> >
> > - if (chanctx_conf)
> > - need_offchan = chan != chanctx_conf->def.chan;
> > - else
> > + if (chanctx_conf) {
> > + need_offchan = chan && (chan != chanctx_conf->def.chan);
> > + } else if (!chan) {
> > + ret = -EINVAL;
> > + goto out_unlock;
> > + } else {
> > need_offchan = true;
> > + }
> > rcu_read_unlock();
>
> It seems this would be clearer?
> http://p.sipsolutions.net/b8a03c85f0e8b89f.txt
agreed :)
I'll include this change.
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv4 1/4] mac80211: make mgmt_tx accept a NULL channel
From: Johannes Berg @ 2013-06-11 11:58 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1370951718.8356.22.camel@jlt4.sipsolutions.net>
On Tue, 2013-06-11 at 13:55 +0200, Johannes Berg wrote:
> On Wed, 2013-06-05 at 17:09 +0200, Antonio Quartulli wrote:
>
> > + if (need_offchan && !chan)
> > + return -EINVAL;
>
> > @@ -2847,10 +2853,14 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
> > rcu_read_lock();
> > chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
> >
> > - if (chanctx_conf)
> > - need_offchan = chan != chanctx_conf->def.chan;
> > - else
> > + if (chanctx_conf) {
> > + need_offchan = chan && (chan != chanctx_conf->def.chan);
> > + } else if (!chan) {
> > + ret = -EINVAL;
> > + goto out_unlock;
> > + } else {
> > need_offchan = true;
> > + }
> > rcu_read_unlock();
>
> It seems this would be clearer?
> http://p.sipsolutions.net/b8a03c85f0e8b89f.txt
Actually, no, I like your version better.
johanes
^ permalink raw reply
* Re: [PATCHv4 4/4] nl80211: allow sending CMD_FRAME without specifying any frequency
From: Antonio Quartulli @ 2013-06-11 11:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1370951598.8356.21.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
On Tue, Jun 11, 2013 at 01:53:18PM +0200, Johannes Berg wrote:
> > + /* get the channel if any has been specified, otherwise pass NULL to
> > + * the driver. The latter will use the current one
> > + */
> > + chandef.chan = NULL;
> > + if (info->attrs[NL80211_ATTR_WIPHY_FREQ]) {
> > + err = nl80211_parse_chandef(rdev, info, &chandef);
> > + if (err)
> > + return err;
> > + }
>
> I think not specifying a channel but setting
> NL80211_ATTR_OFFCHANNEL_TX_OK must be an error.
You are right. Indeed this check is done in mac80211. Other drivers do not use
NL80211_ATTR_OFFCHANNEL_TX_OK at all. But for consistency I guess it would be
correct to do the check here too.
I'll send a new version including this change.
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv4 1/4] mac80211: make mgmt_tx accept a NULL channel
From: Johannes Berg @ 2013-06-11 11:55 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1370444989-2095-1-git-send-email-ordex@autistici.org>
On Wed, 2013-06-05 at 17:09 +0200, Antonio Quartulli wrote:
> + if (need_offchan && !chan)
> + return -EINVAL;
> @@ -2847,10 +2853,14 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
> rcu_read_lock();
> chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
>
> - if (chanctx_conf)
> - need_offchan = chan != chanctx_conf->def.chan;
> - else
> + if (chanctx_conf) {
> + need_offchan = chan && (chan != chanctx_conf->def.chan);
> + } else if (!chan) {
> + ret = -EINVAL;
> + goto out_unlock;
> + } else {
> need_offchan = true;
> + }
> rcu_read_unlock();
It seems this would be clearer?
http://p.sipsolutions.net/b8a03c85f0e8b89f.txt
johannes
^ permalink raw reply
* Re: [PATCHv4 4/4] nl80211: allow sending CMD_FRAME without specifying any frequency
From: Johannes Berg @ 2013-06-11 11:53 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1370444989-2095-4-git-send-email-ordex@autistici.org>
On Wed, 2013-06-05 at 17:09 +0200, Antonio Quartulli wrote:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> Users may want to send a frame on the current channel
> without specifying it.
>
> This is particularly useful for the correct implementation
> of the IBSS/RSN support in wpa_supplicant which requires to
> receive and send AUTH frames.
>
> Make mgmt_tx pass a NULL channel to the driver if none has
> been specified by the user.
>
> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
> ---
>
> v3:
> - moved from 1/4 to 4/4
>
>
> net/wireless/nl80211.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 88e820b..06af395 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -7139,6 +7139,9 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
> return -EOPNOTSUPP;
>
> switch (wdev->iftype) {
> + case NL80211_IFTYPE_P2P_DEVICE:
> + if (!info->attrs[NL80211_ATTR_WIPHY_FREQ])
> + return -EINVAL;
> case NL80211_IFTYPE_STATION:
> case NL80211_IFTYPE_ADHOC:
> case NL80211_IFTYPE_P2P_CLIENT:
> @@ -7146,7 +7149,6 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
> case NL80211_IFTYPE_AP_VLAN:
> case NL80211_IFTYPE_MESH_POINT:
> case NL80211_IFTYPE_P2P_GO:
> - case NL80211_IFTYPE_P2P_DEVICE:
> break;
> default:
> return -EOPNOTSUPP;
> @@ -7174,9 +7176,15 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
>
> no_cck = nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]);
>
> - err = nl80211_parse_chandef(rdev, info, &chandef);
> - if (err)
> - return err;
> + /* get the channel if any has been specified, otherwise pass NULL to
> + * the driver. The latter will use the current one
> + */
> + chandef.chan = NULL;
> + if (info->attrs[NL80211_ATTR_WIPHY_FREQ]) {
> + err = nl80211_parse_chandef(rdev, info, &chandef);
> + if (err)
> + return err;
> + }
I think not specifying a channel but setting
NL80211_ATTR_OFFCHANNEL_TX_OK must be an error.
johannes
^ permalink raw reply
* Re: [RFC 4/5] mac80211: enforce address verification on monitors
From: Johannes Berg @ 2013-06-11 11:46 UTC (permalink / raw)
To: Jakub Kiciński
Cc: Felix Fietkau, linux-wireless, Helmut Schaa,
nietrywialneprzejscie
In-Reply-To: <20130607184210.200dbb52@north>
On Fri, 2013-06-07 at 18:42 +0200, Jakub Kiciński wrote:
> Now I can start two hostapd on those interfaces and
> everything works just fine.
>
> # iw dev wlan0-1 set type monitor
> # ip link set dev wlan0-1 address 00:00:fa:22:7c:00
> # iw dev wlan0-1 set type managed
> # ip link
> 75: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:4f:6a:06:57:90 brd ff:ff:ff:ff:ff:ff
> 76: wlan0-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:00:fa:22:7c:00 brd ff:ff:ff:ff:ff:ff
>
> If I start hostapd on both interfaces now the one on wlan0-1
> will not work correctly (hw won't ack frames).
>
> Also I think it's possible to change active flag on a monitor
> while it's down (check in net/mac80211/cfg.c:75 only applies
> to interfaces that are up):
I think we should "just" move ieee80211_verify_mac() into do_open().
Semantically anyway, I'm clearly handwaving a bit. But I would argue
that you can set any MAC address that you like, as long as you don't
bring the interface up, hence the verification really shouldn't be done
when you assign the address but when you bring it up.
Consider also this. Say you have this scenario:
address mask: 00:00:00:00:00:03
wlan0: 02:00:00:00:00:00
wlan1: 02:00:00:00:00:01
Now you want to change to
wlan0: 03:00:00:00:00:00
wlan1: 03:00:00:00:00:01
It seems that right now you can't do this at all, which also seems
wrong.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Fix bogus RCU warning from ieee80211_get_tx_rates (Was: Re: rcu)
From: Johannes Berg @ 2013-06-11 11:42 UTC (permalink / raw)
To: Calvin Owens; +Cc: linux-wireless, linux-kernel
In-Reply-To: <20130610042959.GA1902@gmail.com>
On Sun, 2013-06-09 at 23:29 -0500, Calvin Owens wrote:
> rate_control_fill_sta_table(), whose sole caller is ieee80211_get_tx_rates(),
> is guaranteed by mac80211 not to be called concurrently with
> rate_control_set_rates() [1], the sole function that touches the rate table
> pointer/data in struct ieee80211_sta. The RCU dereference is therefore safe.
No, this is wrong. ieee80211_get_tx_rates() can be called by drivers in
any context and at any time, that was the whole point of using RCU here.
This needs to be fixed in ath9k, calling ieee80211_get_tx_rates() must
be done under RCU protection.
johannes
^ permalink raw reply
* Re: [PATCH v2 2/2] cfg80211/nl80211: Add packet coalesce support
From: Johannes Berg @ 2013-06-11 11:32 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Bing Zhao, linux-wireless@vger.kernel.org, Luis R. Rodriguez,
Jouni Malinen, Vasanthakumar Thiagarajan, Senthil Balasubramanian,
Luciano Coelho
In-Reply-To: <5FF020A1CFFEEC49BD1E09530C4FF5950F313C2CB5@SC-VEXCH1.marvell.com>
On Mon, 2013-06-03 at 09:47 -0700, Amitkumar Karwar wrote:
> "iw coalesce add" was used, because command for adding multiple rules
> at the same time will be a bit lengthy(user will need to enter
> multiple lists of packet patterns) and syntax check in iw will also
> need some efforts.
I think that this is so much unlike all other nl80211 settings where
they're either refused or replace previous ones entirely that I would
rather not have it. Take connecting for instance, wext allowed you to
set all parameters one by one, etc. This is a bit similar. Also, this
disallows doing checks on the entire configuration easily.
Personally, I see iw as a bit of a test tool so I'm not too concerned
about its sometimes odd command line, but I know giving it lots of
things can be awkward. For TCP wakeup, I've made it parse a small file,
maybe that's an option here as well?
> > Otherwise you're going to have very awkward races and need
> > to always clear etc. The code would also be easier, though obviously
> > you'd need to be able to specify multiple rules at the same time.
>
> For "iw coalesce set" also user needs to always clear the settings
> using "iw coalesce disable". Also similar to "coalesce set", for
> "coalesce add" we clear the settings and free allocations while
> unloading the driver.
>
> Please let us know if you prefer "coalesce set" over "coalesce add".
I would much prefer just having set/clear over piecewise configuration.
johannes
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: update mesh beacon on workqueue
From: Johannes Berg @ 2013-06-11 11:30 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, open80211s, Bob Copeland
In-Reply-To: <1370895442-21784-2-git-send-email-thomas@cozybit.com>
On Mon, 2013-06-10 at 13:17 -0700, Thomas Pedersen wrote:
> + struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
> + u32 bit;
> +
> + /* if we race with running work, worst case this work becomes a noop */
> + for_each_set_bit(bit, (unsigned long *)&changed,
> + sizeof(changed) * BITS_PER_BYTE)
This isn't valid, it happens to work on little endian platforms but will
fail on big endian 64-bit ones, because you have this in memory (0 is
the lowest order nibble):
76 54 32 10 -- -- -- --
and now you point an unsigned long pointer to it, so you interpret the
"--" as the lowest bits.
More generally, I'd argue that mesh is being a bit odd here, flushing
stations turing mesh stop can and will actually cause a BSS info update
after the mesh interface has already been stopped (beaconing has been
disabled in the driver.) This seems rather odd. Maybe it would be better
to move the beacon update out of mesh_sta_cleanup() and into
ieee80211_mesh_housekeeping() in some way? Although it'd also have to be
done in the station handling in cfg.c but that shouldn't be a problem?
Note also that the way you did this is rather odd, ieee80211_stop_mesh()
could cause to schedule out to the workqueue for the update, but then
the update won't happen. It's a bit racy though, because you could stop
and restart the mesh and then the workqueue runs or something? Overall
this approach seems a bit brittle?
johannes
^ permalink raw reply
* Re: [PATCH v2 1/2] mac80211: fix mesh deadlock
From: Johannes Berg @ 2013-06-11 11:15 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, open80211s, Bob Copeland
In-Reply-To: <1370895442-21784-1-git-send-email-thomas@cozybit.com>
On Mon, 2013-06-10 at 13:17 -0700, Thomas Pedersen wrote:
> The patch "cfg80211/mac80211: use cfg80211 wdev mutex in
> mac80211" introduced several deadlocks by converting the
> ifmsh->mtx to wdev->mtx. Solve these by:
>
> 1. drop the cancel_work_sync() in ieee80211_stop_mesh().
> Instead make the mesh work conditional on whether the mesh
> is running or not.
> 2. lock the mesh work with sdata_lock() to protect beacon
> updates and prevent races with wdev->mesh_id_len or
> cfg80211.
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH 0/2] mac80211 fixes
From: Johannes Berg @ 2013-06-11 11:12 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Simon Wunderlich
In-Reply-To: <1370940280-7876-1-git-send-email-siwu@hrz.tu-chemnitz.de>
On Tue, 2013-06-11 at 10:44 +0200, Simon Wunderlich wrote:
> Here are two small mac80211 fixes:
> * I've been seeing a warning when doing DFS tests, which was triggered
> by aborting the CAC when killing hostapd
> * the rate control fix was sent as part of the v3 series of
> "Add support for 5 and 10 MHz channels", but since it's an trivial
> yet important fix I'm adding it to this series too.
Applied, thanks.
johannes
^ permalink raw reply
* [PATCH 2/2] mac80211: Fix rate control mask matching call
From: Simon Wunderlich @ 2013-06-11 8:44 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Simon Wunderlich, Felix Fietkau,
Mathias Kretschmer
In-Reply-To: <1370940280-7876-1-git-send-email-siwu@hrz.tu-chemnitz.de>
The order of parameters was mixed up, introduced in commit
"mac80211: improve the rate control API"
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
net/mac80211/rate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index d3f414f..a02bef3 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -615,7 +615,7 @@ static void rate_control_apply_mask(struct ieee80211_sub_if_data *sdata,
if (rates[i].idx < 0)
break;
- rate_idx_match_mask(&rates[i], sband, mask, chan_width,
+ rate_idx_match_mask(&rates[i], sband, chan_width, mask,
mcs_mask);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] mac80211: abort CAC in stop_ap()
From: Simon Wunderlich @ 2013-06-11 8:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Simon Wunderlich
In-Reply-To: <1370940280-7876-1-git-send-email-siwu@hrz.tu-chemnitz.de>
When a CAC is running and stop_ap is called (e.g. when hostapd is killed
while performing CAC), the CAC must be aborted immediately.
Otherwise ieee80211_stop_ap() will try to stop it when it's too late -
wdev->channel is already NULL and the abort event can not be generated.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
---
net/mac80211/cfg.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 3062210..7f89fc0 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1071,6 +1071,12 @@ static int ieee80211_stop_ap(struct wiphy *wiphy, struct net_device *dev)
clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED);
+ if (sdata->wdev.cac_started) {
+ cancel_delayed_work_sync(&sdata->dfs_cac_timer_work);
+ WARN_ON(local->suspended);
+ cfg80211_cac_event(sdata->dev, NL80211_RADAR_CAC_ABORTED,
+ GFP_KERNEL);
+ }
drv_stop_ap(sdata->local, sdata);
/* free all potentially still buffered bcast frames */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/2] mac80211 fixes
From: Simon Wunderlich @ 2013-06-11 8:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Simon Wunderlich
Here are two small mac80211 fixes:
* I've been seeing a warning when doing DFS tests, which was triggered
by aborting the CAC when killing hostapd
* the rate control fix was sent as part of the v3 series of
"Add support for 5 and 10 MHz channels", but since it's an trivial
yet important fix I'm adding it to this series too.
Cheers,
Simon
Simon Wunderlich (2):
mac80211: abort CAC in stop_ap()
mac80211: Fix rate control mask matching call
net/mac80211/cfg.c | 6 ++++++
net/mac80211/rate.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
--
1.7.10.4
^ permalink raw reply
* Re: Intel Centrino Wireless-N 2200 Tech Support
From: Emmanuel Grumbach @ 2013-06-11 5:41 UTC (permalink / raw)
To: Edward Seyler; +Cc: linux-wireless
In-Reply-To: <20130611042801.GA217@FermiDesk>
> # dmesg | grep iwl
>
> [ 9.868028] iwlwifi 0000:03:00.0: irq 44 for MSI/MSI-X
> [ 9.942668] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1
> [ 10.015848] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG disabled
> [ 10.015861] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
> [ 10.015866] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING enabled
> [ 10.015872] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
> [ 10.015877] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P enabled
> [ 10.015884] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Wireless-N 2200 BGN, REV=0x104
> [ 10.015912] iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
> [ 10.056013] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
> [ 280.878663] iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
> [ 280.886234] iwlwifi 0000:03:00.0: Radio type=0x2-0x0-0x0
> [ 285.886692] iwlwifi 0000:03:00.0: Failed to load firmware chunk!
> [ 285.886888] iwlwifi 0000:03:00.0: Could not load the [0] uCode section
> [ 285.887299] iwlwifi 0000:03:00.0: Failed to run INIT ucode: -110
> [ 285.887516] iwlwifi 0000:03:00.0: Unable to initialize device.
>
This is really weird...
Can you compile with CONFIG_IWLWIFI_DEBUG?
I will then need a few debug prints.
I recently changed this flow to speed up the fw loading process on
platform that can afford a bit amount of DMA, but I just tested it
(again) and it works even if there is not big DMA chunk available.
^ permalink raw reply
* RE: [Ilw] IMPO: URGENT: LINUX IWLEGACY WIRELESS DRIVERS & LINUX VERSION QUESTION
From: Grumbach, Emmanuel @ 2013-06-11 5:36 UTC (permalink / raw)
To: Deniz Kazanci, linux-wireless@vger.kernel.org
Cc: ilw@linux.intel.com, sgruszka@redhat.com
In-Reply-To: <CADvhgjjp2dSCB1yNkOp-XaTkBNQXo3uqaBKU10HVgVwrXPs0jg@mail.gmail.com>
DQpQbGVhc2UgcmVzZW5kIHdpdGhvdXQgc3ViamVjdCBpbiBjYXBpdGFscywgdGhlbiB5b3UnbGwg
aGF2ZSBhIGNoYW5jZSB0byBnbyB0cm91Z2ggdGhlIHNwYW0gZmlsdGVyIG9mIHRoZSBtYWlsaW5n
IGxpc3QuDQoNCg0KSGVsbG8sDQoNCldlIGFyZSBuZXcgdG8gbGludXggZW52aXJvbm1lbnQgYWZ0
ZXIgV2luZG93czsgYW5kIGhhdmUgYSBMZW5vdm8gVjIwMCB3aGljaA0KaGFzIGFuIEludGVswq4g
UFJPL1dpcmVsZXNzIDM5NDVBQkcgY2FyZC4gV2Ugd291bGQgbGlrZSB0byBkb3dubG9hZCBGZWRv
cmENCjE4IG9yIE9wZW5TdXNlIDEyLjMuDQoNCkkgbmVlZCB5b3VyIHVyZ2VudCBoZWxwIHdpdGgg
dGhlIGZvbGxvd2luZyBpdGVtcyBwbGVhc2U6DQoxLiBIb3cgZG8gd2UgY2hhbmdlIHRoZSB0ZXJt
aW5hbCBpbnRvIHJvb3Qgd2hlbiB3ZSBhcmUgbG9nZ2VkIGluIGZyb20gdGhlDQphZG1pbmlzdHJh
dGl2ZSBwcml2aWxpZ2VkIHVzZXIgYWNjb3VudD8NCjIuIEluIHRoZSBodHRwOi8vd2lyZWxlc3Mu
a2VybmVsLm9yZy9lbi91c2Vycy9Ecml2ZXJzL2l3bGVnYWN5IHNpdGUsIDUNCmRpZmZlcmVudCBs
aW5rcyB0byBmaXJtd2FyZSBpcyBnaXZlbiBhcyBiZWxvdzoNCktlcm5lbHMgwqAvIEZpcm13YXJl
DQoyLjYuMjQrIMKgLyBpd2x3aWZpLTM5NDUtdWNvZGUtMi4xNC4xLjUudGd6DQoyLjYuMjQrIMKg
LyBpd2x3aWZpLTM5NDUtdWNvZGUtMTUuMjguMS42LnRneg0KMi42LjI0KyDCoC8gaXdsd2lmaS0z
OTQ1LXVjb2RlLTE1LjI4LjEuOC50Z3oNCjIuNi4yOSsgwqAvIGl3bHdpZmktMzk0NS11Y29kZS0x
NS4yOC4yLjgudGd6DQoyLjYuMjkrIMKgLyBpd2x3aWZpLTM5NDUtdWNvZGUtMTUuMzIuMi45LnRn
eg0KV2hpY2ggb2YgdGhlIGFib3ZlIHByb2dyYW1zIGRvIHdlIGhhdmUgdG8gcnVuIG9uIHRoZSBs
YWJ0b3AgcGxlYXNlPyBXaGF0DQp3b3VsZCBiZSB0aGUgc3RlcHMgdG8gaW5zdGFsbCB0aGUgZHJp
dmVyIHBsZWFzZSBpbiBwbGFpbiBFbmdsaXNoLSB3ZSBmb3VuZA0KdGhlIGxhbmd1YWdlIGdpdmVu
IGluIHRoZSB3ZWJzaXRlIHF1aXRlIGRpZmZpY3VsdCB0byB1bmRlcnN0YW5kPyBUaGFuayB5b3Uu
Lg0KMy4gV2UgYXJlIHVzaW5nIGhlIGxhYnRvYiBmb3IgYnVzaW5lc3MgcHVycG9zZXMgaG93ZXZl
ciB1c2Ugb2YgaW50ZXJuZXQgYW5kDQpvdXRsb29rIGFsb25nIHdpdGggdGhlIG9mZmljZSBwcm9k
dWN0cyBzb21lIChhbHNvIFByb2plY3QgTWFuYWdlbWVudCBUb29scw0KbGlrZSBNUyBQcm9qZWN0
IHNvbWV0aW1lcyksIHNvbWUgbXVzaWMgbGlzdGVuaW5nIGFuZCBzb21lIHZpZGVvIHdhdGNoaW5n
DQpzdWZmaWNlIG91ciBuZWVkcyBvZiB0aGUgY29tcHV0ZXIuIEFtb25nIE9wZW5TdXNlIGFuZCBG
ZWRvcmEgKG9yIG90aGVycyksDQp3aGljaCBvbmUgb2YgdGhlIHByb2R1Y3RzIHdvdWxkIHlvdSBy
ZWNvbW1lbmQgYXMgcGVyIGJlaW5nIHVzZXIgZnJpZW5kbHksDQpyZWxpYWJsZSwgZmFzdCBwbGVh
c2Ugd2l0aCBhIExlbm92byBWMjAwIHBsZWFzZT8NCg0KV2UgYXJlIGxvb2tpbmcgZm9yd2FyZCB0
byBoZWFyaW5nIGJhY2sgZnJvbSB5b3Ugc29vbi4gVGhhbmsgeW91IGtpbmRseSBmb3INCnlvdXIg
aW5mb3JtYXRpb24gYW5kIGF0dGVudGlvbi4NCg0KS2luZCBSZWdhcmRzLA0KRGVuaXogS0FaQU5D
SQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KQSBtZW1iZXIgb2YgdGhlIEludGVsIENvcnBvcmF0aW9uIGdyb3Vw
IG9mIGNvbXBhbmllcwoKVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFp
biBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yCnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg
cmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbgpieSBvdGhlcnMgaXMgc3Ry
aWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCwg
cGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMuCg==
^ permalink raw reply
* Intel Centrino Wireless-N 2200 Tech Support
From: Edward Seyler @ 2013-06-11 4:28 UTC (permalink / raw)
To: linux-wireless
I am having difficulty using my Intel Centrino Wireless-N 2200 PCI-E wireless card. The card is visible but cannot be set "up," either from "ip link" or wpa_supplicant. I am using Arch Linux but have also observed this problem in Ubuntu 12.04 LTS. I have downloaded the firmware from http://wireless.kernel.org/en/users/Drivers/iwlwifi and followed the instructions there on how to copy it into /lib/firmware. Installing Arch Linux's "compat-drivers-patched" package had no effect. Removing all other PCI/PCI-E devices had no effect. My wired ethernet connection is fully functional. Below is the output of several commands that may be relevant, all run as root. Any assistance would be greatly appreciated. Please let me know if I can provide any additional information.
Thank you,
Edward Seyler
# wpa_supplicant -i wlp3s0 -c /etc/wpa_supplicant/my_wpa.conf -D nl80211 -dd
wpa_supplicant v2.0
Successfully initialized wpa_supplicant
Initializing interface 'wlp3s0' conf '/etc/wpa_supplicant/my_wpa.conf' driver 'nl80211' ctrl_interface 'N/A' bridge 'N/A'
Configuration file '/etc/wpa_supplicant/my_wpa.conf' -> '/etc/wpa_supplicant/my_wpa.conf'
Reading configuration file '/etc/wpa_supplicant/my_wpa.conf'
Line: 1 - start of a new network block
BSSID - hexdump(len=6): e0 46 9a 79 75 46
PSK - hexdump(len=32): [REMOVED]
Priority group 0
id=0 ssid=''
nl80211: interface wlp3s0 in phy phy0
rfkill: initial event: idx=0 type=1 op=0 soft=0 hard=0
nl80211: Set mode ifindex 3 iftype 2 (STATION)
nl80211: Subscribe to mgmt frames with non-AP handle 0x1b26740
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=2): 04 0a
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=2): 04 0b
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=2): 04 0c
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=2): 04 0d
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=6): 04 09 50 6f 9a 09
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=5): 7f 50 6f 9a 09
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=1): 06
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=2): 0a 07
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=2): 0a 11
Could not set interface wlp3s0 flags (UP): Connection timed out
nl80211: Could not set interface 'wlp3s0' UP
netlink: Operstate: linkmode=0, operstate=6
nl80211: Set mode ifindex 3 iftype 2 (STATION)
nl80211: Unsubscribe mgmt frames handle 0x1b26740 (mode change)
wlp3s0: Failed to initialize driver interface
Failed to add interface wlp3s0
wlp3s0: Cancelling scan request
wlp3s0: Cancelling authentication timeout
(running this command, or ip link set wlp3s0 up, a second time causes the system to lock up)
# dmesg | grep iwl
[ 9.868028] iwlwifi 0000:03:00.0: irq 44 for MSI/MSI-X
[ 9.942668] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1
[ 10.015848] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG disabled
[ 10.015861] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[ 10.015866] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING enabled
[ 10.015872] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
[ 10.015877] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P enabled
[ 10.015884] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Wireless-N 2200 BGN, REV=0x104
[ 10.015912] iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
[ 10.056013] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[ 280.878663] iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
[ 280.886234] iwlwifi 0000:03:00.0: Radio type=0x2-0x0-0x0
[ 285.886692] iwlwifi 0000:03:00.0: Failed to load firmware chunk!
[ 285.886888] iwlwifi 0000:03:00.0: Could not load the [0] uCode section
[ 285.887299] iwlwifi 0000:03:00.0: Failed to run INIT ucode: -110
[ 285.887516] iwlwifi 0000:03:00.0: Unable to initialize device.
# uname -a
Linux FermiDesk 3.9.5-1-ARCH #1 SMP PREEMPT Sat Jun 8 09:22:45 CEST 2013 x86_64 GNU/Linux
# lspci -vvv | tail -n 35
03:00.0 Network controller: Intel Corporation Centrino Wireless-N 2200 (rev c4)
Subsystem: Intel Corporation Centrino Wireless-N 2200 BGN
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 44
Region 0: Memory at efffe000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 41d1
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <32us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 9c-4e-36-ff-ff-19-1a-8c
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether bc:5f:f4:82:28:91 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 9c:4e:36:19:1a:8c brd ff:ff:ff:ff:ff:ff
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 100
link/none
# iwconfig
tun0 no wireless extensions.
enp0s7 no wireless extensions.
lo no wireless extensions.
wlp3s0 IEEE 802.11bgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
# rfkill list all
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
# lsmod | grep iw
iwldvm 173046 0
mac80211 495646 1 iwldvm
iwlwifi 143110 1 iwldvm
cfg80211 454778 3 iwlwifi,mac80211,iwldvm
compat 1357 4 cfg80211,iwlwifi,mac80211,iwldvm
^ permalink raw reply
* Re: [RFT/RFC 0/4] iwlegacy: workaround for firmware frame tx rejection
From: Jake Edge @ 2013-06-11 3:41 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20130610143848.7afd5acc@chukar.edge2.net>
On Mon, 10 Jun 2013 14:38:48 -0600 Jake Edge wrote:
> > Please apply it together with this mac80211 patch:
> > http://marc.info/?l=linux-wireless&m=136879090123023&w=2
> > which I already posted and is queued to upstream. Not having
> > it may cause troubles and influence negatively this set test.
>
> I tried it on both 3.9 (without 4/4 since it doesn't have that
> workaround in it) and on 3.10-rc4 and in both cases, i get the same
> behavior: it tries to connect many times and fails, then eventually
> connects (after like 20 tries from KDE network manager) ...
actually, i spoke too soon, the 3.10-rc4 has not been able to connect
at all, after many hours of trying. I manually went in and selected
the other 2.4GHz SSID (rather than the 5GHz it had been trying) and it
connected right away, fwiw ...
jake
--
Jake Edge - LWN - jake@lwn.net - http://lwn.net
^ permalink raw reply
* [PATCH RESEND] mwifiex: enable/disable tx_amsdu support via module parameter
From: Bing Zhao @ 2013-06-10 22:39 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
From: Avinash Patil <patila@marvell.com>
This patch disables tx_amsdu support in mwifiex by default.
tx_amdsu support can be enabled via module parameter at load time.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/wmm.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mwifiex/wmm.c b/drivers/net/wireless/mwifiex/wmm.c
index 4be3d33..944e884 100644
--- a/drivers/net/wireless/mwifiex/wmm.c
+++ b/drivers/net/wireless/mwifiex/wmm.c
@@ -37,6 +37,9 @@
/* Offset for TOS field in the IP header */
#define IPTOS_OFFSET 5
+static bool enable_tx_amsdu;
+module_param(enable_tx_amsdu, bool, 0644);
+
/* WMM information IE */
static const u8 wmm_info_ie[] = { WLAN_EID_VENDOR_SPECIFIC, 0x07,
0x00, 0x50, 0xf2, 0x02,
@@ -1233,7 +1236,7 @@ mwifiex_dequeue_tx_packet(struct mwifiex_adapter *adapter)
mwifiex_send_delba(priv, tid_del, ra, 1);
}
}
- if (mwifiex_is_amsdu_allowed(priv, tid) &&
+ if (enable_tx_amsdu && mwifiex_is_amsdu_allowed(priv, tid) &&
mwifiex_is_11n_aggragation_possible(priv, ptr,
adapter->tx_buf_size))
mwifiex_11n_aggregate_pkt(priv, ptr, INTF_HEADER_LEN,
--
1.8.2.3
^ permalink raw reply related
* [PATCH RESEND] mwifiex: fix regression issue for usb interface
From: Bing Zhao @ 2013-06-10 22:39 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
From: Amitkumar Karwar <akarwar@marvell.com>
PATCH "mwifiex: scan delay timer cleanup in unload path" adds code
to cancel scan delay timer in unload path. It causes a regression
for USB interface.
USB8797 card gets enumerated twice. First enumeration is for
firmware download and second enumeration expects firmware
initialization.
It was observed that we are trying del_timer_sync() without setting
up the timer when remove handler is called after first enumeration.
This patch moves setup_timer() call to appropriate place so that
timer is setup for both the enumerations.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/init.c | 81 ------------------------------------
drivers/net/wireless/mwifiex/main.c | 82 +++++++++++++++++++++++++++++++++++++
2 files changed, 82 insertions(+), 81 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/init.c b/drivers/net/wireless/mwifiex/init.c
index c7f11c0..2fe31dc 100644
--- a/drivers/net/wireless/mwifiex/init.c
+++ b/drivers/net/wireless/mwifiex/init.c
@@ -52,84 +52,6 @@ static int mwifiex_add_bss_prio_tbl(struct mwifiex_private *priv)
return 0;
}
-static void scan_delay_timer_fn(unsigned long data)
-{
- struct mwifiex_private *priv = (struct mwifiex_private *)data;
- struct mwifiex_adapter *adapter = priv->adapter;
- struct cmd_ctrl_node *cmd_node, *tmp_node;
- unsigned long flags;
-
- if (adapter->surprise_removed)
- return;
-
- if (adapter->scan_delay_cnt == MWIFIEX_MAX_SCAN_DELAY_CNT) {
- /*
- * Abort scan operation by cancelling all pending scan
- * commands
- */
- spin_lock_irqsave(&adapter->scan_pending_q_lock, flags);
- list_for_each_entry_safe(cmd_node, tmp_node,
- &adapter->scan_pending_q, list) {
- list_del(&cmd_node->list);
- mwifiex_insert_cmd_to_free_q(adapter, cmd_node);
- }
- spin_unlock_irqrestore(&adapter->scan_pending_q_lock, flags);
-
- spin_lock_irqsave(&adapter->mwifiex_cmd_lock, flags);
- adapter->scan_processing = false;
- adapter->scan_delay_cnt = 0;
- adapter->empty_tx_q_cnt = 0;
- spin_unlock_irqrestore(&adapter->mwifiex_cmd_lock, flags);
-
- if (priv->scan_request) {
- dev_dbg(adapter->dev, "info: aborting scan\n");
- cfg80211_scan_done(priv->scan_request, 1);
- priv->scan_request = NULL;
- } else {
- priv->scan_aborting = false;
- dev_dbg(adapter->dev, "info: scan already aborted\n");
- }
- goto done;
- }
-
- if (!atomic_read(&priv->adapter->is_tx_received)) {
- adapter->empty_tx_q_cnt++;
- if (adapter->empty_tx_q_cnt == MWIFIEX_MAX_EMPTY_TX_Q_CNT) {
- /*
- * No Tx traffic for 200msec. Get scan command from
- * scan pending queue and put to cmd pending queue to
- * resume scan operation
- */
- adapter->scan_delay_cnt = 0;
- adapter->empty_tx_q_cnt = 0;
- spin_lock_irqsave(&adapter->scan_pending_q_lock, flags);
- cmd_node = list_first_entry(&adapter->scan_pending_q,
- struct cmd_ctrl_node, list);
- list_del(&cmd_node->list);
- spin_unlock_irqrestore(&adapter->scan_pending_q_lock,
- flags);
-
- mwifiex_insert_cmd_to_pending_q(adapter, cmd_node,
- true);
- queue_work(adapter->workqueue, &adapter->main_work);
- goto done;
- }
- } else {
- adapter->empty_tx_q_cnt = 0;
- }
-
- /* Delay scan operation further by 20msec */
- mod_timer(&priv->scan_delay_timer, jiffies +
- msecs_to_jiffies(MWIFIEX_SCAN_DELAY_MSEC));
- adapter->scan_delay_cnt++;
-
-done:
- if (atomic_read(&priv->adapter->is_tx_received))
- atomic_set(&priv->adapter->is_tx_received, false);
-
- return;
-}
-
/*
* This function initializes the private structure and sets default
* values to the members.
@@ -211,9 +133,6 @@ int mwifiex_init_priv(struct mwifiex_private *priv)
priv->scan_block = false;
- setup_timer(&priv->scan_delay_timer, scan_delay_timer_fn,
- (unsigned long)priv);
-
return mwifiex_add_bss_prio_tbl(priv);
}
diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
index 5bc7ef8..4858719 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -28,6 +28,84 @@ const char driver_version[] = "mwifiex " VERSION " (%s) ";
static char *cal_data_cfg;
module_param(cal_data_cfg, charp, 0);
+static void scan_delay_timer_fn(unsigned long data)
+{
+ struct mwifiex_private *priv = (struct mwifiex_private *)data;
+ struct mwifiex_adapter *adapter = priv->adapter;
+ struct cmd_ctrl_node *cmd_node, *tmp_node;
+ unsigned long flags;
+
+ if (adapter->surprise_removed)
+ return;
+
+ if (adapter->scan_delay_cnt == MWIFIEX_MAX_SCAN_DELAY_CNT) {
+ /*
+ * Abort scan operation by cancelling all pending scan
+ * commands
+ */
+ spin_lock_irqsave(&adapter->scan_pending_q_lock, flags);
+ list_for_each_entry_safe(cmd_node, tmp_node,
+ &adapter->scan_pending_q, list) {
+ list_del(&cmd_node->list);
+ mwifiex_insert_cmd_to_free_q(adapter, cmd_node);
+ }
+ spin_unlock_irqrestore(&adapter->scan_pending_q_lock, flags);
+
+ spin_lock_irqsave(&adapter->mwifiex_cmd_lock, flags);
+ adapter->scan_processing = false;
+ adapter->scan_delay_cnt = 0;
+ adapter->empty_tx_q_cnt = 0;
+ spin_unlock_irqrestore(&adapter->mwifiex_cmd_lock, flags);
+
+ if (priv->scan_request) {
+ dev_dbg(adapter->dev, "info: aborting scan\n");
+ cfg80211_scan_done(priv->scan_request, 1);
+ priv->scan_request = NULL;
+ } else {
+ priv->scan_aborting = false;
+ dev_dbg(adapter->dev, "info: scan already aborted\n");
+ }
+ goto done;
+ }
+
+ if (!atomic_read(&priv->adapter->is_tx_received)) {
+ adapter->empty_tx_q_cnt++;
+ if (adapter->empty_tx_q_cnt == MWIFIEX_MAX_EMPTY_TX_Q_CNT) {
+ /*
+ * No Tx traffic for 200msec. Get scan command from
+ * scan pending queue and put to cmd pending queue to
+ * resume scan operation
+ */
+ adapter->scan_delay_cnt = 0;
+ adapter->empty_tx_q_cnt = 0;
+ spin_lock_irqsave(&adapter->scan_pending_q_lock, flags);
+ cmd_node = list_first_entry(&adapter->scan_pending_q,
+ struct cmd_ctrl_node, list);
+ list_del(&cmd_node->list);
+ spin_unlock_irqrestore(&adapter->scan_pending_q_lock,
+ flags);
+
+ mwifiex_insert_cmd_to_pending_q(adapter, cmd_node,
+ true);
+ queue_work(adapter->workqueue, &adapter->main_work);
+ goto done;
+ }
+ } else {
+ adapter->empty_tx_q_cnt = 0;
+ }
+
+ /* Delay scan operation further by 20msec */
+ mod_timer(&priv->scan_delay_timer, jiffies +
+ msecs_to_jiffies(MWIFIEX_SCAN_DELAY_MSEC));
+ adapter->scan_delay_cnt++;
+
+done:
+ if (atomic_read(&priv->adapter->is_tx_received))
+ atomic_set(&priv->adapter->is_tx_received, false);
+
+ return;
+}
+
/*
* This function registers the device and performs all the necessary
* initializations.
@@ -75,6 +153,10 @@ static int mwifiex_register(void *card, struct mwifiex_if_ops *if_ops,
adapter->priv[i]->adapter = adapter;
adapter->priv_num++;
+
+ setup_timer(&adapter->priv[i]->scan_delay_timer,
+ scan_delay_timer_fn,
+ (unsigned long)adapter->priv[i]);
}
mwifiex_init_lock_list(adapter);
--
1.8.2.3
^ permalink raw reply related
* [PATCH] mwifiex: Add module parameter for regdomain
From: Bing Zhao @ 2013-06-10 22:40 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao,
Paul Stewart
From: Avinash Patil <patila@marvell.com>
Allow a regulatory domain country code to be specified at boot
using a module argument. This overrides the firmware regulatory
mode.
This patch also enables uAP to operate in 11a mode with hostapd.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/cfg80211.c | 29 +++++++++++++++++++++++++----
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c
index 00a8281..0d27952 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -20,6 +20,9 @@
#include "cfg80211.h"
#include "main.h"
+static char *reg_alpha2;
+module_param(reg_alpha2, charp, 0);
+
static const struct ieee80211_iface_limit mwifiex_ap_sta_limits[] = {
{
.max = 2, .types = BIT(NL80211_IFTYPE_STATION),
@@ -2475,6 +2478,17 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
#endif
};
+static bool mwifiex_is_valid_alpha2(const char *alpha2)
+{
+ if (!alpha2 || strlen(alpha2) != 2)
+ return false;
+
+ if (isalpha(alpha2[0]) && isalpha(alpha2[1]))
+ return true;
+
+ return false;
+}
+
/*
* This function registers the device with CFG802.11 subsystem.
*
@@ -2527,6 +2541,7 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
WIPHY_FLAG_AP_PROBE_RESP_OFFLOAD |
WIPHY_FLAG_AP_UAPSD |
WIPHY_FLAG_CUSTOM_REGULATORY |
+ WIPHY_FLAG_STRICT_REGULATORY |
WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
wiphy_apply_custom_regulatory(wiphy, &mwifiex_world_regdom_custom);
@@ -2568,10 +2583,16 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
wiphy_free(wiphy);
return ret;
}
- country_code = mwifiex_11d_code_2_region(priv->adapter->region_code);
- if (country_code)
- dev_info(adapter->dev,
- "ignoring F/W country code %2.2s\n", country_code);
+
+ if (reg_alpha2 && mwifiex_is_valid_alpha2(reg_alpha2)) {
+ wiphy_info(wiphy, "driver hint alpha2: %2.2s\n", reg_alpha2);
+ regulatory_hint(wiphy, reg_alpha2);
+ } else {
+ country_code = mwifiex_11d_code_2_region(adapter->region_code);
+ if (country_code)
+ wiphy_info(wiphy, "ignoring F/W country code %2.2s\n",
+ country_code);
+ }
adapter->wiphy = wiphy;
return ret;
--
1.8.2.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox