* Re: [PATCH] mac80211: fix autoloading of crypto modules for WEP
From: Herbert Xu @ 2009-07-23 0:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andreas Oberritter, linux-wireless
In-Reply-To: <1248294007.19121.9.camel@johannes.local>
On Wed, Jul 22, 2009 at 10:20:07PM +0200, Johannes Berg wrote:
> On Wed, 2009-07-22 at 22:05 +0200, Andreas Oberritter wrote:
> > If at least one of arc4 and ecb is built as a module, then autoloading
> > of the algorithm fails, because crypto_alloc_blkcipher tries to
> > request the module "ecb(arc4)", which does not exist.
> >
> > This patch was made against 2.6.30, but should apply cleanly on top of
> > the wireless-2.6 git tree.
>
> > + /*
> > + * crypto_alloc_blkcipher() will request the
> > + * module "ecb(arc4)", which does not exist.
> > + */
> > +#ifdef CONFIG_CRYPTO_ARC4_MODULE
> > + request_module("arc4");
> > +#endif
> > +#ifdef CONFIG_CRYPTO_ECB_MODULE
> > + request_module("ecb");
> > +#endif
> > +
> > local->wep_tx_tfm = crypto_alloc_blkcipher("ecb(arc4)", 0,
> > CRYPTO_ALG_ASYNC);
>
> But it will absolutely not _be_ applied. Fix the crypto layer instead if
> it has a problem loading modules.
Agreed. Andreas, please attach your config file. Also, please
show us the error that you get without loading those modules by
hand.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH V2] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
From: Tomas Winkler @ 2009-07-23 0:06 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-wireless, Tomas Winkler
1. add intel's sdio vendor id to sdio_ids.h
2. move iwmc3200 sdio devices' ids to sdio_ids.h
Cc:inaky.perez-gonzalez@intel.com
Cc:cindy.h.kao@intel.com
Cc:yi.zhu@intel.com
Cc:drzeus-list@drzeus.cx
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
V2:
1.Fixed indentation and typos
2.Added also GPS
drivers/net/wimax/i2400m/sdio.c | 12 +++++-------
drivers/net/wireless/iwmc3200wifi/sdio.c | 4 +++-
drivers/net/wireless/iwmc3200wifi/sdio.h | 3 ---
include/linux/mmc/sdio_ids.h | 6 ++++++
4 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wimax/i2400m/sdio.c b/drivers/net/wimax/i2400m/sdio.c
index 2538825..ea7b290 100644
--- a/drivers/net/wimax/i2400m/sdio.c
+++ b/drivers/net/wimax/i2400m/sdio.c
@@ -58,6 +58,7 @@
*/
#include <linux/debugfs.h>
+#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio.h>
#include <linux/mmc/sdio_func.h>
#include "i2400m-sdio.h"
@@ -501,15 +502,12 @@ void i2400ms_remove(struct sdio_func *func)
d_fnend(3, dev, "SDIO func %p\n", func);
}
-enum {
- I2400MS_INTEL_VID = 0x89,
-};
-
static
const struct sdio_device_id i2400ms_sdio_ids[] = {
- /* Intel: i2400m WiMAX over SDIO */
- { SDIO_DEVICE(I2400MS_INTEL_VID, 0x1402) },
- { }, /* end: all zeroes */
+ /* Intel: i2400m WiMAX (iwmc3200) over SDIO */
+ { SDIO_DEVICE(SDIO_VENDOR_ID_INTEL,
+ SDIO_DEVICE_ID_INTEL_IWMC3200WIMAX) },
+ { /* end: all zeroes */ },
};
MODULE_DEVICE_TABLE(sdio, i2400ms_sdio_ids);
diff --git a/drivers/net/wireless/iwmc3200wifi/sdio.c b/drivers/net/wireless/iwmc3200wifi/sdio.c
index b93f620..8b1de84 100644
--- a/drivers/net/wireless/iwmc3200wifi/sdio.c
+++ b/drivers/net/wireless/iwmc3200wifi/sdio.c
@@ -65,6 +65,7 @@
#include <linux/kernel.h>
#include <linux/netdevice.h>
#include <linux/debugfs.h>
+#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio.h>
#include <linux/mmc/sdio_func.h>
@@ -492,7 +493,8 @@ static void iwm_sdio_remove(struct sdio_func *func)
}
static const struct sdio_device_id iwm_sdio_ids[] = {
- { SDIO_DEVICE(SDIO_VENDOR_ID_INTEL, SDIO_DEVICE_ID_IWM) },
+ { SDIO_DEVICE(SDIO_VENDOR_ID_INTEL,
+ SDIO_DEVICE_ID_INTEL_IWMC3200WIFI) },
{ /* end: all zeroes */ },
};
MODULE_DEVICE_TABLE(sdio, iwm_sdio_ids);
diff --git a/drivers/net/wireless/iwmc3200wifi/sdio.h b/drivers/net/wireless/iwmc3200wifi/sdio.h
index b3c156b..aab6b68 100644
--- a/drivers/net/wireless/iwmc3200wifi/sdio.h
+++ b/drivers/net/wireless/iwmc3200wifi/sdio.h
@@ -39,9 +39,6 @@
#ifndef __IWM_SDIO_H__
#define __IWM_SDIO_H__
-#define SDIO_VENDOR_ID_INTEL 0x89
-#define SDIO_DEVICE_ID_IWM 0x1403
-
#define IWM_SDIO_DATA_ADDR 0x0
#define IWM_SDIO_INTR_ENABLE_ADDR 0x14
#define IWM_SDIO_INTR_STATUS_ADDR 0x13
diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index 39751c8..2dbfb5a 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -22,6 +22,12 @@
/*
* Vendors and devices. Sort key: vendor first, device next.
*/
+#define SDIO_VENDOR_ID_INTEL 0x0089
+#define SDIO_DEVICE_ID_INTEL_IWMC3200WIMAX 0x1402
+#define SDIO_DEVICE_ID_INTEL_IWMC3200WIFI 0x1403
+#define SDIO_DEVICE_ID_INTEL_IWMC3200TOP 0x1404
+#define SDIO_DEVICE_ID_INTEL_IWMC3200GPS 0x1405
+#define SDIO_DEVICE_ID_INTEL_IWMC3200BT 0x1406
#define SDIO_VENDOR_ID_MARVELL 0x02df
#define SDIO_DEVICE_ID_MARVELL_LIBERTAS 0x9103
--
1.6.0.6
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: WARNING: at net/mac80211/tx.c:561
From: Luis R. Rodriguez @ 2009-07-22 22:56 UTC (permalink / raw)
To: Fabio Rossi; +Cc: linux-wireless
In-Reply-To: <200907230051.57201.rossi.f@inwind.it>
On Wed, Jul 22, 2009 at 3:51 PM, Fabio Rossi<rossi.f@inwind.it> wrote:
> I'm using the last wireless-testing.git and I have experienced the following
> WARNING:
>
> WARNING: at net/mac80211/tx.c:561 ieee80211_tx_h_rate_ctrl+0x3d1/0x470
> [mac80211]()
Please try a git pull
Luis
> Hardware name: System Name
> wlan0: Dropped data frame as no usable bitrate found while scanning and
> associated. Target station: 00:0c:f6:xx:xx:xx on 5 GHz band
> Modules linked in: ath5k mac80211 ath cfg80211
> Pid: 1270, comm: phy0 Tainted: G W 2.6.31-rc3-wl #140
> Call Trace:
> [<e1aaa0a1>] ? ieee80211_tx_h_rate_ctrl+0x3d1/0x470 [mac80211]
> [<e1aaa0a1>] ? ieee80211_tx_h_rate_ctrl+0x3d1/0x470 [mac80211]
> [<c101d37c>] warn_slowpath_common+0x7c/0xa0
> [<e1aaa0a1>] ? ieee80211_tx_h_rate_ctrl+0x3d1/0x470 [mac80211]
> [<c101d3e6>] warn_slowpath_fmt+0x26/0x30
> [<e1aaa0a1>] ieee80211_tx_h_rate_ctrl+0x3d1/0x470 [mac80211]
> [<e1af8afb>] ? ath5k_hw_reset_tx_queue+0x51b/0x830 [ath5k]
> [<e1aa8aa5>] ? ieee80211_tx_prepare+0x105/0x320 [mac80211]
> [<e1aaa489>] invoke_tx_handlers+0x69/0xf0 [mac80211]
> [<e1aaa64f>] ieee80211_tx+0x5f/0x1f0 [mac80211]
> [<c139f940>] ? skb_release_data+0x50/0x90
> [<c139fa83>] ? pskb_expand_head+0x103/0x190
> [<e1aaa8e5>] ieee80211_xmit+0x105/0x270 [mac80211]
> [<e1aaaa9e>] ieee80211_tx_skb+0x4e/0x60 [mac80211]
> [<e1aad7a2>] ieee80211_send_probe_req+0x112/0x180 [mac80211]
> [<c1017168>] ? dequeue_task+0x48/0x90
> [<c101e11b>] ? printk+0x1b/0x20
> [<e1a9ea9a>] ieee80211_mgd_probe_ap+0x11a/0x150 [mac80211]
> [<e1a9eb12>] ieee80211_beacon_loss_work+0x12/0x20 [mac80211]
> [<c102c75c>] worker_thread+0xec/0x1c0
> [<c1454b7d>] ? schedule+0x18d/0x370
> [<e1a9eb00>] ? ieee80211_beacon_loss_work+0x0/0x20 [mac80211]
> [<c102f740>] ? autoremove_wake_function+0x0/0x40
> [<c102c670>] ? worker_thread+0x0/0x1c0
> [<c102f494>] kthread+0x74/0x80
> [<c102f420>] ? kthread+0x0/0x80
> [<c10032d3>] kernel_thread_helper+0x7/0x14
> ---[ end trace a5a80f7488aa4974 ]---
>
> I have a 802.11abg wireless NIC and I'm currently using a 802.11g access
> point.
>
> Fabio
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* WARNING: at net/mac80211/tx.c:561
From: Fabio Rossi @ 2009-07-22 22:51 UTC (permalink / raw)
To: linux-wireless
I'm using the last wireless-testing.git and I have experienced the following
WARNING:
WARNING: at net/mac80211/tx.c:561 ieee80211_tx_h_rate_ctrl+0x3d1/0x470
[mac80211]()
Hardware name: System Name
wlan0: Dropped data frame as no usable bitrate found while scanning and
associated. Target station: 00:0c:f6:xx:xx:xx on 5 GHz band
Modules linked in: ath5k mac80211 ath cfg80211
Pid: 1270, comm: phy0 Tainted: G W 2.6.31-rc3-wl #140
Call Trace:
[<e1aaa0a1>] ? ieee80211_tx_h_rate_ctrl+0x3d1/0x470 [mac80211]
[<e1aaa0a1>] ? ieee80211_tx_h_rate_ctrl+0x3d1/0x470 [mac80211]
[<c101d37c>] warn_slowpath_common+0x7c/0xa0
[<e1aaa0a1>] ? ieee80211_tx_h_rate_ctrl+0x3d1/0x470 [mac80211]
[<c101d3e6>] warn_slowpath_fmt+0x26/0x30
[<e1aaa0a1>] ieee80211_tx_h_rate_ctrl+0x3d1/0x470 [mac80211]
[<e1af8afb>] ? ath5k_hw_reset_tx_queue+0x51b/0x830 [ath5k]
[<e1aa8aa5>] ? ieee80211_tx_prepare+0x105/0x320 [mac80211]
[<e1aaa489>] invoke_tx_handlers+0x69/0xf0 [mac80211]
[<e1aaa64f>] ieee80211_tx+0x5f/0x1f0 [mac80211]
[<c139f940>] ? skb_release_data+0x50/0x90
[<c139fa83>] ? pskb_expand_head+0x103/0x190
[<e1aaa8e5>] ieee80211_xmit+0x105/0x270 [mac80211]
[<e1aaaa9e>] ieee80211_tx_skb+0x4e/0x60 [mac80211]
[<e1aad7a2>] ieee80211_send_probe_req+0x112/0x180 [mac80211]
[<c1017168>] ? dequeue_task+0x48/0x90
[<c101e11b>] ? printk+0x1b/0x20
[<e1a9ea9a>] ieee80211_mgd_probe_ap+0x11a/0x150 [mac80211]
[<e1a9eb12>] ieee80211_beacon_loss_work+0x12/0x20 [mac80211]
[<c102c75c>] worker_thread+0xec/0x1c0
[<c1454b7d>] ? schedule+0x18d/0x370
[<e1a9eb00>] ? ieee80211_beacon_loss_work+0x0/0x20 [mac80211]
[<c102f740>] ? autoremove_wake_function+0x0/0x40
[<c102c670>] ? worker_thread+0x0/0x1c0
[<c102f494>] kthread+0x74/0x80
[<c102f420>] ? kthread+0x0/0x80
[<c10032d3>] kernel_thread_helper+0x7/0x14
---[ end trace a5a80f7488aa4974 ]---
I have a 802.11abg wireless NIC and I'm currently using a 802.11g access
point.
Fabio
^ permalink raw reply
* [PATCH 1/2] [compat-2.6] Add missing import.
From: Hauke Mehrtens @ 2009-07-22 20:37 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, Hauke Mehrtens
This import was missing in 3615cdf6a700ca02cd14118a7d84ed0065a6e1c1
It is not needed now, but it will be soon.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
compat/compat.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/compat/compat.h b/compat/compat.h
index c5ed4ff..05612b2 100644
--- a/compat/compat.h
+++ b/compat/compat.h
@@ -20,5 +20,6 @@
#include <net/compat-2.6.29.h>
#include <net/compat-2.6.30.h>
#include <net/compat-2.6.31.h>
+#include <net/compat-2.6.32.h>
#endif /* LINUX_26_COMPAT_H */
--
1.6.2.1
^ permalink raw reply related
* [PATCH 2/2] [compat-2.6] Move usb_unpoison_anchored_urbs to compat-2.6.29.h
From: Hauke Mehrtens @ 2009-07-22 20:37 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, Hauke Mehrtens
In-Reply-To: <1248295068-26942-1-git-send-email-hauke@hauke-m.de>
The declaration of usb_unpoison_anchored_urbs was introduced in kernel 2.6.29.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
compat/compat-2.6.28.h | 1 -
compat/compat-2.6.29.h | 3 +++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/compat/compat-2.6.28.h b/compat/compat-2.6.28.h
index 9bc1231..40b5320 100644
--- a/compat/compat-2.6.28.h
+++ b/compat/compat-2.6.28.h
@@ -37,7 +37,6 @@ extern void usb_unpoison_urb(struct urb *urb);
#if 0
extern void usb_poison_anchored_urbs(struct usb_anchor *anchor);
#endif
-extern void usb_unpoison_anchored_urbs(struct usb_anchor *anchor);
extern struct urb *usb_get_from_anchor(struct usb_anchor *anchor);
extern void usb_scuttle_anchored_urbs(struct usb_anchor *anchor);
diff --git a/compat/compat-2.6.29.h b/compat/compat-2.6.29.h
index f4086e9..8ea43cb 100644
--- a/compat/compat-2.6.29.h
+++ b/compat/compat-2.6.29.h
@@ -8,6 +8,7 @@
#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,29))
#include <linux/skbuff.h>
+#include <linux/usb.h>
/**
* skb_queue_is_first - check if skb is the first entry in the queue
@@ -40,6 +41,8 @@ static inline struct sk_buff *skb_queue_prev(const struct sk_buff_head *list,
return skb->prev;
}
+extern void usb_unpoison_anchored_urbs(struct usb_anchor *anchor);
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,29)) */
#endif /* LINUX_26_29_COMPAT_H */
--
1.6.2.1
^ permalink raw reply related
* Re: [PATCH] mac80211: fix autoloading of crypto modules for WEP
From: Johannes Berg @ 2009-07-22 20:20 UTC (permalink / raw)
To: Andreas Oberritter; +Cc: linux-wireless, Herbert Xu
In-Reply-To: <4A677126.3040907@linuxtv.org>
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]
On Wed, 2009-07-22 at 22:05 +0200, Andreas Oberritter wrote:
> If at least one of arc4 and ecb is built as a module, then autoloading
> of the algorithm fails, because crypto_alloc_blkcipher tries to
> request the module "ecb(arc4)", which does not exist.
>
> This patch was made against 2.6.30, but should apply cleanly on top of
> the wireless-2.6 git tree.
> + /*
> + * crypto_alloc_blkcipher() will request the
> + * module "ecb(arc4)", which does not exist.
> + */
> +#ifdef CONFIG_CRYPTO_ARC4_MODULE
> + request_module("arc4");
> +#endif
> +#ifdef CONFIG_CRYPTO_ECB_MODULE
> + request_module("ecb");
> +#endif
> +
> local->wep_tx_tfm = crypto_alloc_blkcipher("ecb(arc4)", 0,
> CRYPTO_ALG_ASYNC);
But it will absolutely not _be_ applied. Fix the crypto layer instead if
it has a problem loading modules.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] mac80211: fix autoloading of crypto modules for WEP
From: Andreas Oberritter @ 2009-07-22 20:05 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless
If at least one of arc4 and ecb is built as a module, then autoloading
of the algorithm fails, because crypto_alloc_blkcipher tries to
request the module "ecb(arc4)", which does not exist.
This patch was made against 2.6.30, but should apply cleanly on top of
the wireless-2.6 git tree.
Signed-off-by: Andreas Oberritter <obi@linuxtv.org>
---
net/mac80211/wep.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/wep.c b/net/mac80211/wep.c
index ef73105..78e9119 100644
--- a/net/mac80211/wep.c
+++ b/net/mac80211/wep.c
@@ -29,6 +29,17 @@ int ieee80211_wep_init(struct ieee80211_local *local)
/* start WEP IV from a random value */
get_random_bytes(&local->wep_iv, WEP_IV_LEN);
+ /*
+ * crypto_alloc_blkcipher() will request the
+ * module "ecb(arc4)", which does not exist.
+ */
+#ifdef CONFIG_CRYPTO_ARC4_MODULE
+ request_module("arc4");
+#endif
+#ifdef CONFIG_CRYPTO_ECB_MODULE
+ request_module("ecb");
+#endif
+
local->wep_tx_tfm = crypto_alloc_blkcipher("ecb(arc4)", 0,
CRYPTO_ALG_ASYNC);
if (IS_ERR(local->wep_tx_tfm))
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] compat-wireless-old: Fix problem with TX on amd64
From: Luis R. Rodriguez @ 2009-07-22 19:30 UTC (permalink / raw)
To: Gao Lei; +Cc: linux-wireless
In-Reply-To: <1248290605.4717.76.camel@mountain.triplerocks.net>
On Wed, Jul 22, 2009 at 12:23 PM, Gao Lei<lei.alvin.gao@gmail.com> wrote:
> On amd64, the `ieee80211_tx_info' struct takes 56 bytes, thus cannot fit
> into skb's control buffer.
>
> The very first result is that nothing can be really sent out, because
> skb's next member `len' also gets cleared when doing:
>
> info = IEEE80211_SKB_CB(skb);
> memset(info, 0, sizeof(*info));
>
> A quick fix may be removing the TX control's sta pointer, since IMHO
> it's rarely used for now (the only place that I found was a function
> assigning values to it).
>
> It has been working well for me so far, but please let me know if
> there're better solutions. Thanks!
>
> Best regards,
> Gao Lei
Thanks, what kernel is this against BTW? Just so you know we should be
able to bring down compat-wireless down to 2.6.21 and maybe even
further now that we no longer are using the master netdev, which used
the multiqueue support added as of 2.6.27. Last I checked
compat-wireless now compiles on 2.6.25, but I never actually tried
loading it as I'm on ext4. So if you are on 2.6.25 or 2.6.26 you may
want to try out compat-wireless directly and see if to works. If you
are on 2.6.21..2.6.24 you can try adding backport support. I've added
a few files already for older kernel support based on our old
compat-wireless-old effort, so only the new stuff that mac80211 makes
use of should require backporting.
Luis
^ permalink raw reply
* [PATCH] compat-wireless-old: Fix problem with TX on amd64
From: Gao Lei @ 2009-07-22 19:23 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
On amd64, the `ieee80211_tx_info' struct takes 56 bytes, thus cannot fit
into skb's control buffer.
The very first result is that nothing can be really sent out, because
skb's next member `len' also gets cleared when doing:
info = IEEE80211_SKB_CB(skb);
memset(info, 0, sizeof(*info));
A quick fix may be removing the TX control's sta pointer, since IMHO
it's rarely used for now (the only place that I found was a function
assigning values to it).
It has been working well for me so far, but please let me know if
there're better solutions. Thanks!
Best regards,
Gao Lei
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index e3adf99..b9a5ae7 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -331,7 +331,6 @@ struct ieee80211_tx_info {
struct {
struct ieee80211_vif *vif;
struct ieee80211_key_conf *hw_key;
- struct ieee80211_sta *sta;
unsigned long jiffies;
int ifindex;
u16 aid;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 7d1b32c..ee0ed32 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -540,9 +540,6 @@ ieee80211_tx_h_misc(struct ieee80211_tx_data *tx)
sband = tx->local->hw.wiphy->bands[tx->channel->band];
- if (tx->sta)
- info->control.sta = &tx->sta->sta;
-
if (!info->control.retry_limit) {
if (!is_multicast_ether_addr(hdr->addr1)) {
int len = min_t(int, tx->skb->len + FCS_LEN,
@@ -620,9 +617,6 @@ ieee80211_tx_h_misc(struct ieee80211_tx_data *tx)
info->control.rts_cts_rate_idx = 0;
}
- if (tx->sta)
- info->control.sta = &tx->sta->sta;
-
return TX_CONTINUE;
}
^ permalink raw reply related
* Re: pull request: wireless-2.6 2009-07-22
From: David Miller @ 2009-07-22 18:19 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20090722174756.GI5276@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 22 Jul 2009 13:47:56 -0400
> Here is a collection of fixes intended for 2.6.31. I think they mostly
> speak for themselves and are uncontroversial.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
^ permalink raw reply
* pull request: wireless-2.6 2009-07-22
From: John W. Linville @ 2009-07-22 17:47 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is a collection of fixes intended for 2.6.31. I think they mostly
speak for themselves and are uncontroversial.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit 1b0d92244ff2434a98272f6d2525da32fc230f19:
Wolfgang Grandegger (1):
can: switch carrier on if device was stopped while in bus-off state
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Alan Jenkins (3):
rfkill: fix rfkill_set_states() to set the hw state
rfkill: remove too-strict __must_check
acer-wmi: fix rfkill conversion
Andy Whitcroft (1):
rt2x00: Fix chipset detection for rt2500usb
Bob Copeland (1):
ath5k: temporarily disable crypto for AP mode
Christian Lamparter (1):
cfg80211: double free in __cfg80211_scan_done
Dan Carpenter (1):
p54spi: fix potential null deref in p54spi.c
Javier Cardona (1):
mac80211: use correct address for mesh Path Error
Johannes Berg (4):
mac80211: disable mesh
rfkill: allow toggling soft state in sysfs again
mac80211_hwsim: fix unregistration
mac80211_hwsim: fix use after free
Larry Finger (1):
rtl8187: Fix for kernel oops when unloading with LEDs enabled
Luis R. Rodriguez (2):
ath9k: Tune ANI function processing on AP mode during ANI reset
ath: add support for special 0x8000 regulatory domain
Marek Vasut (1):
libertas: Fix problem with broken V4 firmware on CF8381
Niko Jokinen (1):
nl80211: Memory leak fixed
Pavel Roskin (1):
mac80211: fix injection in monitor mode
Reinette Chatre (2):
iwlwifi: only show active power level via sysfs
iwlwifi: only update byte count table during aggregation
Zhu Yi (1):
iwmc3200wifi: fix NULL pointer dereference in iwm_if_free
drivers/net/wireless/ath/ath5k/base.c | 3 ++
drivers/net/wireless/ath/ath9k/ani.c | 12 ++++++++++
drivers/net/wireless/ath/regd.c | 17 ++++++++++++++
drivers/net/wireless/iwlwifi/iwl-agn.c | 4 +--
drivers/net/wireless/iwlwifi/iwl-tx.c | 3 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 4 +--
drivers/net/wireless/iwmc3200wifi/netdev.c | 2 +-
drivers/net/wireless/libertas/cmd.c | 8 ++++++-
drivers/net/wireless/libertas/defs.h | 2 +
drivers/net/wireless/mac80211_hwsim.c | 6 ++--
drivers/net/wireless/p54/p54spi.c | 2 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 4 ++-
drivers/net/wireless/rtl818x/rtl8187_leds.c | 3 +-
drivers/platform/x86/acer-wmi.c | 2 +-
include/linux/rfkill.h | 2 +-
net/mac80211/Kconfig | 1 +
net/mac80211/mesh_pathtbl.c | 11 +++++++--
net/mac80211/tx.c | 2 +-
net/rfkill/core.c | 31 ++++++++++++++++++++-------
net/wireless/nl80211.c | 5 ++-
net/wireless/scan.c | 3 +-
21 files changed, 94 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index ea04515..029c1bc 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2970,6 +2970,9 @@ ath5k_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
if (modparam_nohwcrypt)
return -EOPNOTSUPP;
+ if (sc->opmode == NL80211_IFTYPE_AP)
+ return -EOPNOTSUPP;
+
switch (key->alg) {
case ALG_WEP:
case ALG_TKIP:
diff --git a/drivers/net/wireless/ath/ath9k/ani.c b/drivers/net/wireless/ath/ath9k/ani.c
index 1aeafb5..aad259b 100644
--- a/drivers/net/wireless/ath/ath9k/ani.c
+++ b/drivers/net/wireless/ath/ath9k/ani.c
@@ -478,6 +478,18 @@ void ath9k_ani_reset(struct ath_hw *ah)
"Reset ANI state opmode %u\n", ah->opmode);
ah->stats.ast_ani_reset++;
+ if (ah->opmode == NL80211_IFTYPE_AP) {
+ /*
+ * ath9k_hw_ani_control() will only process items set on
+ * ah->ani_function
+ */
+ if (IS_CHAN_2GHZ(chan))
+ ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
+ ATH9K_ANI_FIRSTEP_LEVEL);
+ else
+ ah->ani_function = 0;
+ }
+
ath9k_hw_ani_control(ah, ATH9K_ANI_NOISE_IMMUNITY_LEVEL, 0);
ath9k_hw_ani_control(ah, ATH9K_ANI_SPUR_IMMUNITY_LEVEL, 0);
ath9k_hw_ani_control(ah, ATH9K_ANI_FIRSTEP_LEVEL, 0);
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index eef370b..bf3d25b 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -474,6 +474,21 @@ ath_regd_init_wiphy(struct ath_regulatory *reg,
return 0;
}
+/*
+ * Some users have reported their EEPROM programmed with
+ * 0x8000 set, this is not a supported regulatory domain
+ * but since we have more than one user with it we need
+ * a solution for them. We default to 0x64, which is the
+ * default Atheros world regulatory domain.
+ */
+static void ath_regd_sanitize(struct ath_regulatory *reg)
+{
+ if (reg->current_rd != COUNTRY_ERD_FLAG)
+ return;
+ printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
+ reg->current_rd = 0x64;
+}
+
int
ath_regd_init(struct ath_regulatory *reg,
struct wiphy *wiphy,
@@ -486,6 +501,8 @@ ath_regd_init(struct ath_regulatory *reg,
if (!reg)
return -EINVAL;
+ ath_regd_sanitize(reg);
+
printk(KERN_DEBUG "ath: EEPROM regdomain: 0x%0x\n", reg->current_rd);
if (!ath_regd_is_eeprom_valid(reg)) {
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 6d1519e..355f50e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -2675,12 +2675,10 @@ static ssize_t show_power_level(struct device *d,
struct device_attribute *attr, char *buf)
{
struct iwl_priv *priv = dev_get_drvdata(d);
- int mode = priv->power_data.user_power_setting;
int level = priv->power_data.power_mode;
char *p = buf;
- p += sprintf(p, "INDEX:%d\t", level);
- p += sprintf(p, "USER:%d\n", mode);
+ p += sprintf(p, "%d\n", level);
return p - buf + 1;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index 85ae7a6..9bbeec9 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -872,7 +872,8 @@ int iwl_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
iwl_print_hex_dump(priv, IWL_DL_TX, (u8 *)tx_cmd->hdr, hdr_len);
/* Set up entry for this TFD in Tx byte-count array */
- priv->cfg->ops->lib->txq_update_byte_cnt_tbl(priv, txq,
+ if (info->flags & IEEE80211_TX_CTL_AMPDU)
+ priv->cfg->ops->lib->txq_update_byte_cnt_tbl(priv, txq,
le16_to_cpu(tx_cmd->len));
pci_dma_sync_single_for_device(priv->pci_dev, txcmd_phys,
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index cb9bd4c..956798f 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -3643,12 +3643,10 @@ static ssize_t show_power_level(struct device *d,
struct device_attribute *attr, char *buf)
{
struct iwl_priv *priv = dev_get_drvdata(d);
- int mode = priv->power_data.user_power_setting;
int level = priv->power_data.power_mode;
char *p = buf;
- p += sprintf(p, "INDEX:%d\t", level);
- p += sprintf(p, "USER:%d\n", mode);
+ p += sprintf(p, "%d\n", level);
return p - buf + 1;
}
diff --git a/drivers/net/wireless/iwmc3200wifi/netdev.c b/drivers/net/wireless/iwmc3200wifi/netdev.c
index aaa20c6..aea5ccf 100644
--- a/drivers/net/wireless/iwmc3200wifi/netdev.c
+++ b/drivers/net/wireless/iwmc3200wifi/netdev.c
@@ -151,8 +151,8 @@ void iwm_if_free(struct iwm_priv *iwm)
return;
free_netdev(iwm_to_ndev(iwm));
- iwm_wdev_free(iwm);
iwm_priv_deinit(iwm);
+ iwm_wdev_free(iwm);
}
int iwm_if_add(struct iwm_priv *iwm)
diff --git a/drivers/net/wireless/libertas/cmd.c b/drivers/net/wireless/libertas/cmd.c
index 01db705..6850981 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -135,8 +135,14 @@ int lbs_update_hw_spec(struct lbs_private *priv)
/* Clamp region code to 8-bit since FW spec indicates that it should
* only ever be 8-bit, even though the field size is 16-bit. Some firmware
* returns non-zero high 8 bits here.
+ *
+ * Firmware version 4.0.102 used in CF8381 has region code shifted. We
+ * need to check for this problem and handle it properly.
*/
- priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
+ if (MRVL_FW_MAJOR_REV(priv->fwrelease) == MRVL_FW_V4)
+ priv->regioncode = (le16_to_cpu(cmd.regioncode) >> 8) & 0xFF;
+ else
+ priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
for (i = 0; i < MRVDRV_MAX_REGION_CODE; i++) {
/* use the region code to search for the index */
diff --git a/drivers/net/wireless/libertas/defs.h b/drivers/net/wireless/libertas/defs.h
index 48da157..72f3479 100644
--- a/drivers/net/wireless/libertas/defs.h
+++ b/drivers/net/wireless/libertas/defs.h
@@ -234,6 +234,8 @@ static inline void lbs_deb_hex(unsigned int grp, const char *prompt, u8 *buf, in
/** Mesh enable bit in FW capability */
#define MESH_CAPINFO_ENABLE_MASK (1<<16)
+/** FW definition from Marvell v4 */
+#define MRVL_FW_V4 (0x04)
/** FW definition from Marvell v5 */
#define MRVL_FW_V5 (0x05)
/** FW definition from Marvell v10 */
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index a111bda..7916ca3 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -709,7 +709,7 @@ static const struct ieee80211_ops mac80211_hwsim_ops =
static void mac80211_hwsim_free(void)
{
struct list_head tmplist, *i, *tmp;
- struct mac80211_hwsim_data *data;
+ struct mac80211_hwsim_data *data, *tmpdata;
INIT_LIST_HEAD(&tmplist);
@@ -718,7 +718,7 @@ static void mac80211_hwsim_free(void)
list_move(i, &tmplist);
spin_unlock_bh(&hwsim_radio_lock);
- list_for_each_entry(data, &tmplist, list) {
+ list_for_each_entry_safe(data, tmpdata, &tmplist, list) {
debugfs_remove(data->debugfs_group);
debugfs_remove(data->debugfs_ps);
debugfs_remove(data->debugfs);
@@ -1167,8 +1167,8 @@ static void __exit exit_mac80211_hwsim(void)
{
printk(KERN_DEBUG "mac80211_hwsim: unregister radios\n");
- unregister_netdev(hwsim_mon);
mac80211_hwsim_free();
+ unregister_netdev(hwsim_mon);
}
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 83116ba..72c7dbd 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -635,7 +635,7 @@ static int __devinit p54spi_probe(struct spi_device *spi)
hw = p54_init_common(sizeof(*priv));
if (!hw) {
- dev_err(&priv->spi->dev, "could not alloc ieee80211_hw");
+ dev_err(&spi->dev, "could not alloc ieee80211_hw");
return -ENOMEM;
}
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 66daf68..ce75426 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1550,7 +1550,9 @@ static int rt2500usb_init_eeprom(struct rt2x00_dev *rt2x00dev)
rt2500usb_register_read(rt2x00dev, MAC_CSR0, ®);
rt2x00_set_chip(rt2x00dev, RT2570, value, reg);
- if (!rt2x00_check_rev(&rt2x00dev->chip, 0x000ffff0, 0)) {
+ if (!rt2x00_check_rev(&rt2x00dev->chip, 0x000ffff0, 0) ||
+ rt2x00_check_rev(&rt2x00dev->chip, 0x0000000f, 0)) {
+
ERROR(rt2x00dev, "Invalid RT chipset detected.\n");
return -ENODEV;
}
diff --git a/drivers/net/wireless/rtl818x/rtl8187_leds.c b/drivers/net/wireless/rtl818x/rtl8187_leds.c
index b442535..cf9f899 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_leds.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_leds.c
@@ -208,11 +208,12 @@ void rtl8187_leds_exit(struct ieee80211_hw *dev)
{
struct rtl8187_priv *priv = dev->priv;
- rtl8187_unregister_led(&priv->led_tx);
/* turn the LED off before exiting */
queue_delayed_work(dev->workqueue, &priv->led_off, 0);
cancel_delayed_work_sync(&priv->led_off);
+ cancel_delayed_work_sync(&priv->led_on);
rtl8187_unregister_led(&priv->led_rx);
+ rtl8187_unregister_led(&priv->led_tx);
}
#endif /* def CONFIG_RTL8187_LED */
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index be2fd6f..fb45f5e 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -973,7 +973,7 @@ static int acer_rfkill_set(void *data, bool blocked)
{
acpi_status status;
u32 cap = (unsigned long)data;
- status = set_u32(!!blocked, cap);
+ status = set_u32(!blocked, cap);
if (ACPI_FAILURE(status))
return -ENODEV;
return 0;
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index 2ce2983..278777f 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -224,7 +224,7 @@ void rfkill_destroy(struct rfkill *rfkill);
* should be blocked) so that drivers need not keep track of the soft
* block state -- which they might not be able to.
*/
-bool __must_check rfkill_set_hw_state(struct rfkill *rfkill, bool blocked);
+bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked);
/**
* rfkill_set_sw_state - Set the internal rfkill software block state
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index ba2643a..7836ee9 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -83,6 +83,7 @@ endmenu
config MAC80211_MESH
bool "Enable mac80211 mesh networking (pre-802.11s) support"
depends on MAC80211 && EXPERIMENTAL
+ depends on BROKEN
---help---
This options enables support of Draft 802.11s mesh networking.
The implementation is based on Draft 1.08 of the Mesh Networking
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index 3c72557..479597e 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -175,6 +175,8 @@ int mesh_path_add(u8 *dst, struct ieee80211_sub_if_data *sdata)
int err = 0;
u32 hash_idx;
+ might_sleep();
+
if (memcmp(dst, sdata->dev->dev_addr, ETH_ALEN) == 0)
/* never add ourselves as neighbours */
return -ENOTSUPP;
@@ -265,6 +267,7 @@ int mpp_path_add(u8 *dst, u8 *mpp, struct ieee80211_sub_if_data *sdata)
int err = 0;
u32 hash_idx;
+ might_sleep();
if (memcmp(dst, sdata->dev->dev_addr, ETH_ALEN) == 0)
/* never add ourselves as neighbours */
@@ -491,8 +494,10 @@ void mesh_path_tx_pending(struct mesh_path *mpath)
* @skb: frame to discard
* @sdata: network subif the frame was to be sent through
*
- * If the frame was beign forwarded from another MP, a PERR frame will be sent
- * to the precursor.
+ * If the frame was being forwarded from another MP, a PERR frame will be sent
+ * to the precursor. The precursor's address (i.e. the previous hop) was saved
+ * in addr1 of the frame-to-be-forwarded, and would only be overwritten once
+ * the destination is successfully resolved.
*
* Locking: the function must me called within a rcu_read_lock region
*/
@@ -507,7 +512,7 @@ void mesh_path_discard_frame(struct sk_buff *skb,
u8 *ra, *da;
da = hdr->addr3;
- ra = hdr->addr2;
+ ra = hdr->addr1;
mpath = mesh_path_lookup(da, sdata);
if (mpath)
dsn = ++mpath->dsn;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index d238a89..3a8922c 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1455,7 +1455,7 @@ int ieee80211_master_start_xmit(struct sk_buff *skb, struct net_device *dev)
monitor_iface = UNKNOWN_ADDRESS;
len_rthdr = ieee80211_get_radiotap_len(skb->data);
- hdr = (struct ieee80211_hdr *)skb->data + len_rthdr;
+ hdr = (struct ieee80211_hdr *)(skb->data + len_rthdr);
hdrlen = ieee80211_hdrlen(hdr->frame_control);
/* check the header is complete in the frame */
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 79693fe..2fc4a17 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -549,6 +549,10 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, bool hw)
swprev = !!(rfkill->state & RFKILL_BLOCK_SW);
hwprev = !!(rfkill->state & RFKILL_BLOCK_HW);
__rfkill_set_sw_state(rfkill, sw);
+ if (hw)
+ rfkill->state |= RFKILL_BLOCK_HW;
+ else
+ rfkill->state &= ~RFKILL_BLOCK_HW;
spin_unlock_irqrestore(&rfkill->lock, flags);
@@ -648,15 +652,26 @@ static ssize_t rfkill_state_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
- /*
- * The intention was that userspace can only take control over
- * a given device when/if rfkill-input doesn't control it due
- * to user_claim. Since user_claim is currently unsupported,
- * we never support changing the state from userspace -- this
- * can be implemented again later.
- */
+ struct rfkill *rfkill = to_rfkill(dev);
+ unsigned long state;
+ int err;
+
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
+ err = strict_strtoul(buf, 0, &state);
+ if (err)
+ return err;
+
+ if (state != RFKILL_USER_STATE_SOFT_BLOCKED &&
+ state != RFKILL_USER_STATE_UNBLOCKED)
+ return -EINVAL;
+
+ mutex_lock(&rfkill_global_mutex);
+ rfkill_set_block(rfkill, state == RFKILL_USER_STATE_SOFT_BLOCKED);
+ mutex_unlock(&rfkill_global_mutex);
- return -EPERM;
+ return err ?: count;
}
static ssize_t rfkill_claim_show(struct device *dev,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 43bdb13..634496b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -997,7 +997,7 @@ static int nl80211_get_key(struct sk_buff *skb, struct genl_info *info)
if (IS_ERR(hdr)) {
err = PTR_ERR(hdr);
- goto out;
+ goto free_msg;
}
cookie.msg = msg;
@@ -1011,7 +1011,7 @@ static int nl80211_get_key(struct sk_buff *skb, struct genl_info *info)
&cookie, get_key_callback);
if (err)
- goto out;
+ goto free_msg;
if (cookie.error)
goto nla_put_failure;
@@ -1022,6 +1022,7 @@ static int nl80211_get_key(struct sk_buff *skb, struct genl_info *info)
nla_put_failure:
err = -ENOBUFS;
+ free_msg:
nlmsg_free(msg);
out:
cfg80211_put_dev(drv);
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index f8e71b3..9271118 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -35,8 +35,6 @@ void cfg80211_scan_done(struct cfg80211_scan_request *request, bool aborted)
else
nl80211_send_scan_done(wiphy_to_dev(request->wiphy), dev);
- wiphy_to_dev(request->wiphy)->scan_req = NULL;
-
#ifdef CONFIG_WIRELESS_EXT
if (!aborted) {
memset(&wrqu, 0, sizeof(wrqu));
@@ -48,6 +46,7 @@ void cfg80211_scan_done(struct cfg80211_scan_request *request, bool aborted)
dev_put(dev);
out:
+ wiphy_to_dev(request->wiphy)->scan_req = NULL;
kfree(request);
}
EXPORT_SYMBOL(cfg80211_scan_done);
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply related
* [PATCH v2] wireless-regb: make db2bin.py use new hashlib for sha1
From: Luis R. Rodriguez @ 2009-07-22 17:57 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ath9k-devel, johannes, Luis R. Rodriguez
Python now complains about sha module as its deprecated:
./db2bin.py regulatory.bin db.txt ~/.wireless-regdb-mcgrof.key.priv.pem
./db2bin.py:5: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
import sha
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
Don't pass along my regulatory.bin changes..
db2bin.py | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/db2bin.py b/db2bin.py
index e783b3a..23d3ee2 100755
--- a/db2bin.py
+++ b/db2bin.py
@@ -2,7 +2,7 @@
from cStringIO import StringIO
import struct
-import sha
+import hashlib
from dbparse import DBParser
import sys
@@ -127,13 +127,13 @@ if len(sys.argv) > 3:
# determine signature length
key = RSA.load_key(sys.argv[3])
- hash = sha.new()
+ hash = hashlib.sha1()
hash.update(output.getvalue())
sig = key.sign(hash.digest())
# write it to file
siglen.set(len(sig))
# sign again
- hash = sha.new()
+ hash = hashlib.sha1()
hash.update(output.getvalue())
sig = key.sign(hash.digest())
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] wireless-regb: make db2bin.py use new hashlib for sha1
From: Luis R. Rodriguez @ 2009-07-22 17:54 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ath9k-devel, johannes, Luis R. Rodriguez
In-Reply-To: <1248285140-10140-1-git-send-email-lrodriguez@atheros.com>
On Wed, Jul 22, 2009 at 10:52 AM, Luis R.
Rodriguez<lrodriguez@atheros.com> wrote:
> Python now complains about sha module as its deprecated:
>
> ./db2bin.py regulatory.bin db.txt ~/.wireless-regdb-mcgrof.key.priv.pem
> ./db2bin.py:5: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
> import sha
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> db2bin.py | 6 +++---
> regulatory.bin | Bin 3084 -> 3084 bytes
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/db2bin.py b/db2bin.py
> index e783b3a..23d3ee2 100755
> --- a/db2bin.py
> +++ b/db2bin.py
> @@ -2,7 +2,7 @@
>
> from cStringIO import StringIO
> import struct
> -import sha
> +import hashlib
> from dbparse import DBParser
> import sys
>
> @@ -127,13 +127,13 @@ if len(sys.argv) > 3:
>
> # determine signature length
> key = RSA.load_key(sys.argv[3])
> - hash = sha.new()
> + hash = hashlib.sha1()
> hash.update(output.getvalue())
> sig = key.sign(hash.digest())
> # write it to file
> siglen.set(len(sig))
> # sign again
> - hash = sha.new()
> + hash = hashlib.sha1()
> hash.update(output.getvalue())
> sig = key.sign(hash.digest())
>
> diff --git a/regulatory.bin b/regulatory.bin
Bleh, forgot to clean this, will resend.
Luis
^ permalink raw reply
* [PATCH] wireless-regb: make db2bin.py use new hashlib for sha1
From: Luis R. Rodriguez @ 2009-07-22 17:52 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ath9k-devel, johannes, Luis R. Rodriguez
Python now complains about sha module as its deprecated:
./db2bin.py regulatory.bin db.txt ~/.wireless-regdb-mcgrof.key.priv.pem
./db2bin.py:5: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
import sha
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
db2bin.py | 6 +++---
regulatory.bin | Bin 3084 -> 3084 bytes
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/db2bin.py b/db2bin.py
index e783b3a..23d3ee2 100755
--- a/db2bin.py
+++ b/db2bin.py
@@ -2,7 +2,7 @@
from cStringIO import StringIO
import struct
-import sha
+import hashlib
from dbparse import DBParser
import sys
@@ -127,13 +127,13 @@ if len(sys.argv) > 3:
# determine signature length
key = RSA.load_key(sys.argv[3])
- hash = sha.new()
+ hash = hashlib.sha1()
hash.update(output.getvalue())
sig = key.sign(hash.digest())
# write it to file
siglen.set(len(sig))
# sign again
- hash = sha.new()
+ hash = hashlib.sha1()
hash.update(output.getvalue())
sig = key.sign(hash.digest())
diff --git a/regulatory.bin b/regulatory.bin
index 43797b58453482f01b66050e8bf3905242fd057b..6128687a742cf85f1a39def772cc30dd330e5723 100644
GIT binary patch
delta 273
zcmV+s0q*{c7>pROq6z{A43ne^Xn(*WB)7iO3CS>`!(@G$Lz!m<D*d~E$cm-?G$4JG
zlQ7$|U4nwxskc@T;^&b-26aSNf9O~_4OpX63fw{)N*Pf=4}sj1;y)XEqaw$#lVp-B
z357?vVFd%Xl>!@!$WF;lX_>T&D8sQ0(lprReH4=Bcb=7jTB054r(|Lnz<;Kk{$>V4
zG#)UDNAA*fgKVbPE6G_vSXhDoHgn})ywQ`Bz-SFgPv#S=C<B-FXMKA2BlNpuTt`L?
z)x83hKG?htDH!)09BuV~&j(ShcDLgTt3Puin+0D<O~P8UKb_yGT5$7vjst#k_C<r6
Xe8-M~z&q>}jG#)+zmIlU_X5WP*Mxuh
delta 273
zcmV+s0q*{c7>pROq6z{Bl#`?iXn#;swzPB}=h4)L-^~xBz2}pe;8EET#jZtE*8H3k
zXj)vVHXPR-uQZMzlf@W6S={@A#vJjZtpg@jD}+zKI6DS+GdJNQ?i;!n=ZKWtY>miL
z@U~l;%l7Pt2R+>_RBl-2_6KBM62F&m3;+SIjWY)EP9A8g(&I=;gZe0mH-DO&d)b4J
zRlqyy#|hjK421&i7oK+fJ~2iH?Rt2_iu^|H(dha^Ei{m=y%aEnk$tw#YtaG3bIdi7
z$^x{m;*=7+Qf<K%y4{MNS&!be0H>Y7R0%9MixLB1wp?ADW&&N6+f}b~OtpVpFRLtX
Xv^M30B4gmTdF0UEV~?_e@&czA=`Dq-
--
1.6.3.3
^ permalink raw reply related
* [PATCH] wireless-regdb: TH gets 5 GHz enabled as of new regulatory rules
From: Luis R. Rodriguez @ 2009-07-22 17:51 UTC (permalink / raw)
To: linville
Cc: linux-wireless, ath9k-devel, sfalpha, Luis R. Rodriguez,
Michael Green, David Quan
Phattanon Duangdara reported the National Telecommunication
Commisions of Thailand has announced new regulatory rules
about 5GHz for RLAN last year.
I have verified this matches our documentation internally
at Atheros.
Reference in Thai Language:
http://www.ratchakitcha.soc.go.th/DATA/PDF/2551/E/042/64.PDF
Cc: Michael Green <michael.green@atheros.com>
Cc: David Quan <david.quan@atheros.com>
Reported-by: Phattanon Duangdara <sfalpha@gmail.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
db.txt | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/db.txt b/db.txt
index fad098d..01536d6 100644
--- a/db.txt
+++ b/db.txt
@@ -534,7 +534,11 @@ country TW:
(5735 - 5815 @ 40), (3, 30)
country TH:
- (2402 - 2482 @ 40), (N/A, 20)
+ (2402 - 2482 @ 20), (N/A, 20)
+ (5170 - 5250 @ 20), (3, 17)
+ (5250 - 5330 @ 20), (3, 20), DFS
+ (5490 - 5710 @ 20), (3, 20), DFS
+ (5735 - 5835 @ 20), (3, 30)
country TT:
(2402 - 2482 @ 40), (N/A, 20)
--
1.6.3.3
^ permalink raw reply related
* [PATCH] ath: map TH to FCC3_WORLD
From: Luis R. Rodriguez @ 2009-07-22 17:41 UTC (permalink / raw)
To: linville
Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez, David Quan,
Michael Green
TH gets 5 GHz.
Cc: David Quan <david.quan@atheros.com>
Cc: Michael Green <michael.green@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/regd_common.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/regd_common.h b/drivers/net/wireless/ath/regd_common.h
index 4d0e298..ad6d938 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -450,7 +450,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_SWITZERLAND, ETSI1_WORLD, "CH"},
{CTRY_SYRIA, NULL1_WORLD, "SY"},
{CTRY_TAIWAN, APL3_FCCA, "TW"},
- {CTRY_THAILAND, NULL1_WORLD, "TH"},
+ {CTRY_THAILAND, FCC3_WORLD, "TH"},
{CTRY_TRINIDAD_Y_TOBAGO, ETSI4_WORLD, "TT"},
{CTRY_TUNISIA, ETSI3_WORLD, "TN"},
{CTRY_TURKEY, ETSI3_WORLD, "TR"},
--
1.6.3.3
^ permalink raw reply related
* Re: Update for regulatory database on 5GHz band for Thailand (TH)
From: Luis R. Rodriguez @ 2009-07-22 16:41 UTC (permalink / raw)
To: David Quan
Cc: Phattanon Duangdara, linux-wireless@vger.kernel.org,
Michael Green
In-Reply-To: <15B47C78534E094AA9A41F58FB8D74F30147BE67876F@SC1EXMB-MBCL.global.atheros.com>
On Wed, Jul 22, 2009 at 9:27 AM, David Quan<David.Quan@atheros.com> wrote:
> I am not sure what the question is here.
> Our windows driver already have 5G turn on for Thailand.
> Are you stating that it is not on the Linux Ath9K?
David, just a heads up, a public list is being CC'd here.
In the db.txt (from wireless-regdb) we currently have TH mapped as:
country TH:
(2402 - 2482 @ 40), (N/A, 20)
This came from the regpair TH was mapped to, which does differ from
FCC3_WORLD. TH was mapped to NULL1_WORLD which explains the lack of 5
GHz on TH on db.txt.
> In Windows code, it is Thailand is mapped to FCC3_WORLD.
OK this needs to be updated and the regulatory database as well. Only
these countries map to FCC3_WORLD currently in ath.ko (the shared
module between ath5k, ath9k and ar9170):
{CTRY_BRAZIL, FCC3_WORLD, "BR"},
{CTRY_SOUTH_AFRICA, FCC3_WORLD, "ZA"},
{CTRY_SRI_LANKA, FCC3_WORLD, "LK"},
To get TH to map to FCC3_WORLD we need a one line change to ath.ko
code and to the public db.txt to change to use the same regulatory
information as "BR", "ZA", and "LK":
country TH:
(2402 - 2482 @ 20), (N/A, 20)
(5170 - 5250 @ 20), (3, 17)
(5250 - 5330 @ 20), (3, 20), DFS
(5490 - 5710 @ 20), (3, 20), DFS
(5735 - 5835 @ 20), (3, 30)
I'll send the respective patch if you ACK TH should map to the above.
Luis
---
Below are BR, ZA and LK:
country BR:
(2402 - 2482 @ 20), (N/A, 20)
(5170 - 5250 @ 20), (3, 17)
(5250 - 5330 @ 20), (3, 20), DFS
(5490 - 5710 @ 20), (3, 20), DFS
(5735 - 5835 @ 20), (3, 30)
country ZA:
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ 20), (3, 17)
(5250 - 5330 @ 20), (3, 20), DFS
(5490 - 5710 @ 20), (3, 20), DFS
(5735 - 5835 @ 20), (3, 30)
country LK:
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ 20), (3, 17)
(5250 - 5330 @ 20), (3, 20), DFS
(5490 - 5710 @ 20), (3, 20), DFS
(5735 - 5835 @ 20), (3, 30)
^ permalink raw reply
* Re: wireless-testing regression: iwl3945 scan fails
From: reinette chatre @ 2009-07-22 16:38 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Kalle Valo, linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <1248279871.28545.126.camel@violet>
Hi Marcel,
On Wed, 2009-07-22 at 09:24 -0700, Marcel Holtmann wrote:
> Hi Reinette,
>
> > > > I just upgraded to rc3-wl (commit 225b6807) and my iwl3945 doesn't work
> > > > anymore, even scan fails. I don't have time to investigate this right
> > > > now, but I'll try to find some time during the evening.
> > >
> > > I have looked at this now a bit and I don't think this is an iwl3945
> > > problem. Scanning seems to stall in some situations and iwl3945 doesn't
> > > even receive the scan command.
> >
> > The patches we sent recently did undergo testing under various scenarios
> > using wpa_supplicant. We have not done this testing after the
> > 2.6.31-rc3-wl merge (yesterday) though. I just did a quick test on my
> > 3945 using iwconfig to associate and it was able to do so on A and G
> > bands. Looks like I need to do some wpa_supplicant testing.
>
> can also at least get an IP address via DHCP and do some packet
> transfer. I made the experience that DHCP works and then we get
> disconnected seconds later.
I have seen this for a long time now. I am using wpa_supplicant to
connect to a WPA2 network using a 5100 device and get disconnected very
regularly (starts with "CTRL-EVENT-DISCONNECTED - Disconnect event -
remove keys" which is caused by a missing probe response from the AP).
In these cases wpa_supplicant is able to reconnect. This behavior is
also present in 2.6.31-rc3-wl from yesterday.
Do you not get reconnected after you get disconnected?
Reinette
^ permalink raw reply
* RE: Update for regulatory database on 5GHz band for Thailand (TH)
From: David Quan @ 2009-07-22 16:27 UTC (permalink / raw)
To: Luis R. Rodriguez, Phattanon Duangdara
Cc: linux-wireless@vger.kernel.org, Michael Green
In-Reply-To: <43e72e890907220916n6a5c76d3ydbfc0233f86e3546@mail.gmail.com>
I am not sure what the question is here.
Our windows driver already have 5G turn on for Thailand.
Are you stating that it is not on the Linux Ath9K?
In Windows code, it is Thailand is mapped to FCC3_WORLD.
David
-----Original Message-----
From: Luis R. Rodriguez [mailto:mcgrof@gmail.com]
Sent: Wednesday, July 22, 2009 9:17 AM
To: Phattanon Duangdara
Cc: linux-wireless@vger.kernel.org; Michael Green; David Quan
Subject: Re: Update for regulatory database on 5GHz band for Thailand (TH)
Adding Michael and David,
any thoughts on this Thailand regulatory change?
Luis
On Wed, Jul 22, 2009 at 7:04 AM, Phattanon Duangdara<sfalpha@gmail.com> wrote:
> On Wed, Jul 22, 2009 at 8:19 PM, John W. Linville<linville@tuxdriver.com> wrote:
>> On Wed, Jul 22, 2009 at 08:07:21PM +0700, Phattanon Duangdara wrote:
>>> National Telecommunication Commisions of Thailand has announce new
>>> regulatory about 5GHz for RLAN last year.
>>>
>>> But I found that Linux Wireless Regulatory Database not get updated.
>>>
>>> Reference in Thai Language:
>>> http://www.ratchakitcha.soc.go.th/DATA/PDF/2551/E/042/64.PDF
>>> (Partly in english and reference to ITU/FCC documents, I think it
>>> quite easy to understand)
>>>
>>> How can this get update on Regulatory Database ?
>>
>> What a beautiful font! :-)
>>
>> While there is enough English/numbers there that I can probably judge
>> what it means, I'd feel a lot better if someone else (perhaps you)
>> submitted a patch against the tree here:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git
>>
>> Thanks!
>>
>> John
>> --
>> John W. Linville Someday the world will need a hero, and you
>> linville@tuxdriver.com might be all we have. Be ready.
>> -iva Honduras Libre!
>>
>
> Actually, NTC provide english translated documents, but for thism, it
> missing from their website. I already contact NTC to get those
> document in english for reference and clarification. Later models of
> some Laptops sell in Thailand already has 5GHz enabled radio.
>
> For now I will try to update db against tree from my knowledge.
>
> Phattanon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: wireless-testing regression: iwl3945 scan fails
From: Marcel Holtmann @ 2009-07-22 16:24 UTC (permalink / raw)
To: reinette chatre; +Cc: Kalle Valo, linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <1248278121.17896.2728.camel@rc-desk>
Hi Reinette,
> > > I just upgraded to rc3-wl (commit 225b6807) and my iwl3945 doesn't work
> > > anymore, even scan fails. I don't have time to investigate this right
> > > now, but I'll try to find some time during the evening.
> >
> > I have looked at this now a bit and I don't think this is an iwl3945
> > problem. Scanning seems to stall in some situations and iwl3945 doesn't
> > even receive the scan command.
>
> The patches we sent recently did undergo testing under various scenarios
> using wpa_supplicant. We have not done this testing after the
> 2.6.31-rc3-wl merge (yesterday) though. I just did a quick test on my
> 3945 using iwconfig to associate and it was able to do so on A and G
> bands. Looks like I need to do some wpa_supplicant testing.
can also at least get an IP address via DHCP and do some packet
transfer. I made the experience that DHCP works and then we get
disconnected seconds later.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2] p54spi: fix potential null deref in p54spi.c
From: Dan Carpenter @ 2009-07-22 14:40 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Max Filippov, John W. Linville
In-Reply-To: <200907192126.13207.chunkeey@web.de>
Great.
Acked-by: Dan Carpenter <error27@gmail.com>
regards,
dan carpenter
On 7/19/09, Christian Lamparter <chunkeey@web.de> wrote:
> From: Dan Carpenter <error27@gmail.com>
>
> Fix a potential NULL dereference bug during
> error handling in p54spi_probe.
>
> This bug was discovered by smatch:
> (http://repo.or.cz/w/smatch.git).
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> Signed-off-by: Christian Lamparter <chunkeey@web.de>
> ---
> On Sunday 19 July 2009 13:53:57 Dan Carpenter wrote:
>
>> We can't use dev_err() becuase "priv" is NULL.
> yep, but that's my fault and not Micheal's.
>
>> Found by smatch (http://repo.or.cz/w/smatch.git).
>> regards,
>> dan carpenter
> what about this alternative?
> it retains the dev_err by simply moving to the spi_device *spi
> which comes from spi-subsystem and is initialized?
>
> Regards,
> Chr
> ---
> diff --git a/drivers/net/wireless/p54/p54spi.c
> b/drivers/net/wireless/p54/p54spi.c
> index d5f181a..eef5329 100644
> --- a/drivers/net/wireless/p54/p54spi.c
> +++ b/drivers/net/wireless/p54/p54spi.c
> @@ -600,7 +600,7 @@ static int __devinit p54spi_probe(struct spi_device
> *spi)
>
> hw = p54_init_common(sizeof(*priv));
> if (!hw) {
> - dev_err(&priv->spi->dev, "could not alloc ieee80211_hw");
> + dev_err(&spi->dev, "could not alloc ieee80211_hw");
> return -ENOMEM;
> }
>
>
>
>
^ permalink raw reply
* Re: Update for regulatory database on 5GHz band for Thailand (TH)
From: Luis R. Rodriguez @ 2009-07-22 16:16 UTC (permalink / raw)
To: Phattanon Duangdara; +Cc: linux-wireless, Michael Green, David Quan
In-Reply-To: <f7de31c0907220704x5000854bq652b09bf5b6bfc3c@mail.gmail.com>
Adding Michael and David,
any thoughts on this Thailand regulatory change?
Luis
On Wed, Jul 22, 2009 at 7:04 AM, Phattanon Duangdara<sfalpha@gmail.com> wrote:
> On Wed, Jul 22, 2009 at 8:19 PM, John W. Linville<linville@tuxdriver.com> wrote:
>> On Wed, Jul 22, 2009 at 08:07:21PM +0700, Phattanon Duangdara wrote:
>>> National Telecommunication Commisions of Thailand has announce new
>>> regulatory about 5GHz for RLAN last year.
>>>
>>> But I found that Linux Wireless Regulatory Database not get updated.
>>>
>>> Reference in Thai Language:
>>> http://www.ratchakitcha.soc.go.th/DATA/PDF/2551/E/042/64.PDF
>>> (Partly in english and reference to ITU/FCC documents, I think it
>>> quite easy to understand)
>>>
>>> How can this get update on Regulatory Database ?
>>
>> What a beautiful font! :-)
>>
>> While there is enough English/numbers there that I can probably judge
>> what it means, I'd feel a lot better if someone else (perhaps you)
>> submitted a patch against the tree here:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git
>>
>> Thanks!
>>
>> John
>> --
>> John W. Linville Someday the world will need a hero, and you
>> linville@tuxdriver.com might be all we have. Be ready.
>> –iva Honduras Libre!
>>
>
> Actually, NTC provide english translated documents, but for thism, it
> missing from their website. I already contact NTC to get those
> document in english for reference and clarification. Later models of
> some Laptops sell in Thailand already has 5GHz enabled radio.
>
> For now I will try to update db against tree from my knowledge.
>
> Phattanon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: wireless-testing regression: iwl3945 scan fails
From: reinette chatre @ 2009-07-22 15:55 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <87fxcosron.fsf@litku.valot.fi>
Hi Kalle,
On Wed, 2009-07-22 at 07:44 -0700, Kalle Valo wrote:
> Kalle Valo <kalle.valo@iki.fi> writes:
>
> > Good morning,
> >
> > I just upgraded to rc3-wl (commit 225b6807) and my iwl3945 doesn't work
> > anymore, even scan fails. I don't have time to investigate this right
> > now, but I'll try to find some time during the evening.
>
> I have looked at this now a bit and I don't think this is an iwl3945
> problem. Scanning seems to stall in some situations and iwl3945 doesn't
> even receive the scan command.
The patches we sent recently did undergo testing under various scenarios
using wpa_supplicant. We have not done this testing after the
2.6.31-rc3-wl merge (yesterday) though. I just did a quick test on my
3945 using iwconfig to associate and it was able to do so on A and G
bands. Looks like I need to do some wpa_supplicant testing.
>
> Here's an example what's happening with wpa_supplicant from debian
> unstable:
>
> $ sudo ifup wlan0
>
> [ 104.468073] iwl3945 0000:03:00.0: firmware: requesting iwlwifi-3945-2.ucode
> [ 104.533234] iwl3945 0000:03:00.0: loaded firmware version 15.32.2.9
> [ 104.612049] phy0: device now idle
> [ 104.613091] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 106.968392] phy0: device no longer idle - scanning
> [ 109.561397] phy0: device now idle
> [ 109.563737] wlan0: deauthenticating by local choice (reason=3)
> [ 109.563743] phy0: device no longer idle - in use
>
> [waited a while]
>
> $ sudo iwlist wlan0 scan
> wlan0 Interface doesn't support scanning : Device or resource busy
>
> $ sudo iwlist wlan0 scan
> wlan0 Interface doesn't support scanning : Device or resource busy
>
> $ sudo wpa_action wlan0 stop
>
> [ 191.649653] wlan0: deauthenticating by local choice (reason=3)
> [ 191.697619] phy0: device now idle
>
> Also I have been able to reproduce the problem once with iw. For some
> strange reason I have had to reboot my laptop to reproduce this,
> unloading all wireless related modules (expect rfkill which I can't
> unload due to dependencies) is not enough.
Are you saying that this problem occurs always with wpa_supplicant and
sometimes with iw?
Reinette
^ permalink raw reply
* Re: any controller working in AP mode ?
From: Pavel Roskin @ 2009-07-22 15:48 UTC (permalink / raw)
To: Ram kumar; +Cc: Javier Cardona, andrey, linux-wireless
In-Reply-To: <1247843954.25608.62.camel@mj>
On Fri, 2009-07-17 at 11:19 -0400, Pavel Roskin wrote:
> > It would be very helpful if anyone can guide me,how to get the
> > hardware for MARVELL 8388.
>
> 5 minute search finds that Zonet ZEW2502 is what you need. There is
> only one driver for that device on the Zonet site, and it's clearly for
> Marvell.
Just for the record, it turns out the device is not supported, even
though it's Marvell:
Bus 001 Device 005: ID 1286:1fab Marvell Semiconductor, Inc.
Both libertas drivers support only 1286:2001 and 05a3:8388.
Web search for 1286:1fab doesn't find anything useful other than
recommendations to use ndiswrapper.
I should have checked the ID in the *.inf files against the kernel
sources.
--
Regards,
Pavel Roskin
^ 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