Re: dynamic ps + offchannel mgmt_tx + HW RoC
On Wed, May 4, 2016 at 1:33 AM, Johannes Berg wrote: > On Wed, 2016-05-04 at 01:20 +0530, Krishna Chaitanya wrote: >> On Wed, May 4, 2016 at 1:05 AM, Johannes Berg > net> wrote: >> > >> > There is, btw, perhaps a different way - just fix the damn stuff. >> > >> > Requires moving everything into ifmgd rather than local, and then >> > perhaps if only a single managed interface exists mirroring its >> > state >> > into the existing driver calls etc. >> > >> > It'd still be a big task, and I don't see much advantage over just >> > reimplementing it. >> Yes, requires quite an effort and also need to handle lot of cases. >> Instead, why don't we make the default as complete PS offload >> and force the drivers who need to use mac80211 PS negate these >> in the register_hw? That way we are clear about the intentions. > > I don't really see a big advantage, and it'd create churn in a lot of > drivers. Maybe documenting it with the flags that we really think you > should set them or something, or making the powersave DOC section > mention this would be good, but beyond that I don't think it'd be a > good idea. that's fine with me. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] iwlwifi: mvm: silence unintialized variable warning
"max_amsdu_len" isn't set if kstrtouint() fails. Signed-off-by: Dan Carpenter diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c index 362a546..cb8db23 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c @@ -1020,6 +1020,8 @@ static ssize_t iwl_dbgfs_max_amsdu_len_write(struct iwl_mvm *mvm, int ret; ret = kstrtouint(buf, 0, &max_amsdu_len); + if (ret) + return ret; if (max_amsdu_len > IEEE80211_MAX_MPDU_LEN_VHT_11454) return -EINVAL; -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] iwlwifi: mvm: remove an unused variable
We never initalize ampdu_status so it causes a static checker warning
when we pass it to iwl_mvm_pass_packet_to_mac80211(). Fortunately, it's
never used so we can just remove it.
Signed-off-by: Dan Carpenter
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
index 263e8a8..c9d419f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
@@ -100,7 +100,7 @@ static void iwl_mvm_pass_packet_to_mac80211(struct iwl_mvm
*mvm,
struct napi_struct *napi,
struct sk_buff *skb,
struct ieee80211_hdr *hdr, u16 len,
- u32 ampdu_status, u8 crypt_len,
+ u8 crypt_len,
struct iwl_rx_cmd_buffer *rxb)
{
unsigned int hdrlen, fraglen;
@@ -267,7 +267,6 @@ void iwl_mvm_rx_rx_mpdu(struct iwl_mvm *mvm, struct
napi_struct *napi,
struct ieee80211_sta *sta = NULL;
struct sk_buff *skb;
u32 len;
- u32 ampdu_status;
u32 rate_n_flags;
u32 rx_pkt_status;
u8 crypt_len = 0;
@@ -453,8 +452,8 @@ void iwl_mvm_rx_rx_mpdu(struct iwl_mvm *mvm, struct
napi_struct *napi,
mvm->sched_scan_pass_all == SCHED_SCAN_PASS_ALL_ENABLED))
mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_FOUND;
- iwl_mvm_pass_packet_to_mac80211(mvm, napi, skb, hdr, len, ampdu_status,
- crypt_len, rxb);
+ iwl_mvm_pass_packet_to_mac80211(mvm, napi, skb, hdr, len, crypt_len,
+ rxb);
}
static void iwl_mvm_update_rx_statistics(struct iwl_mvm *mvm,
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] rtlwifi: rtl818x: silence uninitialized variable warning
What about if "rtlphy->pwrgroup_cnt" is 2? In that case we would use an
uninitialized "chnlgroup" variable and probably crash. Maybe that can't
happen for some reason which is not obvious but in that case this patch
is harmless.
Setting it to zero seems like a standard default in the surrounding code
so it's probably fine here as well.
Signed-off-by: Dan Carpenter
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.c
index 78a81c1..9475aa2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.c
@@ -208,8 +208,7 @@ static void
_rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
"Realtek regulatory, 40MHz, writeval = 0x%x\n",
writeval);
} else {
- if (rtlphy->pwrgroup_cnt == 1)
- chnlgroup = 0;
+ chnlgroup = 0;
if (rtlphy->pwrgroup_cnt >= 3) {
if (chnl <= 3)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fix infoleak in wilc_wfi_cfgoperations
"mac" is an array allocated in stack without being initialized, and will be sent out via "nla_put". The dump_station() is supposed to initialize the mac address; otherwise, sensitive data in kernel stack will be leaked. To fix this, copy the mac address to it. Signed-off-by: Kangjie Lu --- drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c index 448a5c8..c6e71d9 100644 --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c @@ -1797,6 +1797,7 @@ static int dump_station(struct wiphy *wiphy, struct net_device *dev, wilc_get_rssi(vif, &sinfo->signal); + memcpy(mac, priv->au8AssociatedBss, ETH_ALEN); return 0; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix infoleak in ioctl_cfg80211
On Tue, May 03, 2016 at 06:11:46PM -0400, Kangjie Lu wrote: > "mac" is an array allocated in stack without being initialized, > and will be sent out via "nla_put". The dump_station() is supposed > to initialize the mac address; otherwise, sensitive data in kernel > stack will be leaked. To fix this, either initialize it (e.g., > memset) or completely remove this dump_station(). > > Signed-off-by: Kangjie Lu > --- > drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c > b/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c > index 12d1844..44a1582 100644 > --- a/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c > +++ b/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c > @@ -2926,6 +2926,7 @@ static int cfg80211_rtw_dump_station(struct wiphy > *wiphy, > > /* TODO: dump scanned queue */ > > + memset(mac, 0, ETH_ALEN); > return -ENOENT; > } This isn't needed, as it returns -ENOENT and so mac never gets used. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fix infoleak in ioctl_cfg80211
"mac" is an array allocated in stack without being initialized, and will be sent out via "nla_put". The dump_station() is supposed to initialize the mac address; otherwise, sensitive data in kernel stack will be leaked. To fix this, either initialize it (e.g., memset) or completely remove this dump_station(). Signed-off-by: Kangjie Lu --- drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c index 12d1844..44a1582 100644 --- a/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c +++ b/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c @@ -2926,6 +2926,7 @@ static int cfg80211_rtw_dump_station(struct wiphy *wiphy, /* TODO: dump scanned queue */ + memset(mac, 0, ETH_ALEN); return -ENOENT; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix infoleak in wireless
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, May 03, 2016 at 05:41:46PM -0400, Kangjie Lu wrote: > You are right. But wouldn't it be more general/better if we initialize the > allocation at very beginning? > To avoid information leaks, I think we are supposed to initialize all > allocations properly if > we are not sure how they are used. But the networking maintainers told you to fix the broken drivers instead. So please do that and send those patches to the correct developers and mailing lists. The fact that only 2 staging drivers got this wrong means that everyone knows how to use this api properly, so I agree with the maintainers here. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix infoleak in wireless
On Tue, May 03, 2016 at 05:11:07PM -0400, Kangjie Lu wrote:
> Opps, I did not notice the patch is not attached.
>
> From 34a82a734388d07eb10f91770f86938e38f7575a Mon Sep 17 00:00:00 2001
> From: Kangjie Lu
> Date: Tue, 3 May 2016 14:15:18 -0400
> Subject: [PATCH] fix infoleak in wireless
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The 6-bytes array “mac_addr” is not initialized in the dump_station
> implementations of “drivers/staging/wilc1000/wilc_wfi_cfgoperations.c”
> and “drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c”, so all 6
> bytes may be leaked.
>
> Signed-off-by: Kangjie Lu
> ---
> net/wireless/nl80211.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 056a730..2e92d14 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -3905,6 +3905,7 @@ static int nl80211_dump_station(struct sk_buff *skb,
>
> while (1) {
> memset(&sinfo, 0, sizeof(sinfo));
> + eth_zero_addr(mac_addr);
> err = rdev_dump_station(rdev, wdev->netdev, sta_idx,
> mac_addr, &sinfo);
> if (err == -ENOENT)
Patch is corrupted :(
Why not fix up the staging drivers, they are the real problem here,
which is what I think the networking maintainers were telling you to do.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix infoleak in wireless
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, May 03, 2016 at 04:47:16PM -0400, Kangjie Lu wrote: > Hi Greg, > > Could you please take a look at this issue. > mac_addr is not initialized is some implementations of dump_station(), which > can be exploited by attackers for leaking information. You are going to have to give me more context here... Like the patch itself? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix infoleak in wireless
On Tue, 2016-05-03 at 16:40 -0400, Kangjie Lu wrote: > The 6-bytes array “mac_addr” is not initialized in the dump_station > implementations of > “drivers/staging/wilc1000/wilc_wfi_cfgoperations.c” > and “drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c”, so all 6 > bytes may be leaked. Like I said to you before, this makes those implementations completely broken. I'm not going to apply this patch. If you want, feel free to send patches to Greg to remove those dump_station implementations that are completely broken and that can never do anything useful. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fix infoleak in wireless
The 6-bytes array “mac_addr” is not initialized in the dump_station
implementations of “drivers/staging/wilc1000/wilc_wfi_cfgoperations.c”
and “drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c”, so all 6
bytes may be leaked.
Signed-off-by: Kangjie Lu
---
net/wireless/nl80211.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 056a730..2e92d14 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3905,6 +3905,7 @@ static int nl80211_dump_station(struct sk_buff *skb,
while (1) {
memset(&sinfo, 0, sizeof(sinfo));
+ eth_zero_addr(mac_addr);
err = rdev_dump_station(rdev, wdev->netdev, sta_idx,
mac_addr, &sinfo);
if (err == -ENOENT)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] linux-firmware: ath10k: add QCA9377 and update QCA6174 images
On Fri, Apr 29, 2016 at 08:42:53PM +0300, Kalle Valo wrote: > Hi, > > here are firmware images for the new QCA9377 chip and updates for QCA6174. > Applied, thanks Kalle. cheers, --Kyle > Kalle > > --- > > Kalle Valo (4): > ath10k: QCA6174 hw2.1: update firmware-5.bin to > SW_RM.1.1.1-00157-QCARMSWPZ-1 > ath10k: QCA6174 hw2.1: add board-2.bin > ath10k: QCA6174 hw3.0: add board-2.bin > ath10k: QCA9377 hw1.0: add firmware and board files > > > WHENCE|9 > ath10k/QCA6174/hw2.1/board-2.bin | Bin > ath10k/QCA6174/hw2.1/firmware-5.bin | Bin > ath10k/QCA6174/hw3.0/board-2.bin | Bin > ath10k/QCA9377/hw1.0/board-2.bin | Bin > ath10k/QCA9377/hw1.0/board.bin| Bin > ath10k/QCA9377/hw1.0/firmware-5.bin | Bin > ath10k/QCA9377/hw1.0/notice_ath10k_firmware-5.txt | 1128 > + > 8 files changed, 1136 insertions(+), 1 deletion(-) > create mode 100644 ath10k/QCA6174/hw2.1/board-2.bin > create mode 100644 ath10k/QCA6174/hw3.0/board-2.bin > create mode 100644 ath10k/QCA9377/hw1.0/board-2.bin > create mode 100644 ath10k/QCA9377/hw1.0/board.bin > create mode 100644 ath10k/QCA9377/hw1.0/firmware-5.bin > create mode 100644 ath10k/QCA9377/hw1.0/notice_ath10k_firmware-5.txt > > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dynamic ps + offchannel mgmt_tx + HW RoC
On Wed, 2016-05-04 at 01:20 +0530, Krishna Chaitanya wrote: > On Wed, May 4, 2016 at 1:05 AM, Johannes Berg net> wrote: > > > > There is, btw, perhaps a different way - just fix the damn stuff. > > > > Requires moving everything into ifmgd rather than local, and then > > perhaps if only a single managed interface exists mirroring its > > state > > into the existing driver calls etc. > > > > It'd still be a big task, and I don't see much advantage over just > > reimplementing it. > Yes, requires quite an effort and also need to handle lot of cases. > Instead, why don't we make the default as complete PS offload > and force the drivers who need to use mac80211 PS negate these > in the register_hw? That way we are clear about the intentions. I don't really see a big advantage, and it'd create churn in a lot of drivers. Maybe documenting it with the flags that we really think you should set them or something, or making the powersave DOC section mention this would be good, but beyond that I don't think it'd be a good idea. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dynamic ps + offchannel mgmt_tx + HW RoC
On Wed, May 4, 2016 at 1:05 AM, Johannes Berg wrote: > There is, btw, perhaps a different way - just fix the damn stuff. > > Requires moving everything into ifmgd rather than local, and then > perhaps if only a single managed interface exists mirroring its state > into the existing driver calls etc. > > It'd still be a big task, and I don't see much advantage over just > reimplementing it. Yes, requires quite an effort and also need to handle lot of cases. Instead, why don't we make the default as complete PS offload and force the drivers who need to use mac80211 PS negate these in the register_hw? That way we are clear about the intentions. -- Thanks, Regards, Chaitanya T K. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mwifiex: Drop unnecessary include pcieport_if.h
This header file is only needed for drivers binding to a PCI bridge device allocated by drivers/pci/pcie/portdrv_core.c. The mwifiex driver doesn't do that nor use any symbols defined in pcieport_if.h. Cc: Amitkumar Karwar Cc: Nishant Sarmukadam Signed-off-by: Lukas Wunner --- drivers/net/wireless/marvell/mwifiex/pcie.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h b/drivers/net/wireless/marvell/mwifiex/pcie.h index 6fc2873..1ccd5ad 100644 --- a/drivers/net/wireless/marvell/mwifiex/pcie.h +++ b/drivers/net/wireless/marvell/mwifiex/pcie.h @@ -23,7 +23,6 @@ #define_MWIFIEX_PCIE_H #include -#include #include #include"main.h" -- 2.8.0.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dynamic ps + offchannel mgmt_tx + HW RoC
There is, btw, perhaps a different way - just fix the damn stuff. Requires moving everything into ifmgd rather than local, and then perhaps if only a single managed interface exists mirroring its state into the existing driver calls etc. It'd still be a big task, and I don't see much advantage over just reimplementing it. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces
On Tue, 2016-05-03 at 08:53 +0200, Martin Willi wrote:
>
> +static __net_init int hwsim_init_net(struct net *net)
> +{
> + struct mac80211_hwsim_data *data;
> + bool exists = true;
> + int netgroup = 0;
> +
> + spin_lock_bh(&hwsim_radio_lock);
> + while (exists) {
> + exists = false;
> + list_for_each_entry(data, &hwsim_radios, list) {
> + if (netgroup == data->netgroup) {
> + exists = true;
> + netgroup++;
> + break;
> + }
> + }
> + }
> + spin_unlock_bh(&hwsim_radio_lock);
> +
> + *(int *)net_generic(net, hwsim_net_id) = netgroup;
This seems somewhat awkward. Why not just take the maximum of all the
netgroup IDs + 1? We'd run out of memory and radio IDs long before
netgroup IDs even that way, and they're not actually visible anywhere
so it doesn't matter.
Actually though, *both* your approach and my suggestion don't seem
safe: consider a new netns that doesn't have any hwsim radios yet. Now
you create *another* one, but it would get the same netgroup.
IOW, you should simply use a global counter. Surprising (net)
namespaces don't have an index like that already, but I don't see one.
> +static void __net_exit hwsim_exit_net(struct net *net)
> +{
> + struct mac80211_hwsim_data *entry, *tmp;
> +
> + spin_lock_bh(&hwsim_radio_lock);
> + list_for_each_entry_safe(entry, tmp, &hwsim_radios, list) {
> + if (net_eq(wiphy_net(entry->hw->wiphy), net)) {
> + list_del(&entry->list);
> + INIT_WORK(&entry->destroy_work,
> destroy_radio);
> + schedule_work(&entry->destroy_work);
> + }
> + }
> + spin_unlock_bh(&hwsim_radio_lock);
> +}
This changes today's default behaviour of moving the wiphys to the
default namespace. Did you intend to destroy them based on the
netgroup, i.e. based on the namespace that created them? Actually,
maybe they should move back to the namespace that created them, if the
namespace they are in is destroyed? But that's difficult, I don't mind
this behaviour, but I'm not sure it's what we want by default for
radios created in the init_net.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: Advertise extended capabilities per interface type to userspace
On Fri, 2016-04-22 at 14:52 +, Kanchanapally, Vidyullatha wrote: > > > So I'm thinking something like > > > > supported_on_all = iftype_ext_capab[0] > > for i in 1..num_iftype_ext_capab-1: > > supported_on_all &= iftype_ext_capab[i] > > WARN_ON(wiphy->ext_capa_mask & ~supported_on_all) > We were thinking whether this is an appropriate validation or not > since we cannot be sure how the Extended Capabilities are defined. > They need not necessarily be all positive capabilities, they could > couple both the positive and negative capabilities as well. > Please let us know if this change is really needed. I'm ambivalent about this. I don't think it makes sense to see drivers that register both, i.e. would result in the warning I suggested. I don't think *negative* capabilities can really be added, since the spec always assumes that capabilities that you don't list are zero. In considering multi-bit values, you might have a point, if - for example - you had a MAX-MSDU-IN-AMSDU value of 0b11 for some interfaces, and 0b01 for all the others. Realistically though, does that make sense? I would expect this to be the only multi-bit field that might ever be supported this way, since in the future drivers would likely only specify the current subset of capabilities in the wiphy ext_capab, and put all newer extensions into the per-iftype ext_capa, assuming that they're running on a newer supplicant. So on the whole, I don't really see a good reason to not do pretty much exactly the (pseudo)code I wrote above; perhaps you can come up with a better example than I tried? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dynamic ps + offchannel mgmt_tx + HW RoC
On Tue, 2016-05-03 at 19:21 +0200, Janusz Dziedzic wrote: > > Why not remove PS code from the mac80211 then, while is broken and > should not be used? > It'd still be a regression since some drivers can kinda use it. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dynamic ps + offchannel mgmt_tx + HW RoC
On 3 May 2016 at 18:58, Krishna Chaitanya wrote: > On Tue, May 3, 2016 at 9:31 PM, Johannes Berg > wrote: >> On Tue, 2016-05-03 at 20:02 +0530, Krishna Chaitanya wrote: >> >>> > i don't see any issues in the powersave w.r.t driver. Isn't it a >>> > valid case? you meant implementing dynamic_ps? >> >> No, I really did mean implementing the entire PS logic in the driver, >> instead of having mac80211 do it. >> >>> If it advertise HW_SUPPORTS_DYNAMIC_PS it works fine. >>> so may be we should queue those frames and send it to >>> HW once it is out of powersave? >> >> We could, but I *really* don't want to patch over the messy and broken >> powersave code in mac80211 now. >> >> I really do think that the only way out of this mess is to implement >> powersave entirely outside of mac80211; perhaps mac80211 could provide >> helpers for it, but tying it into the MLME implementation and having >> all the PS-Poll stuff be global etc. is simply wrong today. > Okay, i understand. This again points to our discussion about mac80211 > ps a while ago. May be we should document this somewhere so that > device driver developers are aware of this? > Why not remove PS code from the mac80211 then, while is broken and should not be used? BR Janusz > > > -- > Thanks, > Regards, > Chaitanya T K. > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dynamic ps + offchannel mgmt_tx + HW RoC
On Tue, May 3, 2016 at 9:31 PM, Johannes Berg wrote: > On Tue, 2016-05-03 at 20:02 +0530, Krishna Chaitanya wrote: > >> > i don't see any issues in the powersave w.r.t driver. Isn't it a >> > valid case? you meant implementing dynamic_ps? > > No, I really did mean implementing the entire PS logic in the driver, > instead of having mac80211 do it. > >> If it advertise HW_SUPPORTS_DYNAMIC_PS it works fine. >> so may be we should queue those frames and send it to >> HW once it is out of powersave? > > We could, but I *really* don't want to patch over the messy and broken > powersave code in mac80211 now. > > I really do think that the only way out of this mess is to implement > powersave entirely outside of mac80211; perhaps mac80211 could provide > helpers for it, but tying it into the MLME implementation and having > all the PS-Poll stuff be global etc. is simply wrong today. Okay, i understand. This again points to our discussion about mac80211 ps a while ago. May be we should document this somewhere so that device driver developers are aware of this? -- Thanks, Regards, Chaitanya T K. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dynamic ps + offchannel mgmt_tx + HW RoC
On Tue, 2016-05-03 at 20:02 +0530, Krishna Chaitanya wrote: > > i don't see any issues in the powersave w.r.t driver. Isn't it a > > valid case? you meant implementing dynamic_ps? No, I really did mean implementing the entire PS logic in the driver, instead of having mac80211 do it. > If it advertise HW_SUPPORTS_DYNAMIC_PS it works fine. > so may be we should queue those frames and send it to > HW once it is out of powersave? We could, but I *really* don't want to patch over the messy and broken powersave code in mac80211 now. I really do think that the only way out of this mess is to implement powersave entirely outside of mac80211; perhaps mac80211 could provide helpers for it, but tying it into the MLME implementation and having all the PS-Poll stuff be global etc. is simply wrong today. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 4/5] treewide: replace dev->trans_start update with helper
Replace all trans_start updates with netif_trans_update helper. change was done via spatch: struct net_device *d; @@ - d->trans_start = jiffies + netif_trans_update(d) Compile tested only. Cc: user-mode-linux-de...@lists.sourceforge.net Cc: linux-xte...@linux-xtensa.org Cc: linux1394-de...@lists.sourceforge.net Cc: linux-r...@vger.kernel.org Cc: net...@vger.kernel.org Cc: mpt-fusionlinux@broadcom.com Cc: linux-s...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-par...@vger.kernel.org Cc: linux-o...@vger.kernel.org Cc: linux-h...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-wireless@vger.kernel.org Cc: linux-s...@vger.kernel.org Cc: de...@driverdev.osuosl.org Cc: b.a.t.m@lists.open-mesh.org Cc: linux-blueto...@vger.kernel.org Signed-off-by: Florian Westphal --- Checkpatch complains about whitespace damage, but this extra whitespace already exists before this patch. arch/um/drivers/net_kern.c | 4 ++-- arch/xtensa/platforms/iss/network.c| 2 +- drivers/char/pcmcia/synclink_cs.c | 4 ++-- drivers/firewire/net.c | 2 +- drivers/infiniband/hw/nes/nes_nic.c| 2 +- drivers/infiniband/ulp/ipoib/ipoib_cm.c| 2 +- drivers/infiniband/ulp/ipoib/ipoib_ib.c| 2 +- drivers/isdn/hysdn/hysdn_net.c | 2 +- drivers/isdn/i4l/isdn_net.c| 4 ++-- drivers/isdn/i4l/isdn_x25iface.c | 2 +- drivers/message/fusion/mptlan.c| 2 +- drivers/net/appletalk/cops.c | 2 +- drivers/net/can/mscan/mscan.c | 4 ++-- drivers/net/can/usb/ems_usb.c | 4 ++-- drivers/net/can/usb/esd_usb2.c | 4 ++-- drivers/net/can/usb/peak_usb/pcan_usb_core.c | 4 ++-- drivers/net/cris/eth_v10.c | 2 +- drivers/net/ethernet/3com/3c509.c | 2 +- drivers/net/ethernet/3com/3c515.c | 2 +- drivers/net/ethernet/3com/3c574_cs.c | 2 +- drivers/net/ethernet/3com/3c589_cs.c | 2 +- drivers/net/ethernet/3com/3c59x.c | 2 +- drivers/net/ethernet/8390/axnet_cs.c | 6 +++--- drivers/net/ethernet/8390/lib8390.c| 4 ++-- drivers/net/ethernet/adaptec/starfire.c| 2 +- drivers/net/ethernet/adi/bfin_mac.c| 2 +- drivers/net/ethernet/agere/et131x.c| 4 ++-- drivers/net/ethernet/allwinner/sun4i-emac.c| 6 +++--- drivers/net/ethernet/amd/7990.c| 4 ++-- drivers/net/ethernet/amd/a2065.c | 2 +- drivers/net/ethernet/amd/atarilance.c | 2 +- drivers/net/ethernet/amd/au1000_eth.c | 2 +- drivers/net/ethernet/amd/declance.c| 2 +- drivers/net/ethernet/amd/lance.c | 2 +- drivers/net/ethernet/amd/ni65.c| 4 ++-- drivers/net/ethernet/amd/nmclan_cs.c | 2 +- drivers/net/ethernet/amd/pcnet32.c | 4 ++-- drivers/net/ethernet/amd/sunlance.c| 2 +- drivers/net/ethernet/atheros/alx/main.c| 2 +- drivers/net/ethernet/broadcom/bcmsysport.c | 2 +- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 2 +- drivers/net/ethernet/broadcom/sb1250-mac.c | 2 +- drivers/net/ethernet/broadcom/tg3.c| 2 +- drivers/net/ethernet/cavium/liquidio/lio_main.c| 4 ++-- drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 2 +- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 2 +- drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 2 +- drivers/net/ethernet/davicom/dm9000.c | 4 ++-- drivers/net/ethernet/dec/tulip/de4x5.c | 4 ++-- drivers/net/ethernet/dec/tulip/dmfe.c | 6 +++--- drivers/net/ethernet/dec/tulip/pnic.c | 6 +++--- drivers/net/ethernet/dec/tulip/tulip_core.c| 2 +- drivers/net/ethernet/dec/tulip/uli526x.c | 4 ++-- drivers/net/ethernet/dec/tulip/winbond-840.c | 2 +- drivers/net/ethernet/dlink/dl2k.c | 2 +- drivers/net/ethernet/dlink/sundance.c | 2 +- drivers/net/ethernet/fealnx.c | 2 +- drivers/net/ethernet/freescale/gianfar.c | 2 +- drivers/net/ethernet/fujitsu/fmvj18x_cs.c | 2 +- drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 2 +- drivers/net/ethernet/hisilicon/hns/hns_enet.c | 6 +++--- drivers/net/ethernet/hp/hp100.c| 2 +- drivers/net/ethernet/i825xx/82596.c| 2 +- drivers/net/ethernet/i825xx/lib82596.c | 2 +- dr
Re: dynamic ps + offchannel mgmt_tx + HW RoC
On Tue, May 3, 2016 at 7:46 PM, Krishna Chaitanya wrote: > On Tue, May 3, 2016 at 6:44 PM, Johannes Berg > wrote: >> On Tue, 2016-05-03 at 18:23 +0530, Krishna Chaitanya wrote: >>> Hi, >>> >>> When the HW is in PS and Dynamic PS is enabled we are dropping >>> all the offchannel frames. Sequence is as below >>> >>> if hw is in PS: stop_queues reason=PS, queue dynamic_ps_disable_work >>> send Offchannel mgmt_tx >>> drop the packet because offchanel + stop_reasons[q] !=0 >>> >>> How should we handle this? SW RoC is handling this >>> by checking for offchannel and bringing the HW out of PS before >>> handing the packet to TX path, so it works fine. >> >> You should handle this by not doing such a non-sensical thing and >> finally implementing powersave properly in the driver :) > i don't see any issues in the powersave w.r.t driver. Isn't it a > valid case? you meant implementing dynamic_ps? If it advertise HW_SUPPORTS_DYNAMIC_PS it works fine. so may be we should queue those frames and send it to HW once it is out of powersave? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dynamic ps + offchannel mgmt_tx + HW RoC
On Tue, May 3, 2016 at 6:44 PM, Johannes Berg wrote: > On Tue, 2016-05-03 at 18:23 +0530, Krishna Chaitanya wrote: >> Hi, >> >> When the HW is in PS and Dynamic PS is enabled we are dropping >> all the offchannel frames. Sequence is as below >> >> if hw is in PS: stop_queues reason=PS, queue dynamic_ps_disable_work >> send Offchannel mgmt_tx >> drop the packet because offchanel + stop_reasons[q] !=0 >> >> How should we handle this? SW RoC is handling this >> by checking for offchannel and bringing the HW out of PS before >> handing the packet to TX path, so it works fine. > > You should handle this by not doing such a non-sensical thing and > finally implementing powersave properly in the driver :) i don't see any issues in the powersave w.r.t driver. Isn't it a valid case? you meant implementing dynamic_ps? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cfg80211: remove erroneous comment
From: Johannes Berg
The devlist_mtx mutex was removed about two years ago, in favour of just
using RTNL/RCU protection. Remove the comment still referencing it.
Signed-off-by: Johannes Berg
---
net/wireless/core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index ac44e77..f75d760 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -53,7 +53,7 @@ struct cfg80211_registered_device {
/* associated wireless interfaces, protected by rtnl or RCU */
struct list_head wdev_list;
int devlist_generation, wdev_id;
- int opencount; /* also protected by devlist_mtx */
+ int opencount;
wait_queue_head_t dev_wait;
struct list_head beacon_registrations;
--
2.8.0.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: allow software PS-Poll/U-APSD with AP_LINK_PS
From: Johannes Berg
When using RSS, frames might not be processed in the correct order,
and thus AP_LINK_PS must be used; most likely with firmware keeping
track of the powersave state, this is the case in iwlwifi now.
In this case, the driver can use ieee80211_sta_ps_transition() to
still have mac80211 manage powersave buffering. However, for U-APSD
and PS-Poll this isn't sufficient. If the device can't manage that
entirely on its own, mac80211's code should be used.
To allow this, export two functions: ieee80211_sta_uapsd_trigger()
and ieee80211_sta_pspoll().
Signed-off-by: Johannes Berg
---
include/net/mac80211.h | 27 +++
net/mac80211/rx.c | 70 +++---
2 files changed, 71 insertions(+), 26 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index ce2f6e3..be30b05 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -3996,6 +3996,33 @@ static inline int ieee80211_sta_ps_transition_ni(struct
ieee80211_sta *sta,
return ret;
}
+/**
+ * ieee80211_sta_pspoll - PS-Poll frame received
+ * @sta: currently connected station
+ *
+ * When operating in AP mode with the %IEEE80211_HW_AP_LINK_PS flag set,
+ * use this function to inform mac80211 that a PS-Poll frame from a
+ * connected station was received.
+ * This must be used in conjunction with ieee80211_sta_ps_transition()
+ * and possibly ieee80211_sta_uapsd_trigger(); calls to all three must
+ * be serialized.
+ */
+void ieee80211_sta_pspoll(struct ieee80211_sta *sta);
+
+/**
+ * ieee80211_sta_uapsd_trigger - (potential) U-APSD trigger frame received
+ * @sta: currently connected station
+ * @tid: TID of the received (potential) trigger frame
+ *
+ * When operating in AP mode with the %IEEE80211_HW_AP_LINK_PS flag set,
+ * use this function to inform mac80211 that a (potential) trigger frame
+ * from a connected station was received.
+ * This must be used in conjunction with ieee80211_sta_ps_transition()
+ * and possibly ieee80211_sta_pspoll(); calls to all three must be
+ * serialized.
+ */
+void ieee80211_sta_uapsd_trigger(struct ieee80211_sta *sta, u8 tid);
+
/*
* The TX headroom reserved by mac80211 for its own tx_status functions.
* This is enough for the radiotap header.
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index c567870..5e65e83 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1319,13 +1319,52 @@ int ieee80211_sta_ps_transition(struct ieee80211_sta
*pubsta, bool start)
}
EXPORT_SYMBOL(ieee80211_sta_ps_transition);
+void ieee80211_sta_pspoll(struct ieee80211_sta *pubsta)
+{
+ struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
+
+ if (test_sta_flag(sta, WLAN_STA_SP))
+ return;
+
+ if (!test_sta_flag(sta, WLAN_STA_PS_DRIVER))
+ ieee80211_sta_ps_deliver_poll_response(sta);
+ else
+ set_sta_flag(sta, WLAN_STA_PSPOLL);
+}
+EXPORT_SYMBOL(ieee80211_sta_pspoll);
+
+void ieee80211_sta_uapsd_trigger(struct ieee80211_sta *pubsta, u8 tid)
+{
+ struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
+ u8 ac = ieee802_1d_to_ac[tid & 7];
+
+ /*
+* If this AC is not trigger-enabled do nothing.
+*
+* NB: This could/should check a separate bitmap of trigger-
+* enabled queues, but for now we only implement uAPSD w/o
+* TSPEC changes to the ACs, so they're always the same.
+*/
+ if (!(sta->sta.uapsd_queues & BIT(ac)))
+ return;
+
+ /* if we are in a service period, do nothing */
+ if (test_sta_flag(sta, WLAN_STA_SP))
+ return;
+
+ if (!test_sta_flag(sta, WLAN_STA_PS_DRIVER))
+ ieee80211_sta_ps_deliver_uapsd(sta);
+ else
+ set_sta_flag(sta, WLAN_STA_UAPSD);
+}
+EXPORT_SYMBOL(ieee80211_sta_uapsd_trigger);
+
static ieee80211_rx_result debug_noinline
ieee80211_rx_h_uapsd_and_pspoll(struct ieee80211_rx_data *rx)
{
struct ieee80211_sub_if_data *sdata = rx->sdata;
struct ieee80211_hdr *hdr = (void *)rx->skb->data;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(rx->skb);
- int tid, ac;
if (!rx->sta)
return RX_CONTINUE;
@@ -1351,12 +1390,7 @@ ieee80211_rx_h_uapsd_and_pspoll(struct ieee80211_rx_data
*rx)
return RX_CONTINUE;
if (unlikely(ieee80211_is_pspoll(hdr->frame_control))) {
- if (!test_sta_flag(rx->sta, WLAN_STA_SP)) {
- if (!test_sta_flag(rx->sta, WLAN_STA_PS_DRIVER))
- ieee80211_sta_ps_deliver_poll_response(rx->sta);
- else
- set_sta_flag(rx->sta, WLAN_STA_PSPOLL);
- }
+ ieee80211_sta_pspoll(&rx->sta->sta);
/* Free PS Poll skb here instead of returning RX_DROP that would
* count as an dropped frame. */
@@ -136
[PATCH] cfg80211: make wdev_list accessible to drivers
From: Johannes Berg
There's no harm in having drivers read the list, since they can
use RCU protection or RTNL locking; allow this to not require
each and every driver to also implement its own bookkeeping.
Signed-off-by: Johannes Berg
---
include/net/cfg80211.h | 5 +
net/wireless/chan.c| 2 +-
net/wireless/core.c| 17 ++---
net/wireless/core.h| 3 +--
net/wireless/nl80211.c | 16
net/wireless/reg.c | 2 +-
net/wireless/sme.c | 4 ++--
net/wireless/sysfs.c | 2 +-
net/wireless/util.c| 4 ++--
9 files changed, 31 insertions(+), 24 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 5f6e98ad..6392167 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3189,6 +3189,9 @@ struct wiphy_vendor_command {
* @vht_capa_mod_mask: Specify what VHT capabilities can be over-ridden.
* If null, then none can be over-ridden.
*
+ * @wdev_list: the list of associated (virtual) interfaces; this list must
+ * not be modified by the driver, but can be read with RTNL/RCU protection.
+ *
* @max_acl_mac_addrs: Maximum number of MAC addresses that the device
* supports for ACL.
*
@@ -3328,6 +3331,8 @@ struct wiphy {
const struct ieee80211_ht_cap *ht_capa_mod_mask;
const struct ieee80211_vht_cap *vht_capa_mod_mask;
+ struct list_head wdev_list;
+
/* the network namespace this phy lives in currently */
possible_net_t _net;
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index a6631fb..da49c0b 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -739,7 +739,7 @@ static bool cfg80211_ir_permissive_chan(struct wiphy *wiphy,
* and thus fail the GO instantiation, consider only the interfaces of
* the current registered device.
*/
- list_for_each_entry(wdev, &rdev->wdev_list, list) {
+ list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
struct ieee80211_channel *other_chan = NULL;
int r1, r2;
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7f7b940..d25c82b 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -3,6 +3,7 @@
*
* Copyright 2006-2010 Johannes Berg
* Copyright 2013-2014 Intel Mobile Communications GmbH
+ * Copyright 2015 Intel Deutschland GmbH
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -157,7 +158,7 @@ int cfg80211_switch_netns(struct cfg80211_registered_device
*rdev,
if (!(rdev->wiphy.flags & WIPHY_FLAG_NETNS_OK))
return -EOPNOTSUPP;
- list_for_each_entry(wdev, &rdev->wdev_list, list) {
+ list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
if (!wdev->netdev)
continue;
wdev->netdev->features &= ~NETIF_F_NETNS_LOCAL;
@@ -171,7 +172,8 @@ int cfg80211_switch_netns(struct cfg80211_registered_device
*rdev,
/* failed -- clean up to old netns */
net = wiphy_net(&rdev->wiphy);
- list_for_each_entry_continue_reverse(wdev, &rdev->wdev_list,
+ list_for_each_entry_continue_reverse(wdev,
+&rdev->wiphy.wdev_list,
list) {
if (!wdev->netdev)
continue;
@@ -230,7 +232,7 @@ void cfg80211_shutdown_all_interfaces(struct wiphy *wiphy)
ASSERT_RTNL();
- list_for_each_entry(wdev, &rdev->wdev_list, list) {
+ list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
if (wdev->netdev) {
dev_close(wdev->netdev);
continue;
@@ -298,7 +300,8 @@ void cfg80211_destroy_ifaces(struct
cfg80211_registered_device *rdev)
kfree(item);
spin_unlock_irq(&rdev->destroy_list_lock);
- list_for_each_entry_safe(wdev, tmp, &rdev->wdev_list, list) {
+ list_for_each_entry_safe(wdev, tmp,
+&rdev->wiphy.wdev_list, list) {
if (nlportid == wdev->owner_nlportid)
rdev_del_virtual_intf(rdev, wdev);
}
@@ -410,7 +413,7 @@ use_default_name:
dev_set_name(&rdev->wiphy.dev, PHY_NAME "%d", rdev->wiphy_idx);
}
- INIT_LIST_HEAD(&rdev->wdev_list);
+ INIT_LIST_HEAD(&rdev->wiphy.wdev_list);
INIT_LIST_HEAD(&rdev->beacon_registrations);
spin_lock_init(&rdev->beacon_registrations_lock);
spin_lock_init(&rdev->bss_lock);
@@ -799,7 +802,7 @@ void wiphy_unregister(struct wiphy *wiphy)
nl80211_notify_wiphy(rdev, NL80211_CMD_DEL_WIPHY);
rdev->wiphy.registered = false;
- WARN_ON(!list_empty(&rdev->wdev_list));
+ WARN_ON(!list_empty(&rdev->wiphy.wdev_list));
/*
* First remove the hardware from eve
Re: iwlwifi: add the MVM driver
Dan Carpenter writes: > The patch 8ca151b568b6: "iwlwifi: add the MVM driver" from Jan 24, > 2013, leads to the following static checker warning: Struggling to keep up with the backlog? :) Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dynamic ps + offchannel mgmt_tx + HW RoC
On Tue, 2016-05-03 at 18:23 +0530, Krishna Chaitanya wrote: > Hi, > > When the HW is in PS and Dynamic PS is enabled we are dropping > all the offchannel frames. Sequence is as below > > if hw is in PS: stop_queues reason=PS, queue dynamic_ps_disable_work > send Offchannel mgmt_tx > drop the packet because offchanel + stop_reasons[q] !=0 > > How should we handle this? SW RoC is handling this > by checking for offchannel and bringing the HW out of PS before > handing the packet to TX path, so it works fine. You should handle this by not doing such a non-sensical thing and finally implementing powersave properly in the driver :) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cfg80211: allow to find vendor with OUI without specifying the OUI type
From: Emmanuel Grumbach
This allows to find vendor IE from a specific vendor.
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Luca Coelho
---
include/net/cfg80211.h | 4 ++--
net/wireless/scan.c| 8 ++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 1e008cd..5f6e98ad 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3893,7 +3893,7 @@ const u8 *cfg80211_find_ie(u8 eid, const u8 *ies, int
len);
* cfg80211_find_vendor_ie - find vendor specific information element in data
*
* @oui: vendor OUI
- * @oui_type: vendor-specific OUI type
+ * @oui_type: vendor-specific OUI type (must be < 0xff), negative means any
* @ies: data consisting of IEs
* @len: length of data
*
@@ -3905,7 +3905,7 @@ const u8 *cfg80211_find_ie(u8 eid, const u8 *ies, int
len);
* Note: There are no checks on the element length other than having to fit
into
* the given data.
*/
-const u8 *cfg80211_find_vendor_ie(unsigned int oui, u8 oui_type,
+const u8 *cfg80211_find_vendor_ie(unsigned int oui, int oui_type,
const u8 *ies, int len);
/**
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index abdf651..ef2955c 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -364,13 +364,16 @@ const u8 *cfg80211_find_ie(u8 eid, const u8 *ies, int len)
}
EXPORT_SYMBOL(cfg80211_find_ie);
-const u8 *cfg80211_find_vendor_ie(unsigned int oui, u8 oui_type,
+const u8 *cfg80211_find_vendor_ie(unsigned int oui, int oui_type,
const u8 *ies, int len)
{
struct ieee80211_vendor_ie *ie;
const u8 *pos = ies, *end = ies + len;
int ie_oui;
+ if (WARN_ON(oui_type > 0xff))
+ return NULL;
+
while (pos < end) {
pos = cfg80211_find_ie(WLAN_EID_VENDOR_SPECIFIC, pos,
end - pos);
@@ -386,7 +389,8 @@ const u8 *cfg80211_find_vendor_ie(unsigned int oui, u8
oui_type,
goto cont;
ie_oui = ie->oui[0] << 16 | ie->oui[1] << 8 | ie->oui[2];
- if (ie_oui == oui && ie->oui_type == oui_type)
+ if (ie_oui == oui &&
+ (oui_type < 0 || ie->oui_type == oui_type))
return pos;
cont:
pos += 2 + ie->len;
--
2.8.0.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: remove disconnected APs from BSS table
From: David Spinadel In some cases, after a sudden AP disappearing and reconnection to another AP in the same ESS, user space gets the old AP in scan results (cached). User space may decide to roam to that old AP which will cause a disconnection and longer recovery. Remove APs that are probably out of range from BSS table. Signed-off-by: David Spinadel Signed-off-by: Luca Coelho --- net/mac80211/mlme.c | 5 + 1 file changed, 5 insertions(+) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 885f4ca..8d426f6 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -2399,6 +2399,11 @@ static void __ieee80211_disconnect(struct ieee80211_sub_if_data *sdata) return; } + /* AP is probably out of range (or not reachable for another reason) so +* remove the bss struct for that AP. +*/ + cfg80211_unlink_bss(local->hw.wiphy, ifmgd->associated); + ieee80211_set_disassoc(sdata, IEEE80211_STYPE_DEAUTH, WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY, true, frame_buf); -- 2.8.0.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix regression in Android due to rework .get_station() callback
After f654d13 Android is not able to get station signal strength.
To much was removed, this patch brings back the needed functionality.
Signed-off-by: meijjaa
---
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
index deb5f78..0275474 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
@@ -2428,6 +2428,8 @@ brcmf_cfg80211_get_station(struct wiphy *wiphy, struct
net_device *ndev,
{
struct brcmf_if *ifp = netdev_priv(ndev);
s32 err = 0;
+ struct brcmf_scb_val_le scb_val;
+ int rssi;
struct brcmf_sta_info_le sta_info_le;
u32 sta_flags;
u32 is_tdls_peer;
@@ -2506,6 +2508,21 @@ brcmf_cfg80211_get_station(struct wiphy *wiphy, struct
net_device *ndev,
count_rssi++;
}
}
+ if (test_bit(BRCMF_VIF_STATUS_CONNECTED,
+&ifp->vif->sme_state)) {
+ memset(&scb_val, 0, sizeof(scb_val));
+ err = brcmf_fil_cmd_data_get(ifp, BRCMF_C_GET_RSSI,
+&scb_val, sizeof(scb_val));
+ if (err) {
+ brcmf_err("Could not get rssi (%d)\n", err);
+ goto done;
+ } else {
+ rssi = le32_to_cpu(scb_val.val);
+ sinfo->filled |= BIT(NL80211_STA_INFO_SIGNAL);
+ sinfo->signal = rssi;
+ brcmf_dbg(CONN, "RSSI %d dBm\n", rssi);
+ }
+ }
if (count_rssi) {
sinfo->filled |= BIT(NL80211_STA_INFO_CHAIN_SIGNAL);
sinfo->chains = count_rssi;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] mac80211: allow same PN for AMSDU sub-frames
From: Sara Sharon
Some hardware (iwlwifi an example) de-aggregate AMSDUs and copy the IV
as is to the generated MPDUs, so the same PN appears in multiple
packets without being a replay attack. Allow driver to explicitly
indicate that a frame is allowed to have the same PN as the previous
frame.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
include/net/mac80211.h | 6 +-
net/mac80211/wpa.c | 16
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 07ef937..ce2f6e3 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1068,6 +1068,9 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info
*info)
* @RX_FLAG_RADIOTAP_VENDOR_DATA: This frame contains vendor-specific
* radiotap data in the skb->data (before the frame) as described by
* the &struct ieee80211_vendor_radiotap.
+ * @RX_FLAG_ALLOW_SAME_PN: Allow the same PN as same packet before.
+ * This is used for AMSDU subframes which can have the same PN as
+ * the first subframe.
*/
enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR = BIT(0),
@@ -1101,7 +1104,8 @@ enum mac80211_rx_flags {
RX_FLAG_5MHZ= BIT(29),
RX_FLAG_AMSDU_MORE = BIT(30),
RX_FLAG_RADIOTAP_VENDOR_DATA= BIT(31),
- RX_FLAG_MIC_STRIPPED= BIT_ULL(32),
+ RX_FLAG_MIC_STRIPPED= BIT_ULL(32),
+ RX_FLAG_ALLOW_SAME_PN = BIT_ULL(33),
};
#define RX_FLAG_STBC_SHIFT 26
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index 7e4f265..b48c1e1 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -519,12 +519,16 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data
*rx,
return RX_DROP_UNUSABLE;
if (!(status->flag & RX_FLAG_PN_VALIDATED)) {
+ int res;
+
ccmp_hdr2pn(pn, skb->data + hdrlen);
queue = rx->security_idx;
- if (memcmp(pn, key->u.ccmp.rx_pn[queue],
- IEEE80211_CCMP_PN_LEN) <= 0) {
+ res = memcmp(pn, key->u.ccmp.rx_pn[queue],
+IEEE80211_CCMP_PN_LEN);
+ if (res < 0 ||
+ (!res && !(status->flag & RX_FLAG_ALLOW_SAME_PN))) {
key->u.ccmp.replays++;
return RX_DROP_UNUSABLE;
}
@@ -745,12 +749,16 @@ ieee80211_crypto_gcmp_decrypt(struct ieee80211_rx_data
*rx)
return RX_DROP_UNUSABLE;
if (!(status->flag & RX_FLAG_PN_VALIDATED)) {
+ int res;
+
gcmp_hdr2pn(pn, skb->data + hdrlen);
queue = rx->security_idx;
- if (memcmp(pn, key->u.gcmp.rx_pn[queue],
- IEEE80211_GCMP_PN_LEN) <= 0) {
+ res = memcmp(pn, key->u.gcmp.rx_pn[queue],
+IEEE80211_GCMP_PN_LEN);
+ if (res < 0 ||
+ (!res && !(status->flag & RX_FLAG_ALLOW_SAME_PN))) {
key->u.gcmp.replays++;
return RX_DROP_UNUSABLE;
}
--
2.8.0.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
dynamic ps + offchannel mgmt_tx + HW RoC
Hi, When the HW is in PS and Dynamic PS is enabled we are dropping all the offchannel frames. Sequence is as below if hw is in PS: stop_queues reason=PS, queue dynamic_ps_disable_work send Offchannel mgmt_tx drop the packet because offchanel + stop_reasons[q] !=0 How should we handle this? SW RoC is handling this by checking for offchannel and bringing the HW out of PS before handing the packet to TX path, so it works fine. -- Thanks, Regards, Chaitanya T K. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
re: iwlwifi: mvm: support sched scan if supported by the fw
Hello David Spinadel,
The patch 35a000b7c1bb: "iwlwifi: mvm: support sched scan if
supported by the fw" from Aug 28, 2013, leads to the following static
checker warning:
drivers/net/wireless/intel/iwlwifi/mvm/scan.c:572
iwl_mvm_lmac_scan_abort()
error: uninitialized symbol 'status'.
drivers/net/wireless/intel/iwlwifi/mvm/scan.c
560 static int iwl_mvm_lmac_scan_abort(struct iwl_mvm *mvm)
561 {
562 int ret;
563 struct iwl_host_cmd cmd = {
564 .id = SCAN_OFFLOAD_ABORT_CMD,
565 };
566 u32 status;
567
568 ret = iwl_mvm_send_cmd_status(mvm, &cmd, &status);
569 if (ret)
570 return ret;
571
572 if (status != CAN_ABORT_STATUS) {
^^
There is a "success" path in iwl_mvm_send_cmd_status() where we don't
set status. It's commented inside the function.
573 /*
574 * The scan abort will return 1 for success or
575 * 2 for "failure". A failure condition can be
576 * due to simply not being in an active scan which
577 * can occur if we send the scan abort before the
578 * microcode has notified us that a scan is completed.
579 */
580 IWL_DEBUG_SCAN(mvm, "SCAN OFFLOAD ABORT ret %d.\n",
status);
581 ret = -ENOENT;
582 }
583
584 return ret;
585 }
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
re: iwlwifi: add the MVM driver
Hello Johannes Berg,
The patch 8ca151b568b6: "iwlwifi: add the MVM driver" from Jan 24,
2013, leads to the following static checker warning:
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2080 __iwl_mvm_resume()
error: uninitialized symbol 'd3_status'.
drivers/net/wireless/intel/iwlwifi/mvm/d3.c
2057 static int __iwl_mvm_resume(struct iwl_mvm *mvm, bool test)
2058 {
2059 struct ieee80211_vif *vif = NULL;
2060 int ret = 1;
2061 enum iwl_d3_status d3_status;
2062 bool keep = false;
2063 bool unified_image = fw_has_capa(&mvm->fw->ucode_capa,
2064
IWL_UCODE_TLV_CAPA_CNSLDTD_D3_D0_IMG);
2065
2066 u32 flags = CMD_ASYNC | CMD_HIGH_PRIO | CMD_SEND_IN_IDLE |
2067 CMD_WAKE_UP_TRANS;
2068
2069 mutex_lock(&mvm->mutex);
2070
2071 /* get the BSS vif pointer again */
2072 vif = iwl_mvm_get_bss_vif(mvm);
2073 if (IS_ERR_OR_NULL(vif))
2074 goto err;
2075
2076 ret = iwl_trans_d3_resume(mvm->trans, &d3_status, test,
!unified_image);
iwl_trans_d3_resume() just calls a resume() function pointer, but if
that pointer is NULL then it's a no-op.
2077 if (ret)
2078 goto err;
2079
2080 if (d3_status != IWL_D3_STATUS_ALIVE) {
^
This would still be uninitialized.
2081 IWL_INFO(mvm, "Device was reset during suspend\n");
2082 goto err;
2083 }
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [01/11] rtl8xxxu: Rename rtl8xxxu.c to rtl8xxxu_core.c
> From: Jes Sorensen > > This renames the core file to rtl8xxxu_core.c in order to allow us to > keep the module nake rtl8xxxu.ko when refactoring the code into > multiple files. > > Signed-off-by: Jes Sorensen Thanks, 11 patches applied to wireless-drivers-next.git: 6c60e65cd092 rtl8xxxu: Rename rtl8xxxu.c to rtl8xxxu_core.c 599119f683e6 rtl8xxxu: move rtl8192e related code into rtl8xxxu_8192e.c 6c46ca3b5f3b rtl8xxxu: move rtl8723b related code into rtl8xxxu_8723b.c 20e3b2e97edd rtl8xxxu: move rtl8723a related code into rtl8xxxu_8723a.c 181725dd4f33 rtl8xxxu: move rtl8188[cr] and rtl8192c related code into rtl8xxxu_8192c.c 97db5a87b0f0 rtl8xxxu: Rename rtl8723a_stop_tx_beacon() to rtl8xxxu_stop_tx_beacon() a46b099ca730 rtl8xxxu: rename rtl8723a_channel_group() to rtl8xxxu_gen1_channel_to_group() 993dd9b425f5 rtl8xxxu: Rename rtl8723a_disabled_to_emu() to rtl8xxxu_disabled_to_emu() 9c0343d4f48b rtl8xxxu: Split rtl8723a_h2c_cmd() into a gen1 and a gen2 version 27c7e89ea77b rtl8xxxu: rtl8xxxu_prepare_calibrate() is never used on gen1 e1ca790c8a32 rtl8xxxu: Remove the now obsolete mbox_ext_reg info from rtl8xxxu_fileops Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtlwifi: rtl818x: Deinline indexed IO functions, save 21568 bytes
> rtl818x_ioread8_idx: 151 bytes, 29 calls > rtl818x_ioread16_idx: 151 bytes, 11 calls > rtl818x_ioread32_idx: 151 bytes, 5 calls > rtl818x_iowrite8_idx: 157 bytes, 117 calls > rtl818x_iowrite16_idx: 158 bytes, 74 calls > rtl818x_iowrite32_idx: 157 bytes, 22 calls > > Each of these functions has a pair of mutex lock/unlock ops, > both of these ops perform atomic updates of memory (on x86, it boils down to > "lock cmpxchg %reg,mem" insn), which are 4-8 times more expensive than > call+return. > > text data bss dec hex filename > 95894242 20860288 35991552 152746082 91ab862 vmlinux_before > 95872674 20860320 35991552 152724546 91a6442 vmlinux > > Signed-off-by: Denys Vlasenko > CC: Larry Finger > CC: Chaoming Li > CC: linux-wireless@vger.kernel.org > CC: linux-ker...@vger.kernel.org Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces
> > This allows a controlling namespace to create radios and move them > > to other namespaces for communication. > Neat. > > I'm curious what the use case is? We use a test environment for integration and regression testing, which allows us to run our networked applications in a simulated environment using many hosts. Something like [1], but based on the full set of (nested) Linux Namespaces. This has been working great to simulate wired networks (using veth and bridges). But as it runs unprivileged using user namespaces, we have hit these permission issues when we tried to integrate support for wireless radios using (the very cool) mac80211_hwsim. hwsim allows us to simulate complex wireless networks using an unmodified userspace software stack. > I'll need some time to review it, it'll likely have to wait until > next week given our holiday here on Thursday (and I'm also off work > tomorrow/Friday) Ok, great, looking forward to your feedback. Best regardsMartin [1]https://wiki.strongswan.org/projects/strongswan/wiki/TestingEnvironment -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] nl80211: Allow privileged operations from user namespaces
While a wiphy can be transferred to network namespaces, a process having
CAP_NET_ADMIN in a non-initial user namespace can not administrate such
devices due to the genetlink GENL_ADMIN_PERM restrictions.
For openvswitch having the same issue, a new GENL_UNS_ADMIN_PERM flag has
been introduced, commit 4a92602aa1cd ("openvswitch: allow management from
inside user namespaces"). This patch changes all privileged operations
operating on a wiphy, dev or wdev to allow their administration using the
same mechanism. All operations use either NEED_WIPHY, NEED_WDEV or
NEED_NETDEV, which implies a namespace aware lookup of the device. The only
exception is NL80211_CMD_SET_WIPHY, which explicitly uses a namespace aware
lookup.
Signed-off-by: Martin Willi
---
net/wireless/nl80211.c | 150 -
1 file changed, 75 insertions(+), 75 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 9bc84a2..df4c897 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10945,7 +10945,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_SET_WIPHY,
.doit = nl80211_set_wiphy,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_RTNL,
},
{
@@ -10961,7 +10961,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_SET_INTERFACE,
.doit = nl80211_set_interface,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV |
NL80211_FLAG_NEED_RTNL,
},
@@ -10969,7 +10969,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_NEW_INTERFACE,
.doit = nl80211_new_interface,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WIPHY |
NL80211_FLAG_NEED_RTNL,
},
@@ -10977,7 +10977,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_DEL_INTERFACE,
.doit = nl80211_del_interface,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV |
NL80211_FLAG_NEED_RTNL,
},
@@ -10985,7 +10985,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_GET_KEY,
.doit = nl80211_get_key,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL,
},
@@ -10993,7 +10993,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_SET_KEY,
.doit = nl80211_set_key,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
@@ -11002,7 +11002,7 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_NEW_KEY,
.doit = nl80211_new_key,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
@@ -11011,14 +11011,14 @@ static const struct genl_ops nl80211_ops[] = {
.cmd = NL80211_CMD_DEL_KEY,
.doit = nl80211_del_key,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL,
},
{
.cmd = NL80211_CMD_SET_BEACON,
.policy = nl80211_policy,
- .flags = GENL_ADMIN_PERM,
+ .flags = GENL_UNS_ADMIN_PERM,
.doit = nl80211_set_beacon,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL,
@@ -11026,7 +11026,7 @@ static const struct genl_ops nl80211_ops[] = {
{
.cmd = NL80211_CMD_START_AP,
.policy = nl80211_policy,
-
[PATCH 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces
While wiphys can be moved into network namespaces over nl80211, the
creation and removal of hwsim radios is currently limited to the initial
namespace. This patch allows management of namespaced radios from the
owning namespace by setting genetlink netnsok.
To prevent two arbitrary namespaces from communicating over the simulated
shared medium, radios are separated by netgroups. Each radio created in
the same namespace lives in the same netgroup and hence can communicate
with other radios in that group. When moving radios to other namespaces,
the netgroup is preserved, so two radios having the same netgroup can
communicate even if not in the same namespace; This allows a controlling
namespace to create radios and move them to other namespaces for
communication.
Signed-off-by: Martin Willi
---
drivers/net/wireless/mac80211_hwsim.c | 88 +--
1 file changed, 85 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index c757f14..91bd440 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -30,6 +30,8 @@
#include
#include
#include
+#include
+#include
#include "mac80211_hwsim.h"
#define WARN_QUEUE 100
@@ -39,6 +41,7 @@ MODULE_AUTHOR("Jouni Malinen");
MODULE_DESCRIPTION("Software simulator of 802.11 radio(s) for mac80211");
MODULE_LICENSE("GPL");
+static unsigned int hwsim_net_id;
static u32 wmediumd_portid;
static int radios = 2;
@@ -526,6 +529,9 @@ struct mac80211_hwsim_data {
*/
u64 group;
+ /* group shared by radios created in the same netns */
+ int netgroup;
+
int power_level;
/* difference between this hw's clock and the real clock, in usecs */
@@ -568,6 +574,7 @@ static struct genl_family hwsim_genl_family = {
.name = "MAC80211_HWSIM",
.version = 1,
.maxattr = HWSIM_ATTR_MAX,
+ .netnsok = true,
};
enum hwsim_multicast_groups {
@@ -1202,6 +1209,9 @@ static bool mac80211_hwsim_tx_frame_no_nl(struct
ieee80211_hw *hw,
if (!(data->group & data2->group))
continue;
+ if (data->netgroup != data2->netgroup)
+ continue;
+
if (!hwsim_chans_compat(chan, data2->tmp_chan) &&
!hwsim_chans_compat(chan, data2->channel)) {
ieee80211_iterate_active_interfaces_atomic(
@@ -2348,6 +2358,7 @@ static int mac80211_hwsim_new_radio(struct genl_info
*info,
struct mac80211_hwsim_data *data;
struct ieee80211_hw *hw;
enum nl80211_band band;
+ struct net *net;
const struct ieee80211_ops *ops = &mac80211_hwsim_ops;
int idx;
@@ -2366,6 +2377,13 @@ static int mac80211_hwsim_new_radio(struct genl_info
*info,
err = -ENOMEM;
goto failed;
}
+
+ if (info)
+ net = genl_info_net(info);
+ else
+ net = &init_net;
+ wiphy_net_set(hw->wiphy, net);
+
data = hw->priv;
data->hw = hw;
@@ -2541,6 +2559,8 @@ static int mac80211_hwsim_new_radio(struct genl_info
*info,
data->group = 1;
mutex_init(&data->mutex);
+ data->netgroup = *(int *)net_generic(net, hwsim_net_id);
+
/* Enable frame retransmissions for lossy channels */
hw->max_rates = 4;
hw->max_rate_tries = 11;
@@ -3013,6 +3033,9 @@ static int hwsim_del_radio_nl(struct sk_buff *msg, struct
genl_info *info)
continue;
}
+ if (!net_eq(wiphy_net(data->hw->wiphy), genl_info_net(info)))
+ continue;
+
list_del(&data->list);
spin_unlock_bh(&hwsim_radio_lock);
mac80211_hwsim_del_radio(data, wiphy_name(data->hw->wiphy),
@@ -3039,6 +3062,9 @@ static int hwsim_get_radio_nl(struct sk_buff *msg, struct
genl_info *info)
if (data->idx != idx)
continue;
+ if (!net_eq(wiphy_net(data->hw->wiphy), genl_info_net(info)))
+ continue;
+
skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
if (!skb) {
res = -ENOMEM;
@@ -3078,6 +3104,9 @@ static int hwsim_dump_radio_nl(struct sk_buff *skb,
if (data->idx < idx)
continue;
+ if (!net_eq(wiphy_net(data->hw->wiphy), sock_net(skb->sk)))
+ continue;
+
res = mac80211_hwsim_get_radio(skb, data,
NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq, cb,
@@ -3117,13 +3146,13 @@ static const struct genl_ops hwsim_ops[] = {
.cmd = HWSIM_CMD_NEW_RADIO,
.policy = hwsim_genl_policy,
.doit = hwsim_new_radio_nl,
-
[PATCH 0/2] wireless: Allow wiphy/hwsim management from user namespaces
This patch set enables user namespaces having CAP_NET_ADMIN to manage wiphy devices and create/destroy hwsim radios. The first patch allows a caller from a non-initial user namespace to run privileged nl80211 phy/dev operations. The second patch enables hwsim radio management over Netlink from such namespaces. Together, with these patches an unprivileged test environment can create user/network namespaces and set up abitrary simulated wireless networks. Martin Willi (2): nl80211: Allow privileged operations from user namespaces mac80211_hwsim: Allow managing radios from non-initial namespaces drivers/net/wireless/mac80211_hwsim.c | 88 +++- net/wireless/nl80211.c| 150 +- 2 files changed, 160 insertions(+), 78 deletions(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
