* Re: iwlwifi connection problems
From: Alex Romosan @ 2010-08-02 0:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <1280212629.19098.0.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Mon, 2010-07-26 at 21:59 -0700, Alex Romosan wrote:
>
>> any ideas on how i can debug this? i tried to do a git-bisect but i
>> didn't get anywhere. i have the driver compiled in the kernel if that
>> makes any difference. as i played with the later kernels (after 2.6.34)
>> i discovered that if kept bringing the interface down and then up again
>> eventually i would get "cfg80211: Calling CRDA to update world
>> regulatory domain" the antenna light on the laptop (i have a thinkpad
>> t61) would go off and then at the next ifup the driver connected. looks
>> like some kind of reset/initialization problem to me.
>
> So is the issue maybe the channel the AP is no, not the fact that it's
> hidden? or something like that?
it's still not working even with kernel 2.6.35 so i decided to play with
it a little bit more. indeed, it has nothing to do with the access
point being hidden or not. it doesn't work even when it's visible
(previously i was able to connect to the wireless at work which is
visible so i wrongly assumed that was the cause).
so it looks like the problem is connecting to this particular access
point which is a proxim ap-200 orinoco wireless ap i got in 2003. right
now the ap is setup on channel 3 and the rate is set to 11 Mbps. should
i try a different channel? which one?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
^ permalink raw reply
* Re: Intel Wireless: Microcode SW error detected.
From: Malthe Borch @ 2010-08-01 23:56 UTC (permalink / raw)
To: Guy, Wey-Yi W; +Cc: linux-wireless@vger.kernel.org, Sternberg, Jay E
In-Reply-To: <E9954878DD1FB34FAE5187FB88C58A350122DF3C44@orsmsx506.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
Attached is the additional logging output I get when I load the drivers using:
modprobe iwlagn debug=0x43fff
\malthe
On 27 July 2010 10:40, Guy, Wey-Yi W <wey-yi.w.guy@intel.com> wrote:
> Add Jay to the thread,
>
> Jay, could you help to take a look at it. Thanks
>
> Wey-Yi Guy
> Intel Corporation
> 2111 N.E. 25th Avenue M/S JF3-308
> Hillsboro OR 97124-5961
> USA
> Work Phone: 503-264-6023 (OR)
> Cell Phone: 503-329-8410
> Email: wey-yi.w.guy@intel.com
>
>
> -----Original Message-----
> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of Malthe Borch
> Sent: Monday, July 26, 2010 2:19 PM
> To: linux-wireless@vger.kernel.org
> Subject: Intel Wireless: Microcode SW error detected.
>
> I get this with the latest and greatest Intel firmware 9.221.4.1 build 25532.
>
> Ultimately enabling the device fails with: "uCode did not respond OK."
>
[-- Attachment #2: dmesg --]
[-- Type: application/octet-stream, Size: 1794 bytes --]
ieee80211 phy0: I iwl_print_rx_config_cmd RX CONFIG:
iwl data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
iwl data: 00000010: 00 00 00 00 00 00 00 00 00 00 0e 24 00 00 00 00 ...........$....
iwl data: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
iwl data: 00000030: 00 00 ..
ieee80211 phy0: I iwl_print_rx_config_cmd u16 channel: 0x0
ieee80211 phy0: I iwl_print_rx_config_cmd u32 flags: 0x00000000
ieee80211 phy0: I iwl_print_rx_config_cmd u32 filter_flags: 0x00000000
ieee80211 phy0: I iwl_print_rx_config_cmd u8 dev_type: 0x0
ieee80211 phy0: I iwl_print_rx_config_cmd u8 ofdm_basic_rates: 0x00
ieee80211 phy0: I iwl_print_rx_config_cmd u8 cck_basic_rates: 0x00
ieee80211 phy0: I iwl_print_rx_config_cmd u8[6] node_addr: 00:00:00:00:00:00
ieee80211 phy0: I iwl_print_rx_config_cmd u8[6] bssid_addr: 00:00:00:00:00:00
ieee80211 phy0: I iwl_print_rx_config_cmd u16 assoc_id: 0x0
ieee80211 phy0: I iwl_irq_handle_error Restarting adapter due to uCode error.
ieee80211 phy0: I iwl_rx_reply_alive Alive ucode status 0x00000000 revision 0x1 0x0
ieee80211 phy0: I iwl_rx_reply_alive Runtime Alive received.
iwlagn 0000:02:00.0: uCode did not respond OK.
ieee80211 phy0: U __iwl_down iwlagn is going down
ieee80211 phy0: U iwl_clear_ucode_stations Clearing ucode stations in driver
ieee80211 phy0: U iwl_clear_ucode_stations No active stations found to be cleared
ieee80211 phy0: U iwl_apm_stop Stop card, put in low power state
ieee80211 phy0: U iwl_apm_stop_master stop master
ieee80211 phy0: U iwl_clear_free_frames 0 frames on pre-allocated heap on clear.
iwlagn 0000:02:00.0: START_ALIVE timeout after 4000ms.
ieee80211 phy0: U iwl_configure_filter Enter: changed: 0x0, total: 0x80000000
^ permalink raw reply
* Re: virtual access poitns (ath5k/mac80211)
From: Ben Greear @ 2010-08-01 22:21 UTC (permalink / raw)
To: Ryszard; +Cc: Florian Fainelli, Patrick McHardy, linux-wireless
In-Reply-To: <AANLkTik=t=jeCG7=bgkq3LBwJP9vq7KmFpgDeHngPoq-@mail.gmail.com>
On 08/01/2010 01:56 PM, Ryszard wrote:
> Hey Florian,
>
> thanks for the help on this! Ben/Patrick, if you rebase the patches
> for this functionality, i'm more than happy and willing to do userland
> testing on this to move it along.
>
> regs
>
> On 1 August 2010 19:37, Florian Fainelli<florian@openwrt.org> wrote:
>> Hi,
>>
>> Le Sunday 1 August 2010 03:53:13, Ryszard a écrit :
>>> Hi all,
>>>
>>> i'm working on a project that requires i can create multiple access
>>> points on the one bit of hardware. After an insane amount of googling
>>> and reading the lists the closest i've been able to come up with is
>>> something along the lines of:
>>> iw dev wlan0 interface add vap0 type __ap
>>> iw dev wlan0 interface add vap1 type __ap
>>>
>>> then using macchanger to assign unique mac addresses.
>>>
>>> I've also seen something from March 2009
>>> (http://lwn.net/Articles/321690/) that hints at the functionality
>>> available with the ath9k which gave me a bit of hope!
>>>
>>> My question is, is it possible to create multiple virtual access
>>> points with my hardware ( Atheros Communications Inc. AR5413 802.11abg
>>> ) and the ath5k/mac80211 drivers (or is there some other method to
>>> achieve what i'm after) ? i'm not too fussed about different
>>> channels, but different SSID's and WPA keys are a requirement for the
>>> project.
>>
>> There is support for creating virtual interfaces using iw and ath5k here:
>> http://www.candelatech.com/oss/vsta.html
>>
>> I really wish someone could submit this mainline, unfortunately it is pretty
>> hard to isolate the commits in this tree which are implementing virtual
>> interfaces support.
>>
>> Ben, Patrick, could you rebase your patches on top of wireless-testing and
>> send them for review/testing?
You would not believe how hard it is to keep up with the wireless tree. Last time,
by the time we had something stable, upstream had changed too much to merge.
The merge from .31 to .34 was basically not happening, so we are trying to
re-do things from scratch. I've been busy working on other .34 bugs (and
updating our user-space stuff to work with .34), and haven't heard from
Patrick in a while.
We plan to get this done, but I don't know when.
For what it's worth, our .31 code works pretty well, supporting virtual STA
and APs and deals with multiple STAs trying to all scan at once, etc.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH 5/5] compat-wireless: copy headers in include/pcmcia from compat
From: Kshitij Kulshreshtha @ 2010-08-01 22:02 UTC (permalink / raw)
To: Luis R. Rodriguez, Hauke Mehrtens; +Cc: linux-wireless, Kshitij Kulshreshtha
In-Reply-To: <4C55D22A.5040302@hauke-m.de>
From: Kshitij Kulshreshtha <kshitij@math.hu-berlin.de>
this is needed after the removal of pcmcia/cs_types.h in v2.6.36
Signed-off-by: Kshitij Kulshreshtha <kshitij@math.hu-berlin.de>
---
scripts/admin-update.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/scripts/admin-update.sh b/scripts/admin-update.sh
index 4eb7c3e..8ff2ece 100755
--- a/scripts/admin-update.sh
+++ b/scripts/admin-update.sh
@@ -231,6 +231,7 @@ mkdir -p include/linux/ include/net/ include/linux/usb \
include/linux/unaligned \
include/linux/spi \
include/trace \
+ include/pcmcia \
net/mac80211/ net/wireless/ \
net/rfkill/ \
drivers/ssb/ \
@@ -353,6 +354,7 @@ cp -a $GIT_COMPAT_TREE/scripts/ $COMPAT/
cp -a $GIT_COMPAT_TREE/include/linux/* include/linux/
cp -a $GIT_COMPAT_TREE/include/net/* include/net/
cp -a $GIT_COMPAT_TREE/include/trace/* include/trace/
+cp -a $GIT_COMPAT_TREE/include/pcmcia/* include/pcmcia/
rm -f $COMPAT/*.mod.c
# Refresh patches using quilt
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] compat: header <pcmcia/cs_types.h> was removed in v2.6.36
From: Kshitij Kulshreshtha @ 2010-08-01 22:02 UTC (permalink / raw)
To: Luis R. Rodriguez, Hauke Mehrtens; +Cc: linux-wireless, Kshitij Kulshreshtha
In-Reply-To: <4C55D22A.5040302@hauke-m.de>
the header <pcmcia/cs.h> in versions < 2.6.36 requires types defined
in <pcmcia/cs_types.h> so include it first.
Signed-off-by: Kshitij Kulshreshtha <kkhere.geo@gmail.com>
---
include/pcmcia/cs.h | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644 include/pcmcia/cs.h
diff --git a/include/pcmcia/cs.h b/include/pcmcia/cs.h
new file mode 100644
index 0000000..1c5e0fa
--- /dev/null
+++ b/include/pcmcia/cs.h
@@ -0,0 +1,10 @@
+#ifndef _COMPAT_PCMCIA_CS_H
+#define _COMPAT_PCMCIA_CS_H
+#include <linux/version.h>
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36)
+#include <pcmcia/cs_types.h>
+#endif
+
+#include_next <pcmcia/cs.h>
+#endif
--
1.7.1
^ permalink raw reply related
* [PATCH 4/5] compat-wireless: allow compilation of compat-2.6.35.c from compat
From: Kshitij Kulshreshtha @ 2010-08-01 22:02 UTC (permalink / raw)
To: Luis R. Rodriguez, Hauke Mehrtens; +Cc: linux-wireless, Kshitij Kulshreshtha
In-Reply-To: <4C55D22A.5040302@hauke-m.de>
From: Kshitij Kulshreshtha <kshitij@math.hu-berlin.de>
Signed-off-by: Kshitij Kulshreshtha <kshitij@math.hu-berlin.de>
---
config.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/config.mk b/config.mk
index e8ec458..733ea33 100644
--- a/config.mk
+++ b/config.mk
@@ -20,7 +20,7 @@ endif
# as I suspect all users of this package want 802.11e (WME) and
# 802.11n (HT) support.
ifneq ($(wildcard $(KLIB_BUILD)/Makefile),)
-COMPAT_LATEST_VERSION = 33
+COMPAT_LATEST_VERSION = 35
KERNEL_SUBLEVEL := $(shell $(MAKE) -C $(KLIB_BUILD) kernelversion | sed -n 's/^2\.6\.\([0-9]\+\).*/\1/p')
COMPAT_VERSIONS := $(shell I=$(COMPAT_LATEST_VERSION); while [ "$$I" -gt $(KERNEL_SUBLEVEL) ]; do echo $$I; I=$$(($$I - 1)); done)
$(foreach ver,$(COMPAT_VERSIONS),$(eval CONFIG_COMPAT_KERNEL_$(ver)=y))
--
1.7.1
^ permalink raw reply related
* [PATCH 3/3] compat: define struct va_format introduced in v2.6.36
From: Kshitij Kulshreshtha @ 2010-08-01 22:02 UTC (permalink / raw)
To: Luis R. Rodriguez, Hauke Mehrtens; +Cc: linux-wireless, Kshitij Kulshreshtha
In-Reply-To: <4C55D22A.5040302@hauke-m.de>
Signed-off-by: Kshitij Kulshreshtha <kkhere.geo@gmail.com>
---
include/linux/compat-2.6.36.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/compat-2.6.36.h b/include/linux/compat-2.6.36.h
index 0307108..b14c772 100644
--- a/include/linux/compat-2.6.36.h
+++ b/include/linux/compat-2.6.36.h
@@ -8,6 +8,11 @@
#define kparam_block_sysfs_write(a)
#define kparam_unblock_sysfs_write(a)
+struct va_format {
+ const char *fmt;
+ va_list *va;
+};
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36)) */
#endif /* LINUX_26_36_COMPAT_H */
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3] compat: backport hex_to_bin first introduced in v2.6.35
From: Kshitij Kulshreshtha @ 2010-08-01 22:02 UTC (permalink / raw)
To: Luis R. Rodriguez, Hauke Mehrtens; +Cc: linux-wireless, Kshitij Kulshreshtha
In-Reply-To: <4C55D22A.5040302@hauke-m.de>
Signed-off-by: Kshitij Kulshreshtha <kkhere.geo@gmail.com>
---
compat/Makefile | 1 +
compat/compat-2.6.35.c | 34 ++++++++++++++++++++++++++++++++++
include/linux/compat-2.6.35.h | 2 ++
3 files changed, 37 insertions(+), 0 deletions(-)
create mode 100644 compat/compat-2.6.35.c
diff --git a/compat/Makefile b/compat/Makefile
index 2005ff3..bcd8fe7 100644
--- a/compat/Makefile
+++ b/compat/Makefile
@@ -26,3 +26,4 @@ compat-$(CONFIG_COMPAT_KERNEL_30) += compat-2.6.30.o
compat-$(CONFIG_COMPAT_KERNEL_31) += compat-2.6.31.o
compat-$(CONFIG_COMPAT_KERNEL_32) += compat-2.6.32.o
compat-$(CONFIG_COMPAT_KERNEL_33) += compat-2.6.33.o
+compat-$(CONFIG_COMPAT_KERNEL_35) += compat-2.6.35.o
diff --git a/compat/compat-2.6.35.c b/compat/compat-2.6.35.c
new file mode 100644
index 0000000..0d702ed
--- /dev/null
+++ b/compat/compat-2.6.35.c
@@ -0,0 +1,34 @@
+/*
+ * Copyright 2010 Kshitij Kulshreshtha <kkhere.geo@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Compatibility file for Linux wireless for kernels 2.6.35.
+ */
+
+#include <linux/compat.h>
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
+#include <linux/ctype.h>
+
+/**
+ * hex_to_bin - convert a hex digit to its real value
+ * @ch: ascii character represents hex digit
+ *
+ * hex_to_bin() converts one hex digit to its actual value or -1 in case of bad
+ * input.
+ */
+int hex_to_bin(char ch)
+{
+ if ((ch >= '0') && (ch <= '9'))
+ return ch - '0';
+ ch = tolower(ch);
+ if ((ch >= 'a') && (ch <= 'f'))
+ return ch - 'a' + 10;
+ return -1;
+}
+EXPORT_SYMBOL(hex_to_bin);
+
+#endif /* LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35) */
diff --git a/include/linux/compat-2.6.35.h b/include/linux/compat-2.6.35.h
index c6e7136..f0562cd 100644
--- a/include/linux/compat-2.6.35.h
+++ b/include/linux/compat-2.6.35.h
@@ -25,6 +25,8 @@ static inline wait_queue_head_t *sk_sleep(struct sock *sk)
#define sdio_writeb_readb(func, write_byte, addr, err_ret) sdio_readb(func, addr, err_ret)
+int hex_to_bin(char ch);
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)) */
#endif /* LINUX_26_35_COMPAT_H */
--
1.7.1
^ permalink raw reply related
* [PATCH] build fixes for compat.git and compat-wireless.git
From: Kshitij Kulshreshtha @ 2010-08-01 22:02 UTC (permalink / raw)
To: Luis R. Rodriguez, Hauke Mehrtens; +Cc: linux-wireless
In-Reply-To: <4C55D22A.5040302@hauke-m.de>
Hello,
here are some patches with build fixes for compat.git and
compat-wireless.git in order to build it with kernel v2.6.34.
I have incorporated the comments of Hauke Mehrtens.
Please review and apply.
Thanks and regards.
--
Kshitij Kulshreshtha
Institut für Mathematik,
Universität Paderborn,
Warburger Straße 100,
33098 Paderborn.
Büro: A3.319
^ permalink raw reply
* Re: 2.6.35-rc6-git6: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-08-01 21:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jens Axboe, Tejun Heo, Linux Kernel Mailing List, Maciej Rutecki,
Andrew Morton, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <AANLkTimcH7+Bq1UEbaSU7SQpzArPgmSLegiqE13V8=CF@mail.gmail.com>
On Sunday, August 01, 2010, Linus Torvalds wrote:
> On Sun, Aug 1, 2010 at 6:46 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
...
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16369
> > Subject : Yet another 2.6.35 regression (AGP)?
> > Submitter : Woody Suwalski <terraluna977@gmail.com>
> > Date : 2010-07-09 14:21 (24 days old)
> > Message-ID : <4C373084.8000503@gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127868797119254&w=2
>
> Should hopefully be fixed by commit e7b96f28c58c ("agp/intel: Use the
> correct mask to detect i830 aperture size.")
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16365
> > Subject : kernel BUG at fs/btrfs/extent-tree.c:1353
> > Submitter : Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
> > Date : 2010-07-08 14:27 (25 days old)
> > Message-ID : <201007081627.24654.johannes.hirte@fem.tu-ilmenau.de>
> > References : http://marc.info/?l=linux-kernel&m=127859960725931&w=2
>
> This one is reportedly fixed by commit 83ba7b071f30 ("writeback:
> simplify the write back thread queue")
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16215
> > Subject : sysfs: cannot create duplicate filename '/class/net/bnep0'
> > Submitter : Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> > Date : 2010-06-15 14:55 (48 days old)
> > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>
> Fixed by commit 24b1442d01ae155ea716dfb94ed21605541c317d.
Closed.
Thanks,
Rafael
^ permalink raw reply
* Re: virtual access poitns (ath5k/mac80211)
From: Ryszard @ 2010-08-01 20:56 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Patrick McHardy, Ben Greear, linux-wireless
In-Reply-To: <201008011137.49528.florian@openwrt.org>
Hey Florian,
thanks for the help on this! Ben/Patrick, if you rebase the patches
for this functionality, i'm more than happy and willing to do userland
testing on this to move it along.
regs
On 1 August 2010 19:37, Florian Fainelli <florian@openwrt.org> wrote:
> Hi,
>
> Le Sunday 1 August 2010 03:53:13, Ryszard a écrit :
>> Hi all,
>>
>> i'm working on a project that requires i can create multiple access
>> points on the one bit of hardware. After an insane amount of googling
>> and reading the lists the closest i've been able to come up with is
>> something along the lines of:
>> iw dev wlan0 interface add vap0 type __ap
>> iw dev wlan0 interface add vap1 type __ap
>>
>> then using macchanger to assign unique mac addresses.
>>
>> I've also seen something from March 2009
>> (http://lwn.net/Articles/321690/) that hints at the functionality
>> available with the ath9k which gave me a bit of hope!
>>
>> My question is, is it possible to create multiple virtual access
>> points with my hardware ( Atheros Communications Inc. AR5413 802.11abg
>> ) and the ath5k/mac80211 drivers (or is there some other method to
>> achieve what i'm after) ? i'm not too fussed about different
>> channels, but different SSID's and WPA keys are a requirement for the
>> project.
>
> There is support for creating virtual interfaces using iw and ath5k here:
> http://www.candelatech.com/oss/vsta.html
>
> I really wish someone could submit this mainline, unfortunately it is pretty
> hard to isolate the commits in this tree which are implementing virtual
> interfaces support.
>
> Ben, Patrick, could you rebase your patches on top of wireless-testing and
> send them for review/testing?
> --
> Florian
>
^ permalink raw reply
* [PATCH] p54pci: Add PCI ID for SMC2802W
From: Larry Finger @ 2010-08-01 20:40 UTC (permalink / raw)
To: John W Linville, chunkeey; +Cc: olbrannon, linux-wireless
The SMC2802W appears to work with p54pci.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: David Cozatt <olbrannon@gmail.com>
---
Index: wireless-testing/drivers/net/wireless/p54/p54pci.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/p54/p54pci.c
+++ wireless-testing/drivers/net/wireless/p54/p54pci.c
@@ -43,6 +43,8 @@ static DEFINE_PCI_DEVICE_TABLE(p54p_tabl
{ PCI_DEVICE(0x1260, 0x3886) },
/* Intersil PRISM Xbow Wireless LAN adapter (Symbol AP-300) */
{ PCI_DEVICE(0x1260, 0xffff) },
+ /* Standard Microsystems Corp SMC2802W Wireless PCI */
+ { PCI_DEVICE(0x10b8, 0x2802) },
{ },
};
^ permalink raw reply
* Re: SMC 2802W -status unsupported
From: Larry Finger @ 2010-08-01 20:34 UTC (permalink / raw)
To: David Cozatt; +Cc: linux-wireless
In-Reply-To: <AANLkTinU74hoPQ9tfZp12n_rQQX38OYy2qaETON-qGAu@mail.gmail.com>
On 08/01/2010 02:59 PM, David Cozatt wrote:
> ----snip--
> If I understand correctly, the device is working - only the wiki is wrong.
>
> For my info, what does 'lspci -nnk | grep 2802' show?
>
> Larry
>
> ----/snip--
> random david # lspci -nnk | grep 2802
> Subsystem: Standard Microsystems Corp [SMC] SMC2802W Wireless PCI
> Adapter [10b8:2802]
>
> One thing only bothers me not sure of wpa2 enough to know if it
> matters since I don't use the
> wireless-tools to connect but iwconfig reports-
>
> wlan0 IEEE 802.11bg ESSID:"Davespace"
> Mode:Managed Frequency:2.437 GHz Access Point: 00:1C:10:9C:32:87
> Bit Rate=48 Mb/s Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> Link Quality=70/70 Signal level=-1 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> doesn't care? sinde we use wpa? on the enc off?
The encryption is being handled by mac80211, wpa_supplicant, and the device. The
"encryption key:off" should be ignored. The wireless extension tools such as
iwconfig are being phased out and do not always have the best information.
Looking at the driver code, we need the patch below to enable the device:
Index: wireless-testing/drivers/net/wireless/p54/p54pci.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/p54/p54pci.c
+++ wireless-testing/drivers/net/wireless/p54/p54pci.c
@@ -43,6 +43,8 @@ static DEFINE_PCI_DEVICE_TABLE(p54p_tabl
{ PCI_DEVICE(0x1260, 0x3886) },
/* Intersil PRISM Xbow Wireless LAN adapter (Symbol AP-300) */
{ PCI_DEVICE(0x1260, 0xffff) },
+ /* Standard Microsystems Corp SMC2802W Wireless PCI */
+ { PCI_DEVICE(0x10b8, 0x2802) },
{ },
};
I will do a formal submission of the patch and edit the wiki.
Larry
^ permalink raw reply
* Re: SMC 2802W -status unsupported
From: David Cozatt @ 2010-08-01 19:59 UTC (permalink / raw)
To: linux-wireless
----snip--
If I understand correctly, the device is working - only the wiki is wrong.
For my info, what does 'lspci -nnk | grep 2802' show?
Larry
----/snip--
random david # lspci -nnk | grep 2802
Subsystem: Standard Microsystems Corp [SMC] SMC2802W Wireless PCI
Adapter [10b8:2802]
One thing only bothers me not sure of wpa2 enough to know if it
matters since I don't use the
wireless-tools to connect but iwconfig reports-
wlan0 IEEE 802.11bg ESSID:"Davespace"
Mode:Managed Frequency:2.437 GHz Access Point: 00:1C:10:9C:32:87
Bit Rate=48 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=-1 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
doesn't care? sinde we use wpa? on the enc off?
^ permalink raw reply
* Re: compat-wireless-2010-07-28.tar.bz2 fails to compile with 2.6.34.1
From: Hauke Mehrtens @ 2010-08-01 19:59 UTC (permalink / raw)
To: Kshitij Kulshreshtha; +Cc: linux-wireless, lrodriguez
In-Reply-To: <4C5184E8.30108@gmail.com>
Am 29.07.2010 15:40, schrieb Kshitij Kulshreshtha:
> Hello,
>
> I downloaded compat-wireless-2010-07-28.tar.bz2 from [1] and tried to
> compile it with kernel v2.6.34.1 (config attached) that is running on
> my laptop currently. Unfortunately the package failed to compile with
> several compilation errors (compilation log attached, grep for Error).
>
> I had to apply the attached 3 patches to make it compile. Please update
> compat-wireless and compat git trees accordingly.
>
> Thanks and regards.
>
> [1] http://wireless.kernel.org/download/compat-wireless-2.6/
Hi Kshitij,
thank you for your patches.
Next time please inline your patches into the mail. It makes commenting
on the patch easier. See:
http://wireless.kernel.org/en/users/Download/hacking#Sending_patches
0001-hex_to_bin-was-added-first-in-2.6.35.patch:
hex_to_bin should be backported in compat. Then we do not need to add an
extra patch to compat-wireless. Patches in compat-wireless are hard to
maintain, because the wireless subsystem changes very often and the
patches have to be fixes very often.
0002-Header-file-pcmcia-cs_types.h-has-been-removed-in-2..patch:
This should also be backported in compat and not in compat-wireless. You
can add include/pcmcia/cistpl.h and include the needed file
(pcmcia/cs_types.h) and the original with #include_next <pcmcia/cistpl.h>
Hauke
^ permalink raw reply
* Re: 2.6.35-rc6-git6: Reported regressions from 2.6.34
From: Larry Finger @ 2010-08-01 19:39 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <2dWFdr9kTFM.A.P0D.spXVMB@chimera>
On 08/01/2010 08:46 AM, Rafael J. Wysocki wrote:
> This message contains a list of some regressions from 2.6.34,
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 2.6.34, please let us
> know either and we'll add them to the list. Also, please let us know
> if any of the entries below are invalid.
>
> Each entry from the list will be sent additionally in an automatic reply
> to this message with CCs to the people involved in reporting and handling
> the issue.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16312
> Subject : WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
> Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com>
> Date : 2010-06-28 9:40 (35 days old)
> Message-ID : <AANLkTin24fr5O4_q5Xbo9Y_NKkEmtcp6Hgmr9_4qXaFz@mail.gmail.com>
> References : http://marc.info/?l=linux-kernel&m=127771804806465&w=2
> Handled-By : Jan Kara <jack@suse.cz>
> Patch : https://bugzilla.kernel.org/attachment.cgi?id=27272
I am beginning to think that Bug 16312 is not the same as Bug 16122. Even with
the patches from 16312, I still get warnings as below:
[ 11.728776] ------------[ cut here ]------------
[ 11.728787] WARNING: at fs/fs-writeback.c:964 __mark_inode_dirty+0x10f/0x1a0()
[ 11.728790] Hardware name: HP Pavilion dv2700 Notebook PC
[ 11.728792] Modules linked in: loop(+) dm_mod ide_cd_mod cdrom
snd_hda_codec_conexant ide_pci_generic arc4 ecb b43 rng_core mac80211
snd_hda_intel r8712u(C) cfg80211 snd_hda_codec amd74xx snd_pcm sg ide_core
rfkill led_class snd_timer ssb mmc_core pcmcia snd joydev k8temp hwmon
i2c_nforce2 pcmcia_core forcedeth serio_raw snd_page_alloc i2c_core battery ac
button ext4 mbcache jbd2 crc16 ohci_hcd sd_mod ehci_hcd usbcore fan processor
ahci libahci libata scsi_mod thermal
[ 11.728854] Pid: 2449, comm: udisks-part-id Tainted: G C
2.6.35-rc6-realtek+ #15
[ 11.728857] Call Trace:
[ 11.728865] [<ffffffff8104608a>] warn_slowpath_common+0x7a/0xb0
[ 11.728869] [<ffffffff810460d5>] warn_slowpath_null+0x15/0x20
[ 11.728874] [<ffffffff81129d5f>] __mark_inode_dirty+0x10f/0x1a0
[ 11.728879] [<ffffffff8111e07d>] touch_atime+0x12d/0x170
[ 11.728885] [<ffffffff810cab91>] generic_file_aio_read+0x5c1/0x720
[ 11.728890] [<ffffffff81107ca2>] do_sync_read+0xd2/0x110
[ 11.728896] [<ffffffff81077e7d>] ? trace_hardirqs_on+0xd/0x10
[ 11.728900] [<ffffffff811083c3>] vfs_read+0xb3/0x170
[ 11.728906] [<ffffffff81002d1c>] ? sysret_check+0x27/0x62
[ 11.728909] [<ffffffff811084cc>] sys_read+0x4c/0x80
[ 11.728914] [<ffffffff81002ceb>] system_call_fastpath+0x16/0x1b
[ 11.728917] ---[ end trace 32e16cacad33229f ]---
[ 11.728919] bdi-block not registered
The warnings do not occur with every boot and appear to be some kind of race
condition.
Larry
^ permalink raw reply
* [iw] Implement set 4addr.
From: Jochen Friedrich @ 2010-08-01 19:03 UTC (permalink / raw)
To: linux-wireless; +Cc: Jochen Friedrich
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
interface.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/interface.c b/interface.c
index c092aa2..e6cca4f 100644
--- a/interface.c
+++ b/interface.c
@@ -365,3 +365,16 @@ COMMAND(set, type, "<type>",
NL80211_CMD_SET_INTERFACE, 0, CIB_NETDEV, handle_interface_type,
"Set interface type/mode.\n"
IFACE_TYPES);
+
+static int handle_interface_4addr(struct nl80211_state *state,
+ struct nl_cb *cb,
+ struct nl_msg *msg,
+ int argc, char **argv)
+{
+ if (argc != 1)
+ return 1;
+ return parse_4addr_flag(argv[0], msg);
+}
+COMMAND(set, 4addr, "<on|off>",
+ NL80211_CMD_SET_INTERFACE, 0, CIB_NETDEV, handle_interface_4addr,
+ "Set interface 4addr (WDS) mode.\n");
--
1.7.1
^ permalink raw reply related
* Compat-wireless release for 2010-08-01 is baked
From: Compat-wireless cronjob account @ 2010-08-01 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
494088 - Total upstream lines of code being pulled
1447 - backport code changes
1211 - backport code additions
236 - backport code deletions
5764 - backport from compat module
7211 - total backport code
1.4595 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2465 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100730
compat-wireless release: compat-wireless-2010-07-13-4-g04898a5
^ permalink raw reply
* Re: [PATCH 04/11] pcmcia: do not use io_req_t after call to pcmcia_request_io()
From: Marcel Holtmann @ 2010-08-01 18:04 UTC (permalink / raw)
To: Dominik Brodowski
Cc: linux-pcmcia, netdev, linux-wireless, linux-ide, linux-usb,
laforge, linux-mtd, linux-bluetooth, alsa-devel, linux-serial
In-Reply-To: <1280667550-3040-4-git-send-email-linux@dominikbrodowski.net>
Hi Dominik,
> After pcmcia_request_io(), do not make use of the values stored in
> io_req_t, but instead use those found in struct pcmcia_device->resource[].
>
> CC: netdev@vger.kernel.org
> CC: linux-wireless@vger.kernel.org
> CC: linux-ide@vger.kernel.org
> CC: linux-usb@vger.kernel.org
> CC: laforge@gnumonks.org
> CC: linux-mtd@lists.infradead.org
> CC: linux-bluetooth@vger.kernel.org
> CC: alsa-devel@alsa-project.org
> CC: linux-serial@vger.kernel.org
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
for the drivers/bluetooth/ pieces.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 05/11] pcmcia: do not use io_req_t when calling pcmcia_request_io()
From: Marcel Holtmann @ 2010-08-01 18:04 UTC (permalink / raw)
To: Dominik Brodowski
Cc: linux-pcmcia, netdev, linux-wireless, linux-ide, linux-usb,
laforge, linux-mtd, linux-bluetooth, alsa-devel, linux-serial,
Michael Buesch
In-Reply-To: <1280667550-3040-5-git-send-email-linux@dominikbrodowski.net>
Hi Dominik,
> Instead of io_req_t, drivers are now requested to fill out
> struct pcmcia_device *p_dev->resource[0,1] for up to two ioport
> ranges. After a call to pcmcia_request_io(), the ports found there
> are reserved, after calling pcmcia_request_configuration(), they may
> be used.
>
> CC: netdev@vger.kernel.org
> CC: linux-wireless@vger.kernel.org
> CC: linux-ide@vger.kernel.org
> CC: linux-usb@vger.kernel.org
> CC: laforge@gnumonks.org
> CC: linux-mtd@lists.infradead.org
> CC: linux-bluetooth@vger.kernel.org
> CC: alsa-devel@alsa-project.org
> CC: linux-serial@vger.kernel.org
> CC: Michael Buesch <mb@bu3sch.de>
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
for the drivers/bluetooth/ pieces.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: 2.6.35-rc6-git6: Reported regressions from 2.6.34
From: Linus Torvalds @ 2010-08-01 18:01 UTC (permalink / raw)
To: Rafael J. Wysocki, Jens Axboe, Tejun Heo
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <2dWFdr9kTFM.A.P0D.spXVMB@chimera>
On Sun, Aug 1, 2010 at 6:46 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16400
> Subject : 2.6.35-rc5 inconsistent lock state
> Submitter : Martin Pirker <lkml.collector@gmail.com>
> Date : 2010-07-14 20:33 (19 days old)
> Message-ID : <AANLkTikDF0TL6OyPVCzPlUTwxFehcrETn3ysgSSeTq92@mail.gmail.com>
> References : http://marc.info/?l=linux-kernel&m=127913961025267&w=2
This has a proposed patch. I don't know what the status of it is, though. Jens?
http://marc.info/?l=linux-kernel&m=127950018204029&w=2
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16393
> Subject : kernel BUG at fs/block_dev.c:765!
> Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
> Date : 2010-07-14 13:52 (19 days old)
> Message-ID : <20100714135217.GA1797@arch.tripp.de>
> References : http://marc.info/?l=linux-kernel&m=127911564213748&w=2
This one is interesting. And I think I perhaps see where it's coming from.
bd_start_claiming() (through bd_prepare_to_claim()) has two separate
success cases: either there was no holder (bd_claiming is NULL) or the
new holder was already claiming it (bd_claiming == holder).
Note in particular the case of the holder _already_ holding it. What happens is:
- bd_start_claiming() succeeds because we had _already_ claimed it
with the same holder
- then some error happens, and we call bd_abort_claiming(), which
does whole->bd_claiming = NULL;
- the original holder thinks it still holds the bd, but it has been released!
- a new claimer comes in, and succeeds because bd_claiming is now NULL.
- we now have two "owners" of the bd, but bd_claiming only points to
the second one.
I think bd_start_claiming() needs to do some kind of refcount for the
nested holder case, and bd_abort_claiming() needs to decrement the
refcount and only clear the bd_claiming field when it goes down to
zero.
I dunno. Maybe there's something else going on, but it does look
suspicious, and the above would explain the BUG_ON().
Tejun, Jens?
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16369
> Subject : Yet another 2.6.35 regression (AGP)?
> Submitter : Woody Suwalski <terraluna977@gmail.com>
> Date : 2010-07-09 14:21 (24 days old)
> Message-ID : <4C373084.8000503@gmail.com>
> References : http://marc.info/?l=linux-kernel&m=127868797119254&w=2
Should hopefully be fixed by commit e7b96f28c58c ("agp/intel: Use the
correct mask to detect i830 aperture size.")
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16365
> Subject : kernel BUG at fs/btrfs/extent-tree.c:1353
> Submitter : Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
> Date : 2010-07-08 14:27 (25 days old)
> Message-ID : <201007081627.24654.johannes.hirte@fem.tu-ilmenau.de>
> References : http://marc.info/?l=linux-kernel&m=127859960725931&w=2
This one is reportedly fixed by commit 83ba7b071f30 ("writeback:
simplify the write back thread queue")
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16215
> Subject : sysfs: cannot create duplicate filename '/class/net/bnep0'
> Submitter : Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> Date : 2010-06-15 14:55 (48 days old)
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
Fixed by commit 24b1442d01ae155ea716dfb94ed21605541c317d.
Linus
^ permalink raw reply
* Re: [PATCH] mac80211: Don't squash error codes in key setup functions
From: Johannes Berg @ 2010-08-01 17:12 UTC (permalink / raw)
To: Ben Hutchings; +Cc: John W. Linville, linux-wireless, Marcin Owsiany, 550739
In-Reply-To: <1280680623.13192.382.camel@localhost>
On Sun, 2010-08-01 at 17:37 +0100, Ben Hutchings wrote:
> ieee80211_add_key() currently returns -ENOMEM in case of any error,
> including a missing crypto algorithm. Change ieee80211_key_alloc()
> and ieee80211_aes_{key_setup_encrypt,cmac_key_setup}() to encode
> errors with ERR_PTR() rather than returning NULL, and change
> ieee80211_add_key() accordingly.
>
> Compile-tested only.
Looks good to me.
Acked-by: Johannes Berg <johannes@sipsolutions.net>
> Reported-by: Marcin Owsiany <porridge@debian.org>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> net/mac80211/aes_ccm.c | 6 ++----
> net/mac80211/aes_cmac.c | 6 ++----
> net/mac80211/cfg.c | 4 ++--
> net/mac80211/key.c | 14 ++++++++------
> 4 files changed, 14 insertions(+), 16 deletions(-)
>
> diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
> index a87cb3b..d2b03e0 100644
> --- a/net/mac80211/aes_ccm.c
> +++ b/net/mac80211/aes_ccm.c
> @@ -138,10 +138,8 @@ struct crypto_cipher *ieee80211_aes_key_setup_encrypt(const u8 key[])
> struct crypto_cipher *tfm;
>
> tfm = crypto_alloc_cipher("aes", 0, CRYPTO_ALG_ASYNC);
> - if (IS_ERR(tfm))
> - return NULL;
> -
> - crypto_cipher_setkey(tfm, key, ALG_CCMP_KEY_LEN);
> + if (!IS_ERR(tfm))
> + crypto_cipher_setkey(tfm, key, ALG_CCMP_KEY_LEN);
>
> return tfm;
> }
> diff --git a/net/mac80211/aes_cmac.c b/net/mac80211/aes_cmac.c
> index 3d097b3..b4d66cc 100644
> --- a/net/mac80211/aes_cmac.c
> +++ b/net/mac80211/aes_cmac.c
> @@ -119,10 +119,8 @@ struct crypto_cipher * ieee80211_aes_cmac_key_setup(const u8 key[])
> struct crypto_cipher *tfm;
>
> tfm = crypto_alloc_cipher("aes", 0, CRYPTO_ALG_ASYNC);
> - if (IS_ERR(tfm))
> - return NULL;
> -
> - crypto_cipher_setkey(tfm, key, AES_CMAC_KEY_LEN);
> + if (!IS_ERR(tfm))
> + crypto_cipher_setkey(tfm, key, AES_CMAC_KEY_LEN);
>
> return tfm;
> }
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index db4d934..34f32e3 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -150,8 +150,8 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
>
> key = ieee80211_key_alloc(alg, key_idx, params->key_len, params->key,
> params->seq_len, params->seq);
> - if (!key)
> - return -ENOMEM;
> + if (IS_ERR(key))
> + return PTR_ERR(key);
>
> mutex_lock(&sdata->local->sta_mtx);
>
> diff --git a/net/mac80211/key.c b/net/mac80211/key.c
> index 50d1cff..acf97d6 100644
> --- a/net/mac80211/key.c
> +++ b/net/mac80211/key.c
> @@ -234,13 +234,13 @@ struct ieee80211_key *ieee80211_key_alloc(enum ieee80211_key_alg alg,
> size_t seq_len, const u8 *seq)
> {
> struct ieee80211_key *key;
> - int i, j;
> + int i, j, err;
>
> BUG_ON(idx < 0 || idx >= NUM_DEFAULT_KEYS + NUM_DEFAULT_MGMT_KEYS);
>
> key = kzalloc(sizeof(struct ieee80211_key) + key_len, GFP_KERNEL);
> if (!key)
> - return NULL;
> + return ERR_PTR(-ENOMEM);
>
> /*
> * Default to software encryption; we'll later upload the
> @@ -296,9 +296,10 @@ struct ieee80211_key *ieee80211_key_alloc(enum ieee80211_key_alg alg,
> * it does not need to be initialized for every packet.
> */
> key->u.ccmp.tfm = ieee80211_aes_key_setup_encrypt(key_data);
> - if (!key->u.ccmp.tfm) {
> + if (IS_ERR(key->u.ccmp.tfm)) {
> + err = PTR_ERR(key->u.ccmp.tfm);
> kfree(key);
> - return NULL;
> + key = ERR_PTR(err);
> }
> }
>
> @@ -309,9 +310,10 @@ struct ieee80211_key *ieee80211_key_alloc(enum ieee80211_key_alg alg,
> */
> key->u.aes_cmac.tfm =
> ieee80211_aes_cmac_key_setup(key_data);
> - if (!key->u.aes_cmac.tfm) {
> + if (IS_ERR(key->u.aes_cmac.tfm)) {
> + err = PTR_ERR(key->u.aes_cmac.tfm);
> kfree(key);
> - return NULL;
> + key = ERR_PTR(err);
> }
> }
>
^ permalink raw reply
* wl1251 issues
From: Denis 'GNUtoo' Carikli @ 2010-08-01 17:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Kalle Valo
[-- Attachment #1: Type: text/plain, Size: 5876 bytes --]
Hi, I've an htc dream(also known as G1,first google phone,same device
than the ADP1 )
I prefer GNU/Linux than android,mainly because of the small number of
free software applications for android,and also because I'm used to
GNU/Linux(I feel at home).
So I helped standardizing and debugging the htcdream kernel in order to
be able to run GNU/Linux (android has its own userland interfaces for
some periphericals/devices(I mean something like the sound driver,the
wifi driver etc...))
The wifi driver that ships with android is free software,the sources are
available here:
http://android.git.kernel.org/?p=platform/hardware/ti/wlan.git;a=summary
But unfortunately it uses non-standard userspace<->kernel interfaces.
The non-standard interfaces are used by a patched wpa_supplicant.
The non-standard wpa_supplicant depend on android.
But...there is a wl1251_sdio standard driver in the android kernel we
used,which is available here:
http://gitorious.org/htc-msm-2-6-32/leviathan-incoming/commits/android-msm-2.6.32-rebase
It is derived from the android-msm-2.6.32 branch of the android kernel
available here:
http://android.git.kernel.org/?p=kernel/msm.git;a=summary
At first I used this driver.
But unfortunately it didn't support Power saving modes,and so it
consumed the battery in about one hour.
Fortunately compat-wireless has support for Power saving.
So I used that locally and made tests.
So my goal is to have a working wireless driver with PSM and have
standard kernel interfaces(in order to be compatible with userland
applications),using the android ti wlan driver would be the last resort.
The wl1251_sdio depends on the msm sdcard controller which lives at:
drivers/mmc/host/msm_sdcc.c
it contains the flollowing patch:
sdio: add new function for RAW (Read after Write) operation
viewable here:
http://gitorious.org/htc-msm-2-6-32/leviathan-incoming/commit/03e2cd19cb8b0a486ef8b8f2bec60d3c1b88d8b4
In order to keep the conversation and the flow of mail manageable I will
start with the first issue which doesn't involve PSM.
Here's the setup:
*kernel:
http://gitorious.org/htc-msm-2-6-32/leviathan-incoming/commits/android-msm-2.6.32-rebase at the following commit:
sdio: add new function for RAW (Read after Write) operation
*compat-wireless 2010-07-31 with the following attached patches patches:
0011-wl1251-add-reset-handling.patch
0013-wl1251-prevent-scan-when-connected.patch
va_vormat-2.6.36.patch
debug.patch
all is built with openembedded(the compat-wireless recipe is not
commited in org.openembedded.dev because it's changing so often)
Here's the issue(this first issue doesn't involve PSM yet):
I connect trough wpa to the local access point at the wifi cafee(wrt54
somrthing,running an old openwrt with a 2.4 kernel and the proprietary
broadcom module)
I use dhcp to get an ip
The connection last for a while and then I've that:
wlan0 IEEE 802.11bg ESSID:"essid_has_been_hidden_in_that_mail"
Mode:Managed Frequency:2.432 GHz Access Point:
00:23:69:XX:XX:XX
Bit Rate=1 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=43/70 Signal level=-67 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
That seem connected.
root@htcdream ~ # ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes
^C
--- 192.168.2.1 ping statistics ---
22 packets transmitted, 0 packets received, 100% packet loss
here's the wpa connection script output:
ot@htcdream ~ # sh wpa.sh
CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:23:69:xx:xx:xx
(SSID='essid_has_been_hidden_in_that_mail' freq=2432 MHz)
Associated with 00:23:69:xx:xx:xx
WPA: Key negotiation completed with 00:23:69:xx:xx:xx [PTK=CCMP
GTK=CCMP]
CTRL-EVENT-CONNECTED - Connection to 00:23:69:xx:xx:xx completed (auth)
[id=0 id_str=]
the essid and mac address have been changed.
a while true;do dmesg -c;done gave a still flowing flow of messages:
here's a part of it:
[ 3233.009460] wl1251: IRQ
[ 3233.011016] wl1251: IRQ work
[ 3233.011199] wl1251: intr: 0x1
[ 3233.011260] wl1251: RX: FW +1
[ 3233.011260] wl1251: RX counter: 13
[ 3233.011291] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 3233.011413] wl1251: rx skb 0xc4664c00: 144 B beacon
[ 3233.039428] wl1251: IRQ
[ 3233.039611] wl1251: IRQ work
[ 3233.039764] wl1251: intr: 0x8
[ 3233.039825] wl1251: RX: FW +1
[ 3233.039825] wl1251: RX counter: 14
[ 3233.039855] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 3233.039947] wl1251: rx skb 0xc4664300: 18 B beacon
[ 3233.089447] wl1251: IRQ
[ 3233.089538] wl1251: IRQ work
[ 3233.089660] wl1251: intr: 0x1
[ 3233.089721] wl1251: RX: FW +1
[ 3233.089721] wl1251: RX counter: 15
[ 3233.089752] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 3233.089874] wl1251: rx skb 0xc4664780: 18 B beacon
[ 3233.109436] wl1251: IRQ
[ 3233.109527] wl1251: IRQ work
[ 3233.109680] wl1251: intr: 0x8
[ 3233.109741] wl1251: RX: FW +1
[ 3233.109741] wl1251: RX counter: 0
[ 3233.109741] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 3233.109863] wl1251: rx skb 0xc46649c0: 144 B beacon
[ 3233.159484] wl1251: IRQ
[ 3233.159637] wl1251: IRQ work
[ 3233.159790] wl1251: intr: 0x9
[ 3233.159851] wl1251: RX: FW +2
[ 3233.159851] wl1251: RX counter: 2
[ 3233.159881] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 3233.159973] wl1251: rx skb 0xc4664780: 18 B beacon
[ 3233.160064] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 3233.160186] wl1251: rx skb 0xc4664780: 18 B beacon
[ 3233.209472] wl1251: IRQ
[ 3233.209564] wl1251: IRQ work
[ 3233.209686] wl1251: intr: 0x1
[ 3233.209747] wl1251: RX: FW +1
[ 3233.209777] wl1251: RX counter: 3
[ 3233.209777] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 3233.209899] wl1251: rx skb 0xc4664840: 144 B beacon
I've also a rt2070 card, should I make tests with that card instead?
Denis
[-- Attachment #2: 0011-wl1251-add-reset-handling.patch --]
[-- Type: text/x-patch, Size: 1012 bytes --]
Index: compat-wireless-2010-06-19/drivers/net/wireless/wl12xx/wl1251_sdio.c
===================================================================
--- compat-wireless-2010-06-19.orig/drivers/net/wireless/wl12xx/wl1251_sdio.c 2010-06-20 22:04:12.776553632 +0200
+++ compat-wireless-2010-06-19/drivers/net/wireless/wl12xx/wl1251_sdio.c 2010-06-20 22:06:30.375232047 +0200
@@ -131,6 +131,20 @@
static void wl1251_sdio_reset(struct wl1251 *wl)
{
+ extern int sdio_reset_comm(struct mmc_card *card);
+ struct sdio_func *func = wl_to_func(wl);
+ int ret;
+
+ sdio_claim_host(func);
+ sdio_reset_comm(func->card);
+ ret = sdio_enable_func(func);
+ if (ret)
+ goto release;
+
+ sdio_set_block_size(func, 512);
+
+release:
+ sdio_release_host(func);
}
static void wl1251_sdio_enable_irq(struct wl1251 *wl)
@@ -271,6 +285,9 @@
ret = wl1251_init_ieee80211(wl);
if (ret)
goto out_free_irq;
+
+ /* we can power it down now until it's started */
+ wl->set_power(0);
sdio_set_drvdata(func, wl);
return ret;
[-- Attachment #3: 0013-wl1251-prevent-scan-when-connected.patch --]
[-- Type: text/x-patch, Size: 1164 bytes --]
Index: compat-wireless-2010-07-31/drivers/net/wireless/wl12xx/wl1251.h
===================================================================
--- compat-wireless-2010-07-31.orig/drivers/net/wireless/wl12xx/wl1251.h 2010-08-01 15:04:21.219724545 +0200
+++ compat-wireless-2010-07-31/drivers/net/wireless/wl12xx/wl1251.h 2010-08-01 15:05:22.307219824 +0200
@@ -381,7 +381,9 @@
u32 chip_id;
char fw_ver[21];
-
+
+ bool associated;
+
/* Most recently reported noise in dBm */
s8 noise;
};
Index: compat-wireless-2010-07-31/drivers/net/wireless/wl12xx/wl1251_main.c
===================================================================
--- compat-wireless-2010-07-31.orig/drivers/net/wireless/wl12xx/wl1251_main.c 2010-08-01 15:04:32.919105073 +0200
+++ compat-wireless-2010-07-31/drivers/net/wireless/wl12xx/wl1251_main.c 2010-08-01 15:05:59.668541777 +0200
@@ -874,6 +874,13 @@
wl1251_debug(DEBUG_MAC80211, "mac80211 hw scan");
+ /*
+ * FIXME: scanning while associated causes lockups,
+ * so we don't allow that
+ */
+ if (wl->associated)
+ return -EBUSY;
+
if (req->n_ssids) {
ssid = req->ssids[0].ssid;
ssid_len = req->ssids[0].ssid_len;
[-- Attachment #4: va_vormat-2.6.36.patch --]
[-- Type: text/x-patch, Size: 583 bytes --]
Index: compat-wireless-2010-07-31/include/linux/compat-2.6.36.h
===================================================================
--- compat-wireless-2010-07-31.orig/include/linux/compat-2.6.36.h 2010-08-01 15:28:00.299100291 +0200
+++ compat-wireless-2010-07-31/include/linux/compat-2.6.36.h 2010-08-01 15:28:26.847223098 +0200
@@ -8,6 +8,11 @@
#define kparam_block_sysfs_write(a)
#define kparam_unblock_sysfs_write(a)
+struct va_format {
+ const char *fmt;
+ va_list *va;
+};
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36)) */
#endif /* LINUX_26_36_COMPAT_H */
[-- Attachment #5: debug.patch --]
[-- Type: text/x-patch, Size: 496 bytes --]
Index: compat-wireless-2010-07-17/drivers/net/wireless/wl12xx/wl1251.h
===================================================================
--- compat-wireless-2010-07-17.orig/drivers/net/wireless/wl12xx/wl1251.h 2010-07-18 18:55:22.054116356 +0200
+++ compat-wireless-2010-07-17/drivers/net/wireless/wl12xx/wl1251.h 2010-07-18 18:55:37.583421412 +0200
@@ -52,7 +52,7 @@
DEBUG_ALL = ~0,
};
-#define DEBUG_LEVEL (DEBUG_NONE)
+#define DEBUG_LEVEL (DEBUG_ALL)
#define DEBUG_DUMP_LIMIT 1024
^ permalink raw reply
* [PATCH] mac80211: Don't squash error codes in key setup functions
From: Ben Hutchings @ 2010-08-01 16:37 UTC (permalink / raw)
To: John W. Linville; +Cc: Johannes Berg, linux-wireless, Marcin Owsiany, 550739
ieee80211_add_key() currently returns -ENOMEM in case of any error,
including a missing crypto algorithm. Change ieee80211_key_alloc()
and ieee80211_aes_{key_setup_encrypt,cmac_key_setup}() to encode
errors with ERR_PTR() rather than returning NULL, and change
ieee80211_add_key() accordingly.
Compile-tested only.
Reported-by: Marcin Owsiany <porridge@debian.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
net/mac80211/aes_ccm.c | 6 ++----
net/mac80211/aes_cmac.c | 6 ++----
net/mac80211/cfg.c | 4 ++--
net/mac80211/key.c | 14 ++++++++------
4 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index a87cb3b..d2b03e0 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -138,10 +138,8 @@ struct crypto_cipher *ieee80211_aes_key_setup_encrypt(const u8 key[])
struct crypto_cipher *tfm;
tfm = crypto_alloc_cipher("aes", 0, CRYPTO_ALG_ASYNC);
- if (IS_ERR(tfm))
- return NULL;
-
- crypto_cipher_setkey(tfm, key, ALG_CCMP_KEY_LEN);
+ if (!IS_ERR(tfm))
+ crypto_cipher_setkey(tfm, key, ALG_CCMP_KEY_LEN);
return tfm;
}
diff --git a/net/mac80211/aes_cmac.c b/net/mac80211/aes_cmac.c
index 3d097b3..b4d66cc 100644
--- a/net/mac80211/aes_cmac.c
+++ b/net/mac80211/aes_cmac.c
@@ -119,10 +119,8 @@ struct crypto_cipher * ieee80211_aes_cmac_key_setup(const u8 key[])
struct crypto_cipher *tfm;
tfm = crypto_alloc_cipher("aes", 0, CRYPTO_ALG_ASYNC);
- if (IS_ERR(tfm))
- return NULL;
-
- crypto_cipher_setkey(tfm, key, AES_CMAC_KEY_LEN);
+ if (!IS_ERR(tfm))
+ crypto_cipher_setkey(tfm, key, AES_CMAC_KEY_LEN);
return tfm;
}
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index db4d934..34f32e3 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -150,8 +150,8 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
key = ieee80211_key_alloc(alg, key_idx, params->key_len, params->key,
params->seq_len, params->seq);
- if (!key)
- return -ENOMEM;
+ if (IS_ERR(key))
+ return PTR_ERR(key);
mutex_lock(&sdata->local->sta_mtx);
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 50d1cff..acf97d6 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -234,13 +234,13 @@ struct ieee80211_key *ieee80211_key_alloc(enum ieee80211_key_alg alg,
size_t seq_len, const u8 *seq)
{
struct ieee80211_key *key;
- int i, j;
+ int i, j, err;
BUG_ON(idx < 0 || idx >= NUM_DEFAULT_KEYS + NUM_DEFAULT_MGMT_KEYS);
key = kzalloc(sizeof(struct ieee80211_key) + key_len, GFP_KERNEL);
if (!key)
- return NULL;
+ return ERR_PTR(-ENOMEM);
/*
* Default to software encryption; we'll later upload the
@@ -296,9 +296,10 @@ struct ieee80211_key *ieee80211_key_alloc(enum ieee80211_key_alg alg,
* it does not need to be initialized for every packet.
*/
key->u.ccmp.tfm = ieee80211_aes_key_setup_encrypt(key_data);
- if (!key->u.ccmp.tfm) {
+ if (IS_ERR(key->u.ccmp.tfm)) {
+ err = PTR_ERR(key->u.ccmp.tfm);
kfree(key);
- return NULL;
+ key = ERR_PTR(err);
}
}
@@ -309,9 +310,10 @@ struct ieee80211_key *ieee80211_key_alloc(enum ieee80211_key_alg alg,
*/
key->u.aes_cmac.tfm =
ieee80211_aes_cmac_key_setup(key_data);
- if (!key->u.aes_cmac.tfm) {
+ if (IS_ERR(key->u.aes_cmac.tfm)) {
+ err = PTR_ERR(key->u.aes_cmac.tfm);
kfree(key);
- return NULL;
+ key = ERR_PTR(err);
}
}
--
1.7.1
^ permalink raw reply related
* Re: SMC 2802W -status unsupported
From: Larry Finger @ 2010-08-01 16:35 UTC (permalink / raw)
To: David Cozatt; +Cc: linux-wireless
In-Reply-To: <AANLkTi=XOECFnOgB5mmaDejVhH2aAEedYqz9tyeSz7Ge@mail.gmail.com>
On 08/01/2010 11:17 AM, David Cozatt wrote:
> Accessing http://wireless.kernel.org/en/users/Drivers/p54 shows in unsupported
>
> * early PrismGT cards (e.g.: Netgear WG511v1, SMC 2802W)
>
> There are 2 revisions of this model
>
> random david # lspci -vv | grep SMC
> Subsystem: Standard Microsystems Corp [SMC] SMC2802W Wireless PCI Adapter
> random david # lspci -vv | grep Wireless
> Subsystem: Standard Microsystems Corp [SMC] SMC2802W Wireless PCI Adapter
> random david # dmesg | grep phy0
>
> phy0: p54 detected a LM86 firmware
> phy0: FW rev 2.13.12.0 - Softmac protocol 5.9
> phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
> phy0: hwaddr 00:04:e2:63:c2:67, MAC:isl3890 RF:Duette3
> phy0: Selected rate control algorithm 'minstrel'
> p54pci 0000:00:0a.0: is registered as 'phy0'
>
> Part numbers:
> 99-012084-164
> 99-012084-285
>
> You can verify this with choosing the 2802W from the drop down boxes
> @http://www.smc.com/index.cfm?event=downloads.searchCriteria&localeCode=EN_USA&knowsPartNumber=false&productCategory=5&modelNumber=536&downloadType=0&os=0
>
> Mine is the -164 version. Anything else needed to confirm working properly?
If I understand correctly, the device is working - only the wiki is wrong.
For my info, what does 'lspci -nnk | grep 2802' show?
Larry
^ 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