* Re: NetworkManager not connecting anymore
From: Arend van Spriel @ 2013-09-30 14:20 UTC (permalink / raw)
To: Dan Williams; +Cc: Arend van Spriel, linux-wireless
In-Reply-To: <1380549653.6136.4.camel@dcbw.foobar.com>
On 09/30/13 16:00, Dan Williams wrote:
> On Sun, 2013-09-29 at 11:11 +0200, Arend van Spriel wrote:
>> 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]
>
> 'unavailable' could mean a couple things:
>
> 1) supplicant isn't running or can't be contacted via D-Bus
Hi Dan,
Thanks for explaining. 1) seems to be the issue. 'ps -ae | grep wpa' did
not return anything. I decided to remove and install wpa_supplicant.
Sometimes the helpdesk approach works ;-)
Regards,
Arend
^ permalink raw reply
* Re: NetworkManager not connecting anymore
From: Dan Williams @ 2013-09-30 14:00 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <CAJ65rDzRUZcZG5+iz2TeQLW7YS+T5xD+M-BxpJp23N=W4dn1+g@mail.gmail.com>
On Sun, 2013-09-29 at 11:11 +0200, Arend van Spriel wrote:
> 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]
'unavailable' could mean a couple things:
1) supplicant isn't running or can't be contacted via D-Bus
2) rfkill is blocking wifi
3) the driver returned ENOENT in response to the dev_open() call,
indicating that it does not have any firmware available
The logs you've posted don't look complete; do you get *anything* else
shown? You can also:
killall -TERM NetworkManager
NetworkManager --no-daemon --log-level=debug
to get more information.
Let me know,
Dan
^ permalink raw reply
* Re: [PATCH] ti-connectivity: add wl1251 firmware and license
From: Felipe Balbi @ 2013-09-30 13:32 UTC (permalink / raw)
To: Ben Hutchings
Cc: balbi, Luca Coelho, Linux Kernel Mailing List, linux-wireless,
Pavel Machek
In-Reply-To: <1380512269.1441.10.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
On Mon, Sep 30, 2013 at 04:37:49AM +0100, Ben Hutchings wrote:
> 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.
yeah, give me a couple more days, I need to finish something up here.
cheers
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: ath9k AR9287 status?
From: Oleksij Rempel @ 2013-09-30 13:27 UTC (permalink / raw)
To: Bruno Randolf, linux-wireless, nbd, sujith; +Cc: Ingo Randolf
In-Reply-To: <524954BE.8060603@einfach.org>
Am 30.09.2013 12:38, schrieb Bruno Randolf:
> On 09/30/2013 10:28 AM, Oleksij Rempel wrote:
>> It works at least for me, as AP and as STA...
>
> Thanks, good to hear! :)
>
>> Check:
>> - PCIe related power managment - ASPM.
>
> That sounds most suspicious. Will try to see what can be done in the
> BIOS or if disabling ASPM in the kernel helps.
>
>> - WiFi related PM. "iw dev wlan0 get power_save"
>
> That would only affect STA and IBSS mode, right?
>
>> - defect device?
>
> Having the same problem on two setups... maybe but it's unlikely...
>
>>> 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 have tried with 3.2 clean (Ubuntu 12.04 default) and with the
> mentioned backports version. If you point me to a known working
> backports version I can try it.
I use 3.11 right now. In case of PCIe issue, backport wont help you.
Test completely new kernel.
What is your host hardware?
>>> 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)
>
> integrated bluetooth 4.0; 8bit Spectral Scan?
Here are some descriptions:
http://wikidevi.com/wiki/Atheros_WiFi_Support
--
Regards,
Oleksij
^ permalink raw reply
* [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Lorenzo Bianconi @ 2013-09-30 12:52 UTC (permalink / raw)
To: linville; +Cc: simon.wunderlich, linux-wireless, johannes
Allow management frame injection on DFS channels if the channel has been CAC
checked and is available
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
---
net/mac80211/tx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 3456c04..edb1d3e 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1694,8 +1694,10 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
* radar detection by itself. We can do that later by adding a
* monitor flag interfaces used for AP support.
*/
- if ((chan->flags & (IEEE80211_CHAN_NO_IBSS | IEEE80211_CHAN_RADAR |
- IEEE80211_CHAN_PASSIVE_SCAN)))
+ if (((chan->flags & (IEEE80211_CHAN_PASSIVE_SCAN |
+ IEEE80211_CHAN_NO_IBSS))) ||
+ ((chan->flags & IEEE80211_CHAN_RADAR) &&
+ chan->dfs_state != NL80211_DFS_AVAILABLE))
goto fail_rcu;
ieee80211_xmit(sdata, skb, chan->band);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
From: Hans Verkuil @ 2013-09-30 11:57 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel, Mauro Carvalho Chehab, Greg Kroah-Hartman
In-Reply-To: <E1VMm13-0007hO-9l@rmk-PC.arm.linux.org.uk>
On 09/19/2013 11:44 PM, Russell King wrote:
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Regards,
Hans
> ---
> drivers/staging/media/dt3155v4l/dt3155v4l.c | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c b/drivers/staging/media/dt3155v4l/dt3155v4l.c
> index 90d6ac4..081407b 100644
> --- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
> +++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
> @@ -901,10 +901,7 @@ dt3155_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> int err;
> struct dt3155_priv *pd;
>
> - err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> - if (err)
> - return -ENODEV;
> - err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> if (err)
> return -ENODEV;
> pd = kzalloc(sizeof(*pd), GFP_KERNEL);
>
^ permalink raw reply
* linux-next: manual merge of the wireless-next tree
From: Thierry Reding @ 2013-09-30 11:26 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, linux-next, linux-kernel
In-Reply-To: <1380540373-25352-1-git-send-email-treding@nvidia.com>
Today's linux-next merge of the wireless-next tree got conflicts in
drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
I fixed it up (see below). Please check if the resolution looks correct.
Thanks,
Thierry
---
diff --cc drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
index f8973e5,80a0893..bb319b0
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
@@@ -217,10 -222,10 +215,9 @@@ void _rtl92ce_phy_lc_calibrate(struct i
void rtl92c_phy_set_rfpath_switch(struct ieee80211_hw *hw, bool bmain);
bool rtl92c_phy_config_rf_with_headerfile(struct ieee80211_hw *hw,
enum radio_path rfpath);
-bool rtl8192_phy_check_is_legal_rfpath(struct ieee80211_hw *hw,
- u32 rfpath);
+bool rtl8192_phy_check_is_legal_rfpath(struct ieee80211_hw *hw, u32 rfpath);
- bool rtl92c_phy_set_io_cmd(struct ieee80211_hw *hw, enum io_type iotype);
bool rtl92ce_phy_set_rf_power_state(struct ieee80211_hw *hw,
- enum rf_pwrstate rfpwr_state);
+ enum rf_pwrstate rfpwr_state);
void rtl92ce_phy_set_rf_on(struct ieee80211_hw *hw);
bool rtl92c_phy_set_io_cmd(struct ieee80211_hw *hw, enum io_type iotype);
void rtl92c_phy_set_io(struct ieee80211_hw *hw);
^ permalink raw reply
* Re: [PATCH 3.12] mac80211: fix a tx power handling regression
From: Felix Fietkau @ 2013-09-30 10:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1380537498.14467.10.camel@jlt4.sipsolutions.net>
On 2013-09-30 12:38 PM, Johannes Berg wrote:
> On Mon, 2013-09-30 at 11:43 +0200, Felix Fietkau wrote:
>> 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?
> Yes, but not all drivers support per-interface TX power I guess?
>
>> 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.
>
> Not sure I see why? It's an absolute value after we do the calculations
> in that interface that has the TPC.
Maybe we need to rework this somehow, but in the mean time, this patch
fixes a serious regression that I've been looking into for a while now.
I haven't worked out the exact conditions that trigger this yet, but
often when an AP VLAN gets destroyed and recreated, or when a new
temporary interface is brought up and then down again, the tx power for
*all* interfaces gets reset to the lowest possible level.
- Felix
^ permalink raw reply
* Re: ath9k AR9287 status?
From: Bruno Randolf @ 2013-09-30 10:38 UTC (permalink / raw)
To: Oleksij Rempel, linux-wireless, nbd, sujith; +Cc: Ingo Randolf
In-Reply-To: <5249443E.3080700@rempel-privat.de>
On 09/30/2013 10:28 AM, Oleksij Rempel wrote:
> It works at least for me, as AP and as STA...
Thanks, good to hear! :)
> Check:
> - PCIe related power managment - ASPM.
That sounds most suspicious. Will try to see what can be done in the
BIOS or if disabling ASPM in the kernel helps.
> - WiFi related PM. "iw dev wlan0 get power_save"
That would only affect STA and IBSS mode, right?
> - defect device?
Having the same problem on two setups... maybe but it's unlikely...
>> 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 have tried with 3.2 clean (Ubuntu 12.04 default) and with the
mentioned backports version. If you point me to a known working
backports version I can try it.
>> 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)
integrated bluetooth 4.0; 8bit Spectral Scan?
Thanks!
bruno
^ permalink raw reply
* Re: [PATCH 3.12] mac80211: fix a tx power handling regression
From: Johannes Berg @ 2013-09-30 10:38 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <524947C0.7060607@openwrt.org>
On Mon, 2013-09-30 at 11:43 +0200, Felix Fietkau wrote:
> 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?
Yes, but not all drivers support per-interface TX power I guess?
> 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.
Not sure I see why? It's an absolute value after we do the calculations
in that interface that has the TPC.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Run deferred scan if last roc_list item is not started
From: Johannes Berg @ 2013-09-30 10:37 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <20130930093605.GA23614@w1.fi>
On Mon, 2013-09-30 at 12:36 +0300, Jouni Malinen wrote:
> 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.
Applied.
johannes
^ permalink raw reply
* 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
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