* Re: [PATCH 3.12 2/2] mac80211: update sta->last_rx on acked tx frames
From: Johannes Berg @ 2013-09-30 10:34 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <52494861.8010007@openwrt.org>
On Mon, 2013-09-30 at 11:46 +0200, Felix Fietkau wrote:
> On 2013-09-30 11:10 AM, Johannes Berg wrote:
> > On Sun, 2013-09-29 at 21:39 +0200, Felix Fietkau wrote:
> >> When clients are idle for too long, hostapd sends nullfunc frames for
> >> probing. When those are acked by the client, the idle time needs to be
> >> updated.
> >>
> >> To make this work (and to avoid unnecessary probing), update sta->last_rx
> >> whenever an ACK was received for a tx packet. Only do this if the flag
> >> IEEE80211_HW_REPORTS_TX_ACK_STATUS is set.
> >
> > Why that last bit? If we got an ack status, wouldn't it be OK to do
> > either way? Or are you saying drivers are lying more often than not
> > otherwise?
> I added that just in case, some drivers might not be fully reliable wrt.
> reporting the ACK status.
Ok, I'll apply it.
johannes
^ permalink raw reply
* Re: [PATCH 3.12 2/2] mac80211: update sta->last_rx on acked tx frames
From: Felix Fietkau @ 2013-09-30 9:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1380532248.14467.4.camel@jlt4.sipsolutions.net>
On 2013-09-30 11:10 AM, Johannes Berg wrote:
> On Sun, 2013-09-29 at 21:39 +0200, Felix Fietkau wrote:
>> When clients are idle for too long, hostapd sends nullfunc frames for
>> probing. When those are acked by the client, the idle time needs to be
>> updated.
>>
>> To make this work (and to avoid unnecessary probing), update sta->last_rx
>> whenever an ACK was received for a tx packet. Only do this if the flag
>> IEEE80211_HW_REPORTS_TX_ACK_STATUS is set.
>
> Why that last bit? If we got an ack status, wouldn't it be OK to do
> either way? Or are you saying drivers are lying more often than not
> otherwise?
I added that just in case, some drivers might not be fully reliable wrt.
reporting the ACK status.
- Felix
^ permalink raw reply
* [PATCH] iw: use nl80211 for phy_lookup function
From: Javier Lopez @ 2013-09-30 9:44 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Javier Lopez
Original implementation uses sysfs to get dev index from
dev name. Due the changes on netns and sysfs iw is broken
if using multiple network namespaces. iw works properly
if using it from the main namespace, but it won't work if
using from the new namespace.
Kernel commit 3ff195b0, "sysfs: Implement sysfs tagged
directory support" patch, added a filtering mechanism
to sysfs, allowing sysfs directories to look different
depending on the context where they are being observed.
When an interface is moved to another namespace, the
interface dissapears from sysfs structure. In order
to recover access to the directory a solution is to
remount sysfs from the correct context. This will force
the user to remount sysfs before using iw from a
different namespace.
To avoid this issue we can use nl80211 (using
NL80211_CMD_GET_WIPHY command) this returns the list of
phys, then process the list, find the device and return
the device index.
Signed-off-by: Javier Lopez <jlopex@cozybit.com>
---
iw.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++---------------
1 file changed, 78 insertions(+), 23 deletions(-)
diff --git a/iw.c b/iw.c
index dc99566..23c0386 100644
--- a/iw.c
+++ b/iw.c
@@ -23,6 +23,12 @@
#include "nl80211.h"
#include "iw.h"
+struct lookup_data
+{
+ char *name;
+ int idx;
+};
+
/* libnl 1.x compatibility code */
#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30)
static inline struct nl_handle *nl_socket_alloc(void)
@@ -251,26 +257,6 @@ static void version(void)
printf("iw version %s\n", iw_version);
}
-static int phy_lookup(char *name)
-{
- char buf[200];
- int fd, pos;
-
- snprintf(buf, sizeof(buf), "/sys/class/ieee80211/%s/index", name);
-
- fd = open(buf, O_RDONLY);
- if (fd < 0)
- return -1;
- pos = read(fd, buf, sizeof(buf) - 1);
- if (pos < 0) {
- close(fd);
- return -1;
- }
- buf[pos] = '\0';
- close(fd);
- return atoi(buf);
-}
-
static int error_handler(struct sockaddr_nl *nla, struct nlmsgerr *err,
void *arg)
{
@@ -293,6 +279,75 @@ static int ack_handler(struct nl_msg *msg, void *arg)
return NL_STOP;
}
+static int lookup_handler(struct nl_msg *msg, void *arg)
+{
+ struct nlattr *tb_msg[NL80211_ATTR_MAX + 1];
+ struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
+ struct lookup_data *data = (struct lookup_data*) arg;
+
+ nla_parse(tb_msg, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
+ genlmsg_attrlen(gnlh, 0), NULL);
+
+ if (tb_msg[NL80211_ATTR_WIPHY_NAME]) {
+ if (strcmp(nla_get_string(tb_msg[NL80211_ATTR_WIPHY_NAME]),
+ data->name) == 0) {
+ data->idx = nla_get_u32(tb_msg[NL80211_ATTR_WIPHY]);
+ return NL_STOP;
+ }
+ }
+ return NL_SKIP;
+}
+
+static int phy_lookup(struct nl80211_state *state, char *name)
+{
+ struct nl_cb *cb;
+ struct nl_msg *msg;
+ struct lookup_data data;
+ int err;
+
+ data.name = name;
+ data.idx = -1;
+
+ msg = nlmsg_alloc();
+ if (!msg) {
+ fprintf(stderr, "failed to allocate netlink message\n");
+ return -ENOMEM;
+ }
+
+ cb = nl_cb_alloc(iw_debug ? NL_CB_DEBUG : NL_CB_DEFAULT);
+ if (!cb) {
+ fprintf(stderr, "failed to allocate netlink callbacks\n");
+ err = -ENOMEM;
+ goto out_free_msg;
+ }
+
+ genlmsg_put(msg, 0, 0, state->nl80211_id, 0,
+ NLM_F_DUMP, NL80211_CMD_GET_WIPHY, 0);
+
+ err = nl_send_auto_complete(state->nl_sock, msg);
+ if (err < 0)
+ goto out;
+
+ err = 1;
+
+ nl_cb_set(cb, NL_CB_VALID, NL_CB_CUSTOM, lookup_handler, &data);
+ nl_cb_err(cb, NL_CB_CUSTOM, error_handler, &err);
+ nl_cb_set(cb, NL_CB_FINISH, NL_CB_CUSTOM, finish_handler, &err);
+ nl_cb_set(cb, NL_CB_ACK, NL_CB_CUSTOM, ack_handler, &err);
+
+ while (err > 0)
+ nl_recvmsgs(state->nl_sock, cb);
+ out:
+ nl_cb_put(cb);
+ out_free_msg:
+ nlmsg_free(msg);
+ if (data.idx != -1)
+ return data.idx;
+ else if (err == 0)
+ return -ENODEV;
+ return err;
+}
+
static int __handle_cmd(struct nl80211_state *state, enum id_input idby,
int argc, char **argv, const struct cmd **cmdout)
{
@@ -323,7 +378,7 @@ static int __handle_cmd(struct nl80211_state *state, enum id_input idby,
break;
case II_PHY_NAME:
command_idby = CIB_PHY;
- devidx = phy_lookup(*argv);
+ devidx = phy_lookup(state, *argv);
argc--;
argv++;
break;
@@ -347,7 +402,7 @@ static int __handle_cmd(struct nl80211_state *state, enum id_input idby,
}
if (devidx < 0)
- return -errno;
+ return devidx;
section = *argv;
argc--;
@@ -548,7 +603,7 @@ int main(int argc, char **argv)
detect:
if ((idx = if_nametoindex(argv[0])) != 0)
idby = II_NETDEV;
- else if ((idx = phy_lookup(argv[0])) >= 0)
+ else if ((idx = phy_lookup(&nlstate, argv[0])) >= 0)
idby = II_PHY_NAME;
err = __handle_cmd(&nlstate, idby, argc, argv, &cmd);
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 3.12] mac80211: fix a tx power handling regression
From: Felix Fietkau @ 2013-09-30 9:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1380532158.14467.3.camel@jlt4.sipsolutions.net>
On 2013-09-30 11:09 AM, Johannes Berg wrote:
> On Sun, 2013-09-29 at 14:48 +0200, Felix Fietkau wrote:
>> commit 1ea6f9c0d48b11b6ec3ec4b5579ec74fc3951cf8
>> "mac80211: handle TX power per virtual interface"
>>
>> This commit added support for tracking tx power configuration for
>> multiple interfaces, however instead of using the maximum value of all
>> virtual interfaces, it uses the minimum.
>
> I'm not sure it should be using the maximum? What if the AP required
> lowering TX power by way of TPC for example?
Shouldn't that only affect the virtual interface that is connected to
that AP?
If there's a regulatory requirement to use lower tx power, it should be
tracked as a limit somewhere else instead of implicitly being handled
via vif tx power configuration.
- Felix
^ permalink raw reply
* [PATCH] mac80211: Run deferred scan if last roc_list item is not started
From: Jouni Malinen @ 2013-09-30 9:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
mac80211 scan processing could get stuck if roc work for pending, but
not started when a scan request was deferred due to such roc item.
Normally the deferred scan would be started from
ieee80211_start_next_roc(), but ieee80211_sw_roc_work() calls that only
if the finished ROC was started. Fix this by calling
ieee80211_run_deferred_scan() in the case the last ROC was not actually
started.
This issue was hit relatively easily in P2P find operations where Listen
state (remain-on-channel) and Search state (scan) are repeated in a
loop.
Signed-off-by: Jouni Malinen <j@w1.fi>
---
net/mac80211/offchannel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
index acd1f71..0c2a294 100644
--- a/net/mac80211/offchannel.c
+++ b/net/mac80211/offchannel.c
@@ -394,6 +394,8 @@ void ieee80211_sw_roc_work(struct work_struct *work)
if (started)
ieee80211_start_next_roc(local);
+ else if (list_empty(&local->roc_list))
+ ieee80211_run_deferred_scan(local);
}
out_unlock:
--
1.7.9.5
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply related
* Re: [PATCH] iw: sync frequency to channel mapping with kernel
From: Johannes Berg @ 2013-09-30 9:32 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linux-wireless
In-Reply-To: <1380213945-31815-1-git-send-email-br1@einfach.org>
On Thu, 2013-09-26 at 17:45 +0100, Bruno Randolf wrote:
> Use ieee80211_frequency_to_channel() and ieee80211_channel_to_frequency() as in
> the current kernel. This is necessary to properly print the channel numbers for
> 4.9GHz channels which can be used in Japan.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH 3.12 1/2] mac80211: use sta_info_get_bss() for nl80211 tx and client probing
From: Johannes Berg @ 2013-09-30 9:31 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <1380483574-88667-1-git-send-email-nbd@openwrt.org>
On Sun, 2013-09-29 at 21:39 +0200, Felix Fietkau wrote:
> This allows calls for clients in AP_VLANs (e.g. for 4-addr) to succeed
Applied.
johannes
^ permalink raw reply
* Re: ath9k AR9287 status?
From: Oleksij Rempel @ 2013-09-30 9:28 UTC (permalink / raw)
To: Bruno Randolf, linux-wireless, nbd, sujith; +Cc: Ingo Randolf
In-Reply-To: <52492FB0.3010201@einfach.org>
Hi Bruno,
Am 30.09.2013 10:00, schrieb Bruno Randolf:
> Hello!
>
> What is the status of AR9287 support in ath9k?
It works at least for me, as AP and as STA...
But some people have different issues, looks like, mostly with old kernels.
You can find some of them:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/838016
http://pleph.appspot.com/init/posts/view/2657865
Check:
- PCIe related power managment - ASPM.
- WiFi related PM. "iw dev wlan0 get power_save"
- defect device?
> I have a AR9287 PCI-Express card which is behaving more than weird with
> kernel 3.2 and with the current (3.10.4-1) backports drivers: It can't
> connect to APs (many reconnects), with hostap it _seems_ to work as an
> AP, but no beacons are seen and no stations can connect, similar in
> ad-hoc mode, and when bringing the interface down the whole system
> freezes...
Is it regression? Are there any working kernel version?
> I've seen some related bugs in the bugtracker, but I wonder what the
> experiences with this chipset are in general?
actually not so bad :) like i said it works for me rally good.
> Or - can anyone recommend a good half size PCI-Express card that works
> well with ath9k?
If you wont to bay some new toy, then take a look here:
http://wikidevi.com/wiki/Atheros
I would take AR9462, there are some interesting highlights ;) (suddenly
I do not have it right now)
--
Regards,
Oleksij
^ permalink raw reply
* Re: [PATCH 3.12 2/2] mac80211: update sta->last_rx on acked tx frames
From: Johannes Berg @ 2013-09-30 9:10 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <1380483574-88667-2-git-send-email-nbd@openwrt.org>
On Sun, 2013-09-29 at 21:39 +0200, Felix Fietkau wrote:
> When clients are idle for too long, hostapd sends nullfunc frames for
> probing. When those are acked by the client, the idle time needs to be
> updated.
>
> To make this work (and to avoid unnecessary probing), update sta->last_rx
> whenever an ACK was received for a tx packet. Only do this if the flag
> IEEE80211_HW_REPORTS_TX_ACK_STATUS is set.
Why that last bit? If we got an ack status, wouldn't it be OK to do
either way? Or are you saying drivers are lying more often than not
otherwise?
johannes
^ permalink raw reply
* Re: [PATCH 3.12] mac80211: fix a tx power handling regression
From: Johannes Berg @ 2013-09-30 9:09 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <1380458883-19862-1-git-send-email-nbd@openwrt.org>
On Sun, 2013-09-29 at 14:48 +0200, Felix Fietkau wrote:
> commit 1ea6f9c0d48b11b6ec3ec4b5579ec74fc3951cf8
> "mac80211: handle TX power per virtual interface"
>
> This commit added support for tracking tx power configuration for
> multiple interfaces, however instead of using the maximum value of all
> virtual interfaces, it uses the minimum.
I'm not sure it should be using the maximum? What if the AP required
lowering TX power by way of TPC for example?
johannes
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix merge damage
From: Johannes Berg @ 2013-09-30 9:07 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
In-Reply-To: <1380531766-15384-1-git-send-email-johannes@sipsolutions.net>
On Mon, 2013-09-30 at 11:02 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> The merge b35c8097 seems to have lost commit eabc4ac5d,
> put the code back.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Ah, forgot to say - John, I think you should apply this as a patch,
having it in my pull request seems odd. But if you're of another opinion
I can stick it into my next -next pull request too.
johannes
^ permalink raw reply
* [PATCH] iwlwifi: pcie: fix merge damage
From: Johannes Berg @ 2013-09-30 9:02 UTC (permalink / raw)
To: linux-wireless, linville; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
The merge b35c8097 seems to have lost commit eabc4ac5d,
put the code back.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/iwlwifi/pcie/trans.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/pcie/trans.c b/drivers/net/wireless/iwlwifi/pcie/trans.c
index bad95d2..c3f904d 100644
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@ -1401,6 +1401,10 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
spin_lock_init(&trans_pcie->reg_lock);
init_waitqueue_head(&trans_pcie->ucode_write_waitq);
+ err = pci_enable_device(pdev);
+ if (err)
+ goto out_no_pci;
+
if (!cfg->base_params->pcie_l1_allowed) {
/*
* W/A - seems to solve weird behavior. We need to remove this
@@ -1412,10 +1416,6 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
PCIE_LINK_STATE_CLKPM);
}
- err = pci_enable_device(pdev);
- if (err)
- goto out_no_pci;
-
pci_set_master(pdev);
err = pci_set_dma_mask(pdev, DMA_BIT_MASK(36));
--
1.8.4.rc3
^ permalink raw reply related
* Fwd: NetworkManager not connecting anymore
From: Arend van Spriel @ 2013-09-30 8:31 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAJ65rDzRUZcZG5+iz2TeQLW7YS+T5xD+M-BxpJp23N=W4dn1+g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
Resending. Bounced by linux-wireless, because my gmail used HTML
---------- Forwarded message ----------
From: Arend van Spriel <aspriel@gmail.com>
Date: Sun, Sep 29, 2013 at 11:11 AM
Subject: NetworkManager not connecting anymore
To: Dan Williams <dcbw@redhat.com>
Cc: linux-wireless@vger.kernel.org
With a recent update on my Ubuntu 12.10 laptop, wireless connection is
no longer working with NetworkManager. It is working when using
wpa_supplicant directly. The nm-applet indicates 'device not ready'
for the Wireless Networks. Attached is the syslog upon inserting the
wireless driver module, which is brcmsmac. Not sure if the state
change below correlates to the nm-applet status.
NetworkManager[1121]: <info> (wlan0): device state change: unmanaged
-> unavailable (reason 'managed') [10 20 2]
Regards,
Arend van Spriel
[-- Attachment #2: syslog-nm-wifi-issue --]
[-- Type: application/octet-stream, Size: 12938 bytes --]
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.266150] brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 17
Sep 28 18:41:38 arend-ubuntu-1 NetworkManager[1121]: <info> found WiFi radio killswitch rfkill7 (at /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/bcma0:0/ieee80211/phy5/rfkill7) (driver (unknown))
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275500] cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275504] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275505] cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275506] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275507] cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275508] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275509] cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275510] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275511] cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275512] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275513] cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275514] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275515] cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275516] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275517] cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275518] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275519] cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275520] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275521] cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275523] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275523] cfg80211: Updating information on frequency 2462 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275525] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275525] cfg80211: Updating information on frequency 2467 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275527] cfg80211: 2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275528] cfg80211: Updating information on frequency 2472 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275529] cfg80211: 2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A mBi, 1900 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275530] cfg80211: Disabling freq 2484 MHz as custom regd has no rule that fits a 20 MHz wide channel
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275531] cfg80211: Updating information on frequency 5180 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275532] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275533] cfg80211: Updating information on frequency 5200 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275534] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275535] cfg80211: Updating information on frequency 5220 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275536] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275537] cfg80211: Updating information on frequency 5240 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275538] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275539] cfg80211: Updating information on frequency 5260 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275540] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275541] cfg80211: Updating information on frequency 5280 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275542] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275543] cfg80211: Updating information on frequency 5300 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275544] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275545] cfg80211: Updating information on frequency 5320 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275546] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275547] cfg80211: Updating information on frequency 5500 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275549] cfg80211: 5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275549] cfg80211: Updating information on frequency 5520 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275551] cfg80211: 5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275552] cfg80211: Updating information on frequency 5540 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275553] cfg80211: 5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275554] cfg80211: Updating information on frequency 5560 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275555] cfg80211: 5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275556] cfg80211: Updating information on frequency 5580 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275557] cfg80211: 5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275558] cfg80211: Updating information on frequency 5600 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275559] cfg80211: 5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275560] cfg80211: Updating information on frequency 5620 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275561] cfg80211: 5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275562] cfg80211: Updating information on frequency 5640 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275563] cfg80211: 5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275564] cfg80211: Updating information on frequency 5660 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275565] cfg80211: 5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275566] cfg80211: Updating information on frequency 5680 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275567] cfg80211: 5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275568] cfg80211: Updating information on frequency 5700 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275569] cfg80211: 5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275570] cfg80211: Updating information on frequency 5745 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275571] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275572] cfg80211: Updating information on frequency 5765 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275574] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275574] cfg80211: Updating information on frequency 5785 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275576] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275577] cfg80211: Updating information on frequency 5805 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275578] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275579] cfg80211: Updating information on frequency 5825 MHz for a 20 MHz width channel with regulatory rule:
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275580] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A mBi, 2100 mBm)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275606] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.275700] ieee80211 phy5: Selected rate control algorithm 'minstrel_ht'
Sep 28 18:41:38 arend-ubuntu-1 NetworkManager[1121]: SCPlugin-Ifupdown: devices added (path: /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/bcma0:0/net/wlan0, iface: wlan0)
Sep 28 18:41:38 arend-ubuntu-1 NetworkManager[1121]: SCPlugin-Ifupdown: device added (path: /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/bcma0:0/net/wlan0, iface: wlan0): no ifupdown configuration found.
Sep 28 18:41:38 arend-ubuntu-1 NetworkManager[1121]: <info> (wlan0): using nl80211 for WiFi device control
Sep 28 18:41:38 arend-ubuntu-1 NetworkManager[1121]: <info> (wlan0): new 802.11 WiFi device (driver: 'brcmsmac' ifindex: 10)
Sep 28 18:41:38 arend-ubuntu-1 NetworkManager[1121]: <info> (wlan0): exported as /org/freedesktop/NetworkManager/Devices/6
Sep 28 18:41:38 arend-ubuntu-1 NetworkManager[1121]: <info> (wlan0): now managed
Sep 28 18:41:38 arend-ubuntu-1 NetworkManager[1121]: <info> (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Sep 28 18:41:38 arend-ubuntu-1 NetworkManager[1121]: <info> (wlan0): bringing up device.
Sep 28 18:41:38 arend-ubuntu-1 NetworkManager[1121]: <info> (wlan0): preparing device.
Sep 28 18:41:38 arend-ubuntu-1 NetworkManager[1121]: <info> (wlan0): deactivating device (reason 'managed') [2]
Sep 28 18:41:38 arend-ubuntu-1 NetworkManager[1121]: <info> (wlan0): supplicant interface state: starting -> init
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.304378] ieee80211 phy5: brcms_ops_bss_info_changed: qos enabled: false (implement)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.304389] ieee80211 phy5: brcms_ops_config: change power-save mode: false (implement)
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.305729] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sep 28 18:41:38 arend-ubuntu-1 kernel: [14922.305957] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
^ permalink raw reply
* ath9k AR9287 status?
From: Bruno Randolf @ 2013-09-30 8:00 UTC (permalink / raw)
To: linux-wireless, nbd, sujith, linux; +Cc: Ingo Randolf
Hello!
What is the status of AR9287 support in ath9k?
I have a AR9287 PCI-Express card which is behaving more than weird with
kernel 3.2 and with the current (3.10.4-1) backports drivers: It can't
connect to APs (many reconnects), with hostap it _seems_ to work as an
AP, but no beacons are seen and no stations can connect, similar in
ad-hoc mode, and when bringing the interface down the whole system
freezes...
I've seen some related bugs in the bugtracker, but I wonder what the
experiences with this chipset are in general?
Or - can anyone recommend a good half size PCI-Express card that works
well with ath9k?
Thanks,
bruno
^ permalink raw reply
* Re: [PATCH] ti-connectivity: add wl1251 firmware and license
From: Ben Hutchings @ 2013-09-30 3:37 UTC (permalink / raw)
To: balbi; +Cc: Luca Coelho, Linux Kernel Mailing List, linux-wireless,
Pavel Machek
In-Reply-To: <20130925132359.GE10746@radagast>
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
On Wed, 2013-09-25 at 08:23 -0500, Felipe Balbi wrote:
> Hi,
>
> On Wed, Sep 25, 2013 at 02:07:58PM +0300, Luca Coelho wrote:
[...]
> > Ah, and I forgot to say that you should update the WHENCE file
> > accordingly too. Check the wl12xx and wl18xx drivers for examples.
>
> I'll send a pull request, but how about this ? I don't think we can
> change the license. It seems like the other firmwares are using the
> older license, I'd argue those should be changed to the new one, but
> that's another discussion.
[...]
I haven't seen this pull request, so it looks like there is nothing for
me to apply at the moment.
Ben.
--
Ben Hutchings
Life is like a sewer:
what you get out of it depends on what you put into it.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] cw1200: Add SDD file for the Sagrad SG901-1091/1098 WLAN modules.
From: Ben Hutchings @ 2013-09-30 3:30 UTC (permalink / raw)
To: Solomon Peachy; +Cc: David Woodhouse, Adam Harriman, linux-wireless
In-Reply-To: <1378335153-23059-1-git-send-email-pizza@shaftnet.org>
On Wed, 2013-09-04 at 18:52 -0400, Solomon Peachy wrote:
> Sagrad has granted permission to redistribute this file, which contains
> calibration and initialization tables for for their WLAN modules.
>
> Please note that the cw1200 driver still requires firmware files, which
> are separately licensed by ST-E. When (if?) explicit permission is
> obtained to redistribute the firmware, it will be added.
>
> Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
> Signed-off-by: Adam Harriman <adam@sagrad.com>
> ---
> WHENCE | 22 ++++++++++++++++++++++
> sdd_sagrad_1091_1098.bin | Bin 0 -> 816 bytes
> 2 files changed, 22 insertions(+)
> create mode 100644 sdd_sagrad_1091_1098.bin
[...]
Applied, thanks.
Ben.
--
Ben Hutchings
Life is like a sewer:
what you get out of it depends on what you put into it.
^ permalink raw reply
* Re: NetworkManager not listing access points
From: Rafał Miłecki @ 2013-09-29 21:11 UTC (permalink / raw)
To: Detlev Casanova
Cc: linux-wireless@vger.kernel.org, Johannes Berg, laurent.pinchart
In-Reply-To: <CACna6rx-8C+jMDG+BL3RQhfqp1+ozbjqamvn=7PzKG=JUa1J_w@mail.gmail.com>
2013/9/29 Rafał Miłecki <zajec5@gmail.com>:
> Scanning on channel b43 is failing even worse starting with that
> commit.
s/b43/13/
--
Rafał
^ permalink raw reply
* Re: NetworkManager not listing access points
From: Rafał Miłecki @ 2013-09-29 21:10 UTC (permalink / raw)
To: Detlev Casanova
Cc: linux-wireless@vger.kernel.org, Johannes Berg, laurent.pinchart
In-Reply-To: <31357461.i5mG9q5IfA@naboo>
2013/9/18 Detlev Casanova <detlev.casanova@gmail.com>:
> After a bisection on the kernel, it seems that a patch is causing a
> problem with NetworkManager:
>
> commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 ("cfg80211:
> use DS or HT operation IEs to determine BSS channel")
>
> (...)
>
> The hardware is: 14e4:4315 (Network controller: Broadcom Corporation
> BCM4312 802.11b/g LP-PHY (rev 01)) on an Intel Core i3 M370 CPU (64
> bits) computer.
See:
http://www.spinics.net/lists/linux-wireless/msg105359.html
("Scanning regression since "cfg80211: use DS or HT operation IEs to
determine BSS channel"")
It seems that starting with the mentioned commit, b43 doesn't report
any results on the 1st scanning. No idea how this patch affected b43.
Scanning on channel b43 is failing even worse starting with that
commit.
--
Rafał
^ permalink raw reply
* [PATCH 3.12 1/2] mac80211: use sta_info_get_bss() for nl80211 tx and client probing
From: Felix Fietkau @ 2013-09-29 19:39 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
This allows calls for clients in AP_VLANs (e.g. for 4-addr) to succeed
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
net/mac80211/cfg.c | 2 +-
net/mac80211/tx.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 2e7855a..629dee7 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -3518,7 +3518,7 @@ static int ieee80211_probe_client(struct wiphy *wiphy, struct net_device *dev,
return -EINVAL;
}
band = chanctx_conf->def.chan->band;
- sta = sta_info_get(sdata, peer);
+ sta = sta_info_get_bss(sdata, peer);
if (sta) {
qos = test_sta_flag(sta, WLAN_STA_WME);
} else {
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 3456c04..70b5a05 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1120,7 +1120,8 @@ ieee80211_tx_prepare(struct ieee80211_sub_if_data *sdata,
tx->sta = rcu_dereference(sdata->u.vlan.sta);
if (!tx->sta && sdata->dev->ieee80211_ptr->use_4addr)
return TX_DROP;
- } else if (info->flags & IEEE80211_TX_CTL_INJECTED ||
+ } else if (info->flags & (IEEE80211_TX_CTL_INJECTED |
+ IEEE80211_TX_INTFL_NL80211_FRAME_TX) ||
tx->sdata->control_port_protocol == tx->skb->protocol) {
tx->sta = sta_info_get_bss(sdata, hdr->addr1);
}
--
1.8.0.2
^ permalink raw reply related
* [PATCH 3.12 2/2] mac80211: update sta->last_rx on acked tx frames
From: Felix Fietkau @ 2013-09-29 19:39 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
In-Reply-To: <1380483574-88667-1-git-send-email-nbd@openwrt.org>
When clients are idle for too long, hostapd sends nullfunc frames for
probing. When those are acked by the client, the idle time needs to be
updated.
To make this work (and to avoid unnecessary probing), update sta->last_rx
whenever an ACK was received for a tx packet. Only do this if the flag
IEEE80211_HW_REPORTS_TX_ACK_STATUS is set.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
net/mac80211/status.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 368837f..78dc2e9 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -180,6 +180,9 @@ static void ieee80211_frame_acked(struct sta_info *sta, struct sk_buff *skb)
struct ieee80211_local *local = sta->local;
struct ieee80211_sub_if_data *sdata = sta->sdata;
+ if (local->hw.flags & IEEE80211_HW_REPORTS_TX_ACK_STATUS)
+ sta->last_rx = jiffies;
+
if (ieee80211_is_data_qos(mgmt->frame_control)) {
struct ieee80211_hdr *hdr = (void *) skb->data;
u8 *qc = ieee80211_get_qos_ctl(hdr);
--
1.8.0.2
^ permalink raw reply related
* Re: NetworkManager not listing access points
From: Detlev Casanova @ 2013-09-29 19:29 UTC (permalink / raw)
To: Dan Williams; +Cc: Johannes Berg, linux-wireless, laurent.pinchart
In-Reply-To: <1379952829.2475.16.camel@dcbw.foobar.com>
Le lundi 23 septembre 2013 11:13:49 Dan Williams a écrit :
> On Sun, 2013-09-22 at 16:20 +0200, Detlev Casanova wrote:
> > Le samedi 21 septembre 2013 22:51:59 Johannes Berg a écrit :
> > > On Thu, 2013-09-19 at 07:58 +0200, Detlev Casanova wrote:
> > > > Here is the output (attached file for formatting)
> > >
> > > Was that from the good case? The bad case would have been
> >
> > more
> >
> > > interesting.
> >
> > This is both cases. I made another one and here, I can give more
> > details:
> >
> > Network manager is trying to list APs and fails until time
> > 1379858724.386569
>
> Ok, the logs indicate that the driver simply doesn't see any scan
> results:
>
> 1379858724.381522: Received scan results (0 BSSes)
>
> Then 20 seconds later (after the explicit iwlist), it finds some scan
> results:
>
> 1379858746.953924: Received scan results (3 BSSes)
>
> So I'm not sure what's going on here, but I don't think NetworkManager
> is the issue; it's likely in the supplicant's scanning code or in the
> driver itself. NetworkManager asks the supplicant to scan with both the
> wildcard SSID and any hidden-tagged SSID, and the wildcard SSID should
> ensure that all available APs are found.
Yes and the problem is most likely to be in the driver because it doesn't
occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 ("cfg80211: use
DS or HT operation IEs to determine BSS channel")
> Johannes, does anything else jump out at you in the logs?
>
> Dan
>
> > The The first "iwlist wlan0 scan" is done juste after the log line
> > (1379858738.682054). It lists the APs in range in the console but
> > not in the Network Manager ui.
> >
> > The second "iwlist wlan0 scan" is done at time 1379858739.802067
> > and APs are being listed in the console and in the Network Manager
> > UI.
> >
> > After that, NM will connect to the acces point with SSID "Maison".
> >
> > It also looks like the listing in Network Manager comes between the
> > moment "iwlist wlan0 scan" is run for the second time and the
> > moment is shows its output on the console.
> >
> > Detlev.
^ permalink raw reply
* Re: Troubleshooting a WLAN Adapter
From: Larry Finger @ 2013-09-29 15:54 UTC (permalink / raw)
To: Arokux X; +Cc: linux-wireless
In-Reply-To: <CAPNxggZ30Ghg03Vza+Vay=txF1vznWD46FBb8rWVM2AGJ+Q1qQ@mail.gmail.com>
On 09/29/2013 06:40 AM, Arokux X wrote:
> Dear Larry, dear all,
>
> may I please draw your attention to the following thread
>
> http://thread.gmane.org/gmane.linux.usb.general/94872
>
> I am working on a USB EHCI bus glue driver. I have tested several USB
> devices and they work. However I cannot get an on-board WLAN Adapter
> (idVendor=0bda, idProduct=8176) working. I have have run out of ideas
> how to troubleshoot the issue. I hope you will have some.
I posted the only fix that I have for USB issues in the gmane thread. I doubt
that it will help you, but it is worth a try.
Larry
^ permalink raw reply
* [PATCH 3.12] mac80211: fix a tx power handling regression
From: Felix Fietkau @ 2013-09-29 12:48 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
commit 1ea6f9c0d48b11b6ec3ec4b5579ec74fc3951cf8
"mac80211: handle TX power per virtual interface"
This commit added support for tracking tx power configuration for
multiple interfaces, however instead of using the maximum value of all
virtual interfaces, it uses the minimum.
This causes the configured tx power to be reset to the absolute minimum
for all virtual interfaces, whenever an interface is created and destroyed
immediately afterwards.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
net/mac80211/main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 21d5d44..87c5509 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -97,7 +97,7 @@ static u32 ieee80211_hw_conf_chan(struct ieee80211_local *local)
struct ieee80211_sub_if_data *sdata;
struct cfg80211_chan_def chandef = {};
u32 changed = 0;
- int power;
+ int power = 0;
u32 offchannel_flag;
offchannel_flag = local->hw.conf.flags & IEEE80211_CONF_OFFCHANNEL;
@@ -142,16 +142,16 @@ static u32 ieee80211_hw_conf_chan(struct ieee80211_local *local)
changed |= IEEE80211_CONF_CHANGE_SMPS;
}
- power = ieee80211_chandef_max_power(&chandef);
-
rcu_read_lock();
list_for_each_entry_rcu(sdata, &local->interfaces, list) {
if (!rcu_access_pointer(sdata->vif.chanctx_conf))
continue;
- power = min(power, sdata->vif.bss_conf.txpower);
+ power = max(power, sdata->vif.bss_conf.txpower);
}
rcu_read_unlock();
+ power = min(power, ieee80211_chandef_max_power(&chandef));
+
if (local->hw.conf.power_level != power) {
changed |= IEEE80211_CONF_CHANGE_POWER;
local->hw.conf.power_level = power;
--
1.8.0.2
^ permalink raw reply related
* Troubleshooting a WLAN Adapter
From: Arokux X @ 2013-09-29 11:40 UTC (permalink / raw)
To: Larry.Finger; +Cc: linux-wireless
Dear Larry, dear all,
may I please draw your attention to the following thread
http://thread.gmane.org/gmane.linux.usb.general/94872
I am working on a USB EHCI bus glue driver. I have tested several USB
devices and they work. However I cannot get an on-board WLAN Adapter
(idVendor=0bda, idProduct=8176) working. I have have run out of ideas
how to troubleshoot the issue. I hope you will have some.
Best regards,
Arokux
^ permalink raw reply
* [PATCH 3.12] ath9k: fix powersave response handling for BA session packets
From: Felix Fietkau @ 2013-09-29 11:06 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
When a packet is passed from mac80211 to the driver with the
IEEE80211_TX_CTL_PS_RESPONSE flag set, it bypasses the normal driver
internal queueing and goes directly to the UAPSD queue.
When that happens, packets that are part of a BlockAck session still
need to be tracked as such inside the driver, otherwise it will create
discrepancies in the receiver BA reorder window, causing traffic stalls.
This only happens in AP mode with powersave-enabled clients.
This patch fixes the regression introduced in the commit
"ath9k: use software queues for un-aggregated data packets"
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 13f5434..1ce8af2 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1969,15 +1969,18 @@ static void ath_tx_txqaddbuf(struct ath_softc *sc, struct ath_txq *txq,
static void ath_tx_send_normal(struct ath_softc *sc, struct ath_txq *txq,
struct ath_atx_tid *tid, struct sk_buff *skb)
{
+ struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
struct ath_frame_info *fi = get_frame_info(skb);
struct list_head bf_head;
- struct ath_buf *bf;
-
- bf = fi->bf;
+ struct ath_buf *bf = fi->bf;
INIT_LIST_HEAD(&bf_head);
list_add_tail(&bf->list, &bf_head);
bf->bf_state.bf_type = 0;
+ if (tid && (tx_info->flags & IEEE80211_TX_CTL_AMPDU)) {
+ bf->bf_state.bf_type = BUF_AMPDU;
+ ath_tx_addto_baw(sc, tid, bf);
+ }
bf->bf_next = NULL;
bf->bf_lastbf = bf;
--
1.8.0.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox