* 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] 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: [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: [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: [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: 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: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 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: 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: 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 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: [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: [PATCH] nl80211: add kernel-doc for NL80211_FEATURE_ACTIVE_MONITOR
From: Johannes Berg @ 2013-06-11 12:14 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <1370275845-97370-1-git-send-email-nbd@openwrt.org>
Applied.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] {nl,cfg}80211: make peer link expiration time configurable
From: Johannes Berg @ 2013-06-11 12:17 UTC (permalink / raw)
To: Colleen Twitty; +Cc: linux-wirelss, open80211s
In-Reply-To: <1370278420-10135-1-git-send-email-colleen@cozybit.com>
On Mon, 2013-06-03 at 09:53 -0700, Colleen Twitty wrote:
> If a STA has a peer that it hasn't seen any tx activity
> from for a certain length of time, the peer link is
> expired. This means the inactive STA is removed from the
> list of peers and that STA is not considered a peer again
> unless it re-peers. Previously, this inactivity time was
> always 30 minutes. Now, add it to the mesh configuration
> and allow it to be configured. Retain 30 minutes as a
> default value.
Applied both.
johannes
^ permalink raw reply
* [PATCHv5 1/4] mac80211: make mgmt_tx accept a NULL channel
From: Antonio Quartulli @ 2013-06-11 12:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
From: Antonio Quartulli <antonio@open-mesh.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case. Fail if offchan is required.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
net/mac80211/cfg.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 3062210..617c5c8 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2838,6 +2838,12 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
return -EOPNOTSUPP;
}
+ /* configurations requiring offchan cannot work if no channel has been
+ * specified
+ */
+ if (need_offchan && !chan)
+ return -EINVAL;
+
mutex_lock(&local->mtx);
/* Check if the operating channel is the requested channel */
@@ -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();
}
--
1.8.1.5
^ permalink raw reply related
* [PATCHv5 3/4] ath6kl: make mgmt_tx accept a NULL channel
From: Antonio Quartulli @ 2013-06-11 12:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli, Nicolas Cavallari
In-Reply-To: <1370953203-4086-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case
Cc: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
Acked-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index f7995b2..2437ad2 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3175,10 +3175,21 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
{
struct ath6kl_vif *vif = ath6kl_vif_from_wdev(wdev);
struct ath6kl *ar = ath6kl_priv(vif->ndev);
- u32 id;
+ u32 id, freq;
const struct ieee80211_mgmt *mgmt;
bool more_data, queued;
+ /* default to the current channel, but use the one specified as argument
+ * if any
+ */
+ freq = vif->ch_hint;
+ if (chan)
+ freq = chan->center_freq;
+
+ /* never send freq zero to the firmware */
+ if (WARN_ON(freq == 0))
+ return -EINVAL;
+
mgmt = (const struct ieee80211_mgmt *) buf;
if (vif->nw_type == AP_NETWORK && test_bit(CONNECTED, &vif->flags) &&
ieee80211_is_probe_resp(mgmt->frame_control) &&
@@ -3188,8 +3199,7 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
* command to allow the target to fill in the generic IEs.
*/
*cookie = 0; /* TX status not supported */
- return ath6kl_send_go_probe_resp(vif, buf, len,
- chan->center_freq);
+ return ath6kl_send_go_probe_resp(vif, buf, len, freq);
}
id = vif->send_action_id++;
@@ -3205,17 +3215,14 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
/* AP mode Power saving processing */
if (vif->nw_type == AP_NETWORK) {
- queued = ath6kl_mgmt_powersave_ap(vif,
- id, chan->center_freq,
- wait, buf,
- len, &more_data, no_cck);
+ queued = ath6kl_mgmt_powersave_ap(vif, id, freq, wait, buf, len,
+ &more_data, no_cck);
if (queued)
return 0;
}
- return ath6kl_wmi_send_mgmt_cmd(ar->wmi, vif->fw_vif_idx, id,
- chan->center_freq, wait,
- buf, len, no_cck);
+ return ath6kl_wmi_send_mgmt_cmd(ar->wmi, vif->fw_vif_idx, id, freq,
+ wait, buf, len, no_cck);
}
static void ath6kl_mgmt_frame_register(struct wiphy *wiphy,
--
1.8.1.5
^ permalink raw reply related
* [PATCHv5 2/4] brcm80211: make mgmt_tx in brcmfmac accept a NULL channel
From: Antonio Quartulli @ 2013-06-11 12:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli, brcm80211-dev-list
In-Reply-To: <1370953203-4086-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case
Cc: brcm80211-dev-list@broadcom.com
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index 6d758f2..8bd256b 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -3917,6 +3917,7 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
struct brcmf_fil_af_params_le *af_params;
bool ack;
s32 chan_nr;
+ u32 freq;
brcmf_dbg(TRACE, "Enter\n");
@@ -3929,6 +3930,8 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
return -EPERM;
}
+ vif = container_of(wdev, struct brcmf_cfg80211_vif, wdev);
+
if (ieee80211_is_probe_resp(mgmt->frame_control)) {
/* Right now the only reason to get a probe response */
/* is for p2p listen response or for p2p GO from */
@@ -3944,7 +3947,6 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
ie_offset = DOT11_MGMT_HDR_LEN +
DOT11_BCN_PRB_FIXED_LEN;
ie_len = len - ie_offset;
- vif = container_of(wdev, struct brcmf_cfg80211_vif, wdev);
if (vif == cfg->p2p.bss_idx[P2PAPI_BSSCFG_PRIMARY].vif)
vif = cfg->p2p.bss_idx[P2PAPI_BSSCFG_DEVICE].vif;
err = brcmf_vif_set_mgmt_ie(vif,
@@ -3968,8 +3970,15 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
memcpy(&af_params->bssid[0], &mgmt->bssid[0], ETH_ALEN);
/* Add the length exepted for 802.11 header */
action_frame->len = cpu_to_le16(len - DOT11_MGMT_HDR_LEN);
- /* Add the channel */
- chan_nr = ieee80211_frequency_to_channel(chan->center_freq);
+ /* Add the channel. Use the one specified as parameter if any or
+ * the current one (got from the firmware) otherwise
+ */
+ if (chan)
+ freq = chan->center_freq;
+ else
+ brcmf_fil_cmd_int_get(vif->ifp, BRCMF_C_GET_CHANNEL,
+ &freq);
+ chan_nr = ieee80211_frequency_to_channel(freq);
af_params->channel = cpu_to_le32(chan_nr);
memcpy(action_frame->data, &buf[DOT11_MGMT_HDR_LEN],
--
1.8.1.5
^ permalink raw reply related
* [PATCHv5 4/4] nl80211: allow sending CMD_FRAME without specifying any frequency
From: Antonio Quartulli @ 2013-06-11 12:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1370953203-4086-1-git-send-email-ordex@autistici.org>
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>
---
v5:
- return -EINVAL if NL80211_ATTR_WIPHY_FREQ is set while
NL80211_ATTR_OFFCHANNEL_TX_OK is not
net/wireless/nl80211.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 88e820b..d8f43df 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,18 @@ 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;
+ }
+
+ if (!chandef.chan && offchan)
+ return -EINVAL;
if (!dont_wait_for_ack) {
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH v2] {nl,mac,cfg}80211: Allow user to configure basic rates for mesh
From: Johannes Berg @ 2013-06-11 12:25 UTC (permalink / raw)
To: Ashok Nagarajan; +Cc: linux-wireless, linville, devel, javier
In-Reply-To: <1370280816-9799-1-git-send-email-ashok@cozybit.com>
On Mon, 2013-06-03 at 10:33 -0700, Ashok Nagarajan wrote:
> Currently mesh uses mandatory rates as the default basic rates. Allow basic
> rates to be configured during mesh join. Basic rates are applied only if
> channel is also provided with mesh join command.
Applied, I fixed some whitespace and made it remove rates specification
w/o channel specification. Please check.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] iw: Allow user to provide freq during mesh join
From: Johannes Berg @ 2013-06-11 12:26 UTC (permalink / raw)
To: Ashok Nagarajan; +Cc: linux-wireless, linville, devel, javier
In-Reply-To: <1370280859-9860-1-git-send-email-ashok@cozybit.com>
On Mon, 2013-06-03 at 10:34 -0700, Ashok Nagarajan wrote:
> Allow user to configure frequency and channel type during mesh join command.
>
> Signed-off-by: Ashok Nagarajan <ashok@cozybit.com>
> ---
> mesh.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++---
> 1 files changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/mesh.c b/mesh.c
> index 5a09b62..ec202c9 100644
> --- a/mesh.c
> +++ b/mesh.c
> @@ -431,8 +431,18 @@ static int join_mesh(struct nl80211_state *state, struct nl_cb *cb,
> {
> struct nlattr *container;
> float rate;
> - int bintval, dtim_period;
> + int bintval, dtim_period, i;
> char *end;
> + static const struct {
> + const char *name;
> + unsigned int val;
> + } htmap[] = {
> + { .name = "HT20", .val = NL80211_CHAN_HT20, },
> + { .name = "HT40+", .val = NL80211_CHAN_HT40PLUS, },
> + { .name = "HT40-", .val = NL80211_CHAN_HT40MINUS, },
> + { .name = "NOHT", .val = NL80211_CHAN_NO_HT, },
> + };
I think you should use chandefs already, to allow for VHT. Also, it'd be
good to refactor the channel parsing for this, monitor and IBSS (though
I wonder why I haven't done that already?)
johannes
^ permalink raw reply
* Re: [RFC 0/4] add master channel switch announcement support
From: Johannes Berg @ 2013-06-11 12:31 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <20130514092734.GA16426@pandem0nium>
> > > * channels are announced by adding IEs (CSA and Extended CSA) in beacons
> > > * after some (configurable) time, the channel is switched
> > > * with the channel switch, CSA/ECSA IEs are removed and channel information
> > > is updated.
> > > * Userspace calls a new command NL80211_CMD_CHANNEL_SWITCH along with channel info
> > > (freq + width), whether traffic should be blocked and timing information
> > > * it currently works for me [TM] on my ath9k based machine
> >
> > I don't really like your approach of building all the IEs in the kernel.
> > There are some things, like the country-after-switch in the CSA wrapper
> > (introduced in 11ac), that would be really awkward this way.
>
> Hmm ... OK. I have not checked 802.11ac yet (actually I don't have access to the
> drafts anyway). So what we have to expect is changing the country after the switch,
> or also other new things?
There are a few things in the channel switch wrapper: new country, wide
bandwidth channel switch, new VHT transmit power envelope. I guess the
intention is to allow for extensions in the future.
> > > * could other drivers (next to ath9k) work with this API?
> >
> > Probably not easily. Any TI folks reading this?
>
> I was thinking about adding another callback function or option for that for drivers
> who do the channel switch internally. Then we would only need mac80211 to adapt.
>
> Would that help, or what would be problematic?
I don't really know. If you look at what we do in managed mode now, some
drivers will do the switching and report back when done.
> Yeah, that would be an alternative. I've been inspired by IEEE 802.11-2012/6.3.17
> (MLME-CHANNELSWITCH) originally. :)
> I think your suggestion is good for AP where we control the beacon. For IBSS it
> would be a little different: when a channel switch is triggered, userspace does
> not know the beacon (and will not set it). Therefore, we could only accept the
> change IEs and skip the "after-switch-beacon" IEs (these would be re-generated
> internally) in IBSS mode. I guess it would be similar for mesh.
Yeah, agree, IBSS/mesh modes are somewhat different here, userspace
doesn't really know the channel is switching at all, does it?
johannes
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Allow TDLS peer AID to be configured for VHT
From: Johannes Berg @ 2013-06-11 12:37 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <20130527152402.GC12369@jouni.qca.qualcomm.com>
On Mon, 2013-05-27 at 18:24 +0300, Jouni Malinen wrote:
> VHT uses peer AID in the PARTIAL_AID field in TDLS frames. The current
> design for TDLS is to first add a dummy STA entry before completing TDLS
> Setup and then update information on this STA entry based on what was
> received from the peer during the setup exchange.
>
> In theory, this could use NL80211_ATTR_STA_AID to set the peer AID just
> like this is used in AP mode to set the AID of an association station.
> However, existing cfg80211 validation rules prevent this attribute from
> being used with set_station operation. To avoid interoperability issues
> between different kernel and user space version combinations, introduce
> a new nl80211 attribute for the purpose of setting TDLS peer AID. This
> attribute can be used in both the new_station and set_station
> operations. It is not supposed to be allowed to change the AID value
> during the lifetime of the STA entry, but that validation is left for
> drivers to do in the change_station callback.
Hmm. I guess I accidentally applied the first version, I've now applied
the differences.
johannes
^ permalink raw reply
* rtl8192cu: slow path warning and connection problem v3.10-rc5
From: Richard GENOUD @ 2013-06-11 12:38 UTC (permalink / raw)
To: Larry Finger; +Cc: Chaoming Li, John W. Linville, linux-wireless, linux-kernel
Hi,
I've got an usb wireless adapter TP-Link TL-WN725N
http://www.tp-link.com/ca/products/details/?categoryid=241&model=TL-WN725N
It is based on the rtl8192cu chip.
I'm running a recent kernel (3.10-rc5) on a arm-based board (at91sam9g35-ek).
and last linux-firmwares (2892af0)
The problem I've got it that the device authenticates to the AP
(with a slow path warning), but there's no traffic (I can't get an IP
address from DHCP for example).
Here is the log:
***Insert the TP-Link key
[ 22.710937] usb 1-2.3: new high-speed USB device number 3 using atmel-ehci
[ 22.828125] rtl8192cu: Chip version 0x10
[ 22.921875] rtl8192cu: MAC address: a0:f3:c1:1a:28:5f
[ 22.929687] rtl8192cu: Board Type 0
[ 22.929687] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
[ 22.937500] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin
[ 22.953125] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[ 22.968750] rtlwifi: wireless switch is on
# ip link set wlan0 up
[ 34.656250] rtl8192cu: MAC auto ON okay!
[ 34.695312] rtl8192cu: Tx queue select: 0x05
# iw dev wlan0 scan
BSS 00:1c:10:69:90:fe (on wlan0)
TSF: 1046528539 usec (0d, 00:17:26)
freq: 2412
beacon interval: 100
capability: ESS ShortSlotTime (0x0401)
signal: -58.00 dBm
last seen: 500 ms ago
Information elements from Probe Response frame:
SSID: test
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
DS Parameter set: channel 1
TIM: DTIM Count 1 DTIM Period 2 Bitmap Control 0x0 Bitmap[0] 0x0
ERP: Barker_Preamble_Mode
Extended supported rates: 24.0 36.0 48.0 54.0
# iw wlan0 connect test
[ 51.851562] wlan0: authenticate with 00:1c:10:69:90:fe
[ 51.859375] wlan0: Allocated STA 00:1c:10:69:90:fe
[ 51.867187] wlan0: Inserted STA 00:1c:10:69:90:fe
[ 51.875000] wlan0: direct probe to 00:1c:10:69:90:fe (try 1/3)
# [ 52.078125] wlan0: direct probe to 00:1c:10:69:90:fe (try 2/3)
[ 52.281250] wlan0: direct probe to 00:1c:10:69:90:fe (try 3/3)
[ 52.484375] wlan0: authentication with 00:1c:10:69:90:fe timed out
[ 52.484375] wlan0: Removed STA 00:1c:10:69:90:fe
[ 52.492187] wlan0: Destroyed STA 00:1c:10:69:90:fe
# iw wlan0 connect test
# [ 70.718750] wlan0: authenticate with 00:1c:10:69:90:fe
[ 70.718750] wlan0: Allocated STA 00:1c:10:69:90:fe
[ 70.742187] wlan0: Inserted STA 00:1c:10:69:90:fe
[ 70.742187] wlan0: send auth to 00:1c:10:69:90:fe (try 1/3)
[ 70.757812] wlan0: authenticated
[ 70.757812] wlan0: moving STA 00:1c:10:69:90:fe to state 2
[ 70.765625] rtl8192cu 1-2.3:1.0 wlan0: disabling HT as WMM/QoS is not supported by the AP
[ 70.773437] rtl8192cu 1-2.3:1.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP
[ 70.789062] wlan0: associate with 00:1c:10:69:90:fe (try 1/3)
[ 70.804687] wlan0: RX AssocResp from 00:1c:10:69:90:fe (capab=0x401 status=0 aid=1)
[ 70.812500] wlan0: moving STA 00:1c:10:69:90:fe to state 3
[ 70.820312] wlan0: moving STA 00:1c:10:69:90:fe to state 4
[ 70.828125] wlan0: associated
[ 71.187500] ------------[ cut here ]------------
[ 71.187500] WARNING: at kernel/workqueue.c:1365 __queue_work+0x180/0x1f8()
[ 71.187500] CPU: 0 PID: 593 Comm: kworker/0:2 Not tainted 3.10.0-rc5-00133-g691a986 #6
[ 71.187500] Workqueue: rtl92c_usb rtl_watchdog_wq_callback
[ 71.187500] [<c000d2a0>] (unwind_backtrace+0x0/0xf0) from [<c000ba34>] (show_stack+0x10/0x14)
[ 71.187500] [<c000ba34>] (show_stack+0x10/0x14) from [<c00150fc>] (warn_slowpath_common+0x48/0x64)
[ 71.187500] [<c00150fc>] (warn_slowpath_common+0x48/0x64) from [<c00151e0>] (warn_slowpath_null+0x1c/0x24)
[ 71.187500] [<c00151e0>] (warn_slowpath_null+0x1c/0x24) from [<c0029878>] (__queue_work+0x180/0x1f8)
[ 71.187500] [<c0029878>] (__queue_work+0x180/0x1f8) from [<c0029ee8>] (queue_work_on+0x44/0x50)
[ 71.187500] [<c0029ee8>] (queue_work_on+0x44/0x50) from [<c01fd850>] (rtl_watchdog_wq_callback+0x290/0x4e0)
[ 71.187500] [<c01fd850>] (rtl_watchdog_wq_callback+0x290/0x4e0) from [<c002a138>] (process_one_work+0x110/0x358)
[ 71.187500] [<c002a138>] (process_one_work+0x110/0x358) from [<c002a728>] (worker_thread+0xf4/0x308)
[ 71.187500] [<c002a728>] (worker_thread+0xf4/0x308) from [<c002f8b4>] (kthread+0xa4/0xb0)
[ 71.187500] [<c002f8b4>] (kthread+0xa4/0xb0) from [<c00091b0>] (ret_from_fork+0x14/0x24)
[ 71.187500] ---[ end trace 5f274d456b3a4c7f ]---
iw dev wlan0 link
Connected to 00:1c:10:69:90:fe (on wlan0)
SSID: test
freq: 2412
RX: 8896 bytes (256 packets)
TX: 80 bytes (2 packets)
signal: -48 dBm
tx bitrate: 1.0 MBit/s
bss flags: short-slot-time
dtim period: 0
beacon int: 100
# udhcpc -i wlan0 -f -n -q
udhcpc (v1.21.0) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
**** inserting another key (an older cisco/linksys WUSG54GC)
# [ 108.875000] usb 1-2.2: new high-speed USB device number 4 using atmel-ehci
[ 109.109375] usb 1-2.2: reset high-speed USB device number 4 using atmel-ehci
[ 109.242187] ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected
[ 109.265625] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 0006 detected
[ 109.273437] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
# ip link set wlan1 up
[ 116.234375] ieee80211 phy1: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
[ 116.250000] ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.29
# iw dev wlan1 scan
BSS 00:1c:10:69:90:fe (on wlan1)
TSF: 1144496990 usec (0d, 00:19:04)
freq: 2412
beacon interval: 100
capability: ESS ShortSlotTime (0x0401)
signal: -27.00 dBm
last seen: 1429 ms ago
SSID: test
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
DS Parameter set: channel 1
ERP: Barker_Preamble_Mode
Extended supported rates: 24.0 36.0 48.0 54.0
BSS 00:17:9a:84:fb:94 (on wlan1)
TSF: 5965523554325 usec (69d, 01:05:23)
freq: 2437
beacon interval: 100
capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
signal: -55.00 dBm
last seen: 960 ms ago
Information elements from Probe Response frame:
SSID: paratronic
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 12.0 24.0 36.0
DS Parameter set: channel 6
Country: GB Environment: Indoor/Outdoor
Channels [1 - 13] @ 14 dBm
ERP: <no flags>
Extended supported rates: 9.0 18.0 48.0 54.0
WMM: * Parameter version 1
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: CW 3-7, AIFSN 2, TXOP 1504 usec
# iw wlan1 connect test
[ 135.710937] wlan1: authenticate with 00:1c:10:69:90:fe
[ 135.718750] wlan1: Allocated STA 00:1c:10:69:90:fe
[ 135.726562] wlan1: Inserted STA 00:1c:10:69:90:fe
[ 135.734375] wlan1: send auth to 00:1c:10:69:90:fe (try 1/3)
[ 135.742187] wlan1: authenticated
[ 135.742187] wlan1: moving STA 00:1c:10:69:90:fe to state 2
# [ 135.750000] rt2800usb 1-2.2:1.0 wlan1: disabling HT as WMM/QoS is not supported by the AP
[ 135.757812] rt2800usb 1-2.2:1.0 wlan1: disabling VHT as WMM/QoS is not supported by the AP
[ 135.773437] wlan1: associate with 00:1c:10:69:90:fe (try 1/3)
[ 135.773437] wlan1: RX AssocResp from 00:1c:10:69:90:fe (capab=0x401 status=0 aid=2)
[ 135.789062] wlan1: moving STA 00:1c:10:69:90:fe to state 3
[ 135.796875] wlan1: moving STA 00:1c:10:69:90:fe to state 4
[ 135.812500] wlan1: associated
# udhcpc -i wlan1 -f -n -q
udhcpc (v1.21.0) started
Sending discover...
Sending select for 10.125.0.205...
Lease of 10.125.0.205 obtained, lease time 60
deleting routers
route: SIOCDELRT: No such process
# ping 10.125.0.201
PING 10.125.0.201 (10.125.0.201): 56 data bytes
\x03
--- 10.125.0.201 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
# ping 10.125.0.1
PING 10.125.0.1 (10.125.0.1): 56 data bytes
64 bytes from 10.125.0.1: seq=0 ttl=64 time=6.966 ms
64 bytes from 10.125.0.1: seq=1 ttl=64 time=2.677 ms
64 bytes from 10.125.0.1: seq=2 ttl=64 time=2.895 ms
\x03
--- 10.125.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 2.677/4.179/6.966 ms
#
So it works allright with the other key, but not with the tp-link one.
Did I do something wrong ?
Regards,
Richard.
^ permalink raw reply
* Re: [RFC 4/5] mac80211: enforce address verification on monitors
From: Jakub Kiciński @ 2013-06-11 13:01 UTC (permalink / raw)
To: Johannes Berg
Cc: Felix Fietkau, linux-wireless, Helmut Schaa,
nietrywialneprzejscie
In-Reply-To: <1370951175.8356.17.camel@jlt4.sipsolutions.net>
On Tue, 11 Jun 2013 13:46:15 +0200, Johannes Berg wrote:
>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.
I've considered this initially. Two reasons that made me
think the current approach is cleaner are:
- it's nice when user gets the error during the action that
puts system in inconsistent state not some time later. I
personally hate to get vague EBUSY and have to figure out
what's wrong.
- suppose there are two interfaces, both down with
incompatible addresses. User adds third ifc, what address
should we assign to it?
Besides who would care what address does passive monitor
have? ;)
> 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.
Right but I believe user would understand what is the problem
here and just remove and recreate one of the interfaces. They
have to be down to change MAC addr anyway.
Obviously this change is no matter for a big discussion. I
already feel like stealing your time a bit, because only
rt2x00 cares about this stuff anyway (I think). So please
let me know if my reasoning convinces you and if not I will
be happy to rewrite this the way you suggest.
-- kuba
^ permalink raw reply
* Re: [PATCHv5 1/4] mac80211: make mgmt_tx accept a NULL channel
From: Johannes Berg @ 2013-06-11 13:02 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1370953203-4086-1-git-send-email-ordex@autistici.org>
Applied all, but I fixed your locking.
johannes
^ permalink raw reply
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