* Re: iwlagn is getting very shaky
From: wwguy @ 2011-10-26 19:36 UTC (permalink / raw)
To: Norbert Preining
Cc: David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <20111026043419.GA30368@gamma.logic.tuwien.ac.at>
On Tue, 2011-10-25 at 21:34 -0700, Norbert Preining wrote:
> On Di, 25 Okt 2011, wwguy wrote:
> > > But *I* cannot be sure about it ;-)
> > >
> > Are you seeing this without suspend/resume?
>
> Yes. I just shut down and started, and the same happens again. If you
> need the dmesg output let me know.
>
please send us the log, but I will be late on response since I am on
business trip until the end of next week.
Thanks
Wey
^ permalink raw reply
* Re: [Ilw] Re: iwlagn is getting very shaky
From: wwguy @ 2011-10-26 19:56 UTC (permalink / raw)
To: Richard Yao
Cc: Norbert Preining, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, ipw3945-devel@lists.sourceforge.net,
ilw@linux.intel.com, Pekka Enberg, David Rientjes
In-Reply-To: <CABDyM6T-_UWjQtb9E8Yie1kj5UpDHZNRTb13xJBt=YFczbwxZA@mail.gmail.com>
On Tue, 2011-10-25 at 21:54 -0700, Richard Yao wrote:
> Dear Norbert,
>
> Try doing "iwconfig wlan0 rts 0". As I said less than an hour ago in
> my rather lengthy post to the Linux mailing list, that made things
> better for me, but not perfect.
>
> Speaking of which, that post described my findings on why I was having
> wireless issues that I did not post several weeks ago because I didn't
> think anyone would care. Since people do seem to care, I probably
> should have CCed that email to everyone else that was on people's CC
> lists, but I am new to mailing lists (and to Linux), so I did not
> think of it until now.
>
yes we care, sorry to miss your email thread. please provide more
information about your issue.
Thanks
Wey
>
> On Wed, Oct 26, 2011 at 12:34 AM, Norbert Preining <preining@logic.at> wrote:
> > On Di, 25 Okt 2011, wwguy wrote:
> >> > But *I* cannot be sure about it ;-)
> >> >
> >> Are you seeing this without suspend/resume?
> >
> > Yes. I just shut down and started, and the same happens again. If you
> > need the dmesg output let me know.
> >
> > Best wishes
> >
> > Norbert
> > ------------------------------------------------------------------------
> > Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
> > JAIST, Japan TeX Live & Debian Developer
> > DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
> > ------------------------------------------------------------------------
> > RUNCORN (n.)
> > A peeble (q.v.) which is larger that a belper (q.v.)
> > --- Douglas Adams, The Meaning of Liff
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> _______________________________________________
> ilw mailing list
> ilw@linux.intel.com
> http://linux.intel.com/mailman/listinfo/ilw
^ permalink raw reply
* Re: wifi iwlagn fails to authenticate after wake from suspend
From: wwguy @ 2011-10-26 20:00 UTC (permalink / raw)
To: David Rientjes, johannes.berg
Cc: Gene Smith, ilw@linux.intel.com, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org
In-Reply-To: <alpine.DEB.2.00.1110252325090.20273@chino.kir.corp.google.com>
Johannes, any idea?
Thanks
Wey
On Tue, 2011-10-25 at 23:27 -0700, David Rientjes wrote:
> On Wed, 26 Oct 2011, Gene Smith wrote:
>
> > Now after upgrade to Ubuntu 11.10 when resume from suspend, wifi fails to
> > reconnect saying waiting for authentication. When I use older kernel, 2.4.38
> > instead of the new 3.0.0, it still works OK. If using ethernet, after wake
> > from suspend it always works OK.
> >
>
> So we need to bisect between 2.4.38 and 3.0.0? :) I'm running ubuntu
> 11.10 on a home laptop so I'll give this a try as well when I can if I can
> put up with unity for that long.
>
> > More details on this bug are here
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/880648
> > and here
> > https://bugzilla.redhat.com/show_bug.cgi?id=7374
> >
> > Tried new Ubuntu kernel 3.1-rc10 did not help. Did not try an alternate kernel
> > with Fedora 15.
> >
> > The common failure messages seen with Ubuntu and Fedora is this:
> >
> > <info> (wlan0): device state change: need-auth -> failed (reason 'no-secrets')
> > [60 120 7]
> > Oct 24 01:20:00 hplt NetworkManager[1016]: <warn> Activation (wlan0) failed
> > for access point (dbnet)
> >
> > After this occurs, no further attempt to authenticate wifi occur and a red X
> > appears over the wifi icon. I must then use ethernet (or reboot).
> >
>
> Adding wireless folks to the cc.
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Larry Finger @ 2011-10-26 21:20 UTC (permalink / raw)
To: Chiefdome; +Cc: linux-wireless
In-Reply-To: <4EA861F5.4020200@googlemail.com>
On 10/26/2011 02:39 PM, Chiefdome wrote:
> Did you tested the commands you posted to me? Anyway here they do nothing. I
> cant see any changes in iwconfig nor in in iw.
>
> iw reg get
> country 00:
> (2400 - 2494 @ 40), (N/A, 33)
> (4910 - 5895 @ 40), (N/A, 33)
>
> so after my regulatory domain I should be able to change the adapter settings.
No, I did not test them. If they don't work, then you need to debug cfg80211.
These things are not a part of the driver. It only does what it is told.
You need to set a proper regulatory domain. Yours says "country 00", which is
not right. Mine says
finger@larrylap:~> iw reg get
country US:
(2402 - 2472 @ 40), (3, 27)
(5170 - 5250 @ 40), (3, 17)
(5250 - 5330 @ 40), (3, 20), DFS
(5490 - 5600 @ 40), (3, 20), DFS
(5650 - 5710 @ 40), (3, 20), DFS
(5735 - 5835 @ 40), (3, 30)
and that 27 dBm exactly matches what iwconfig says.
Larry
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Larry Finger @ 2011-10-26 21:31 UTC (permalink / raw)
To: Chiefdome; +Cc: linux-wireless
In-Reply-To: <4EA861F5.4020200@googlemail.com>
On 10/26/2011 02:39 PM, Chiefdome wrote:
>
> Did you tested the commands you posted to me? Anyway here they do nothing. I
> cant see any changes in iwconfig nor in in iw.
>
> iw reg get
> country 00:
> (2400 - 2494 @ 40), (N/A, 33)
> (4910 - 5895 @ 40), (N/A, 33)
>
> so after my regulatory domain I should be able to change the adapter settings.
I now have tested. My device is limited to 27 dBm, thus the limit in the txpower
command is 2700, but one can reduce the power.
finger@larrylap:~/linux-2.6> iwconfig wlan25
wlan25 IEEE 802.11bg ESSID:"lwfdjf-n"
Mode:Managed Frequency:2.422 GHz Access Point: C0:3F:0E:BE:2B:44
Bit Rate=54 Mb/s Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=66/70 Signal level=-44 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:93 Invalid misc:270 Missed beacon:0
finger@larrylap:~/linux-2.6> sudo iw dev wlan25 set txpower limit 2200
finger@larrylap:~/linux-2.6> iwconfig wlan25
wlan25 IEEE 802.11bg ESSID:"lwfdjf-n"
Mode:Managed Frequency:2.422 GHz Access Point: C0:3F:0E:BE:2B:44
Bit Rate=54 Mb/s Tx-Power=22 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=68/70 Signal level=-42 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:93 Invalid misc:270 Missed beacon:0
With your regulatory info, you should be able to get 3300, unless the rtl8192cu
firmware has a limit to keep you from destroying the chip.
Perhaps you should ask Alfa about this issue.
Larry
^ permalink raw reply
* 3.1-rc9 and 3.1 wifi problem , problem continues with 3.1
From: werner @ 2011-10-26 21:47 UTC (permalink / raw)
To: linux-kernel, linux-wireless, dave.taht, rientjes, arend,
toralf.foerster, wey-yi.w.guy, ilw, larry.finger
[-- Attachment #1: Type: text/plain, Size: 5402 bytes --]
As reported, with 3.1-rc9 the wifi of a friend's laptop
didnt work at all. With 3.0.4 it's working normally.
The problem continues with 3.1
Now I take some files for identify the problem. Below see
lsmod and dmesg , and enclosed is hwinfo and syslog of
that laptop as it was running with 3.1 just as wifi didn't
work. For comparison, on syslog you can see the
previous boots (I separated them by blank lines), all with
3.0.4 , when wifi was working.
I hope that's now enough information to fix that problem.
Werner Landgraf
============= lsmod ========================
Module Size Used by
bnep 7766 2
rfcomm 25786 3
hidp 10944 2
bluetooth 120537 16 bnep,rfcomm,hidp
snd_usb_audio 67370 0
snd_usbmidi_lib 13290 1 snd_usb_audio
snd_rawmidi 12740 1 snd_usbmidi_lib
snd_seq_device 3765 1 snd_rawmidi
tpm_tis 6429 0
tpm 9267 1 tpm_tis
tpm_bios 3680 1 tpm
i2c_i801 6737 0
iTCO_wdt 9371 0
iTCO_vendor_support 1329 1 iTCO_wdt
iwlagn 175521 0
mac80211 172429 1 iwlagn
cfg80211 123540 2 iwlagn,mac80211
uvcvideo 50646 0
rtc_cmos 7122 0
snd_hda_codec_realtek 194904 1
snd_hda_intel 17064 7
snd_hda_codec 55426 2
snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 4142 2
snd_usb_audio,snd_hda_codec
snd_pcm 52489 5
snd_usb_audio,snd_hda_intel,snd_hda_codec
snd_timer 13192 3 snd_pcm
snd 36610 20
snd_usb_audio,snd_usbmidi_lib,snd_rawmidi,snd_seq_device,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
soundcore 3803 1 snd
snd_page_alloc 5101 2 snd_hda_intel,snd_pcm
================= dmesg (only last part which is visible)
===================
... plenty tests deleted ...
Testing event system raw_syscalls: OK
Running tests on all trace events:
Testing all events: OK
kmemleak: Kernel memory leak detector initialized
kmemleak: Automatic memory scanning thread started
kAFS: Red Hat AFS client v0.1 registering.
FS-Cache: Netfs 'afs' registered for caching
raid6test: testing the 4-disk case...
raid6test: test_disks(0, 1): faila= 0(D) failb= 1(D)
OK
... plenty raid tests deleted
raid6test: complete (257 tests, 0 failures)
register_blkdev: cannot get major 3 for hd
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
md: Waiting for all devices to be available before
autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
kjournald starting. Commit interval 5 seconds
EXT3-fs (sda1): mounted filesystem with ordered data mode
VFS: Mounted root (ext3 filesystem) readonly on device
8:1.
devtmpfs: mounted
Freeing unused kernel memory: 1004k freed
Write protecting the kernel text: 15588k
Write protecting the kernel read-only data: 4744k
udevd (5746): /proc/5746/oom_adj is deprecated, please use
/proc/5746/oom_score_adj instead.
snd_hda_intel 0000:00:1b.0: power state changed by ACPI to
D0
snd_hda_intel 0000:00:1b.0: power state changed by ACPI to
D0
ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 10
snd_hda_intel 0000:00:1b.0: PCI INT A -> Link[LNKF] -> GSI
10 (level, low) -> IRQ 10
snd_hda_intel 0000:00:1b.0: setting latency timer to 64
hda_codec: ALC269: BIOS auto-probing.
input: HDA Digital PCBeep as
/devices/pci0000:00/0000:00:1b.0/input/input10
input: HDA Intel Mic as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input11
input: HDA Intel Headphone as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input12
snd_hda_intel 0000:01:00.1: PCI INT B -> GSI 0 (level,
low) -> IRQ 0
hda-intel: unable to grab IRQ 0, disabling device
snd_hda_intel 0000:01:00.1: PCI INT B disabled
snd_hda_intel: probe of 0000:01:00.1 failed with error -16
rtc_cmos 00:08: RTC can wake from S4
rtc_cmos 00:08: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k, 242 bytes nvram, hpet
irqs
uvcvideo: Found UVC 1.00 device CNF8015 (04f2:b112)
input: CNF8015 as
/devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2:1.0/input/input13
usbcore: registered new interface driver uvcvideo
USB Video Class driver (1.1.1)
cfg80211: Calling CRDA to update world regulatory domain
Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:
Copyright(c) 2003-2011 Intel Corporation
iwlagn 0000:03:00.0: PCI INT A -> Link[LNKB] -> GSI 11
(level, low) -> IRQ 11
iwlagn 0000:03:00.0: setting latency timer to 64
iTCO_vendor_support: vendor-support=0
iwlagn 0000:03:00.0: pci_resource_len = 0x00002000
iwlagn 0000:03:00.0: pci_resource_base = fa07c000
iwlagn 0000:03:00.0: HW Revision ID = 0x0
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.06
iwlagn 0000:03:00.0: pci_enable_msi failed
iwlagn 0000:03:00.0: PCI INT A disabled
iTCO_wdt: Found a ICH9M TCO device (Version=2,
TCOBASE=0x0460)
iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
i801_smbus 0000:00:1f.3: PCI INT C -> Link[LNKD] -> GSI 10
(level, low) -> IRQ 10
EXT3-fs (sda1): using internal journal
usbcore: registered new interface driver snd-usb-audio
---
Professional hosting for everyone - http://www.host.ru
[-- Attachment #2: hwinfo.bz2 --]
[-- Type: application/bzip2, Size: 54865 bytes --]
[-- Attachment #3: syslog.last.bz2 --]
[-- Type: application/bzip2, Size: 13235 bytes --]
^ permalink raw reply
* [PATCH 0/5] v3 HT support for mesh
From: Thomas Pedersen @ 2011-10-26 21:47 UTC (permalink / raw)
To: linux-wireless; +Cc: devel, Thomas Pedersen, johannes, linville
This patchset adds basic HT support for mesh nodes. We avoid the question of
how to negotiate channel types, by simply disallowing peering with mismatched
HT modes.
Many thanks to Luis Rodriguez for his assistance, and Ashok Nagarajan for
co-authoring this patchset.
v2:
Remove outdated BA comments (Christian)
v3:
Guido R. Hiertz was kind enough to point out:
"IEEE 802.11s-2011 states that mesh STAs use the default EDCA parameter
set only. Clause 9.1.3.1 in 802.11s-2011 reads: "When communicating
within a BSS, the EDCA parameters used are […] from the default values
for the parameters […] when the STA is a mesh STA." Thus, all mesh STAs
use the same (default) EDCA parameter set."
So resubmitting without the WMM patches.
Alexander Simon (1):
mac80211: Add HT helper functions
Thomas Pedersen (4):
mac80211: comment allocation of mesh frames
mac80211: add HT IEs to mesh frames
mac80211: set HT capabilities for mesh peer
mac80211: allow frame aggregation for mesh
net/mac80211/agg-rx.c | 3 +-
net/mac80211/agg-tx.c | 10 +---
net/mac80211/ht.c | 3 +-
net/mac80211/ieee80211_i.h | 8 +++
net/mac80211/mesh.c | 70 +++++++++++++++++++++++---
net/mac80211/mesh.h | 4 ++
net/mac80211/mesh_hwmp.c | 36 +++++++-------
net/mac80211/mesh_plink.c | 50 ++++++++++++++-----
net/mac80211/rx.c | 7 +--
net/mac80211/tx.c | 23 ++++++--
net/mac80211/util.c | 116 +++++++++++++++++++++++++++++++++++++------
net/mac80211/work.c | 29 +-----------
12 files changed, 252 insertions(+), 107 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCH 1/5] mac80211: comment allocation of mesh frames
From: Thomas Pedersen @ 2011-10-26 21:47 UTC (permalink / raw)
To: linux-wireless; +Cc: devel, Thomas Pedersen, johannes, linville
In-Reply-To: <1319665649-21784-1-git-send-email-thomas@cozybit.com>
Remove most references to magic numbers, save a few bytes and hopefully
improve readability.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
net/mac80211/mesh_hwmp.c | 36 ++++++++++++++++++------------------
net/mac80211/mesh_plink.c | 28 +++++++++++++++++-----------
net/mac80211/tx.c | 19 +++++++++++++------
3 files changed, 48 insertions(+), 35 deletions(-)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 174040a..9a1f8bb 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -113,20 +113,20 @@ static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_local *local = sdata->local;
- struct sk_buff *skb = dev_alloc_skb(local->hw.extra_tx_headroom + 400);
+ struct sk_buff *skb;
struct ieee80211_mgmt *mgmt;
- u8 *pos;
- int ie_len;
+ u8 *pos, ie_len;
+ int hdr_len = offsetof(struct ieee80211_mgmt, u.action.u.mesh_action) +
+ sizeof(mgmt->u.action.u.mesh_action);
+ skb = dev_alloc_skb(local->hw.extra_tx_headroom +
+ hdr_len +
+ 2 + 37); /* max HWMP IE */
if (!skb)
return -1;
skb_reserve(skb, local->hw.extra_tx_headroom);
- /* 25 is the size of the common mgmt part (24) plus the size of the
- * common action part (1)
- */
- mgmt = (struct ieee80211_mgmt *)
- skb_put(skb, 25 + sizeof(mgmt->u.action.u.mesh_action));
- memset(mgmt, 0, 25 + sizeof(mgmt->u.action.u.mesh_action));
+ mgmt = (struct ieee80211_mgmt *) skb_put(skb, hdr_len);
+ memset(mgmt, 0, hdr_len);
mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
IEEE80211_STYPE_ACTION);
@@ -240,20 +240,20 @@ int mesh_path_error_tx(u8 ttl, u8 *target, __le32 target_sn,
struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_local *local = sdata->local;
- struct sk_buff *skb = dev_alloc_skb(local->hw.extra_tx_headroom + 400);
+ struct sk_buff *skb;
struct ieee80211_mgmt *mgmt;
- u8 *pos;
- int ie_len;
+ u8 *pos, ie_len;
+ int hdr_len = offsetof(struct ieee80211_mgmt, u.action.u.mesh_action) +
+ sizeof(mgmt->u.action.u.mesh_action);
+ skb = dev_alloc_skb(local->hw.extra_tx_headroom +
+ hdr_len +
+ 2 + 15 /* PERR IE */);
if (!skb)
return -1;
skb_reserve(skb, local->tx_headroom + local->hw.extra_tx_headroom);
- /* 25 is the size of the common mgmt part (24) plus the size of the
- * common action part (1)
- */
- mgmt = (struct ieee80211_mgmt *)
- skb_put(skb, 25 + sizeof(mgmt->u.action.u.mesh_action));
- memset(mgmt, 0, 25 + sizeof(mgmt->u.action.u.mesh_action));
+ mgmt = (struct ieee80211_mgmt *) skb_put(skb, hdr_len);
+ memset(mgmt, 0, hdr_len);
mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
IEEE80211_STYPE_ACTION);
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 7e57f5d..351e48c 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -153,23 +153,29 @@ static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
enum ieee80211_self_protected_actioncode action,
u8 *da, __le16 llid, __le16 plid, __le16 reason) {
struct ieee80211_local *local = sdata->local;
- struct sk_buff *skb = dev_alloc_skb(local->hw.extra_tx_headroom + 400 +
- sdata->u.mesh.ie_len);
+ struct sk_buff *skb;
struct ieee80211_mgmt *mgmt;
bool include_plid = false;
- int ie_len = 4;
u16 peering_proto = 0;
- u8 *pos;
-
+ u8 *pos, ie_len = 4;
+ int hdr_len = offsetof(struct ieee80211_mgmt, u.action.u.self_prot) +
+ sizeof(mgmt->u.action.u.self_prot);
+
+ skb = dev_alloc_skb(local->hw.extra_tx_headroom +
+ hdr_len +
+ 2 + /* capability info */
+ 2 + /* AID */
+ 2 + 8 + /* supported rates */
+ 2 + (IEEE80211_MAX_SUPP_RATES - 8) +
+ 2 + sdata->u.mesh.mesh_id_len +
+ 2 + sizeof(struct ieee80211_meshconf_ie) +
+ 2 + 8 + /* peering IE */
+ sdata->u.mesh.ie_len);
if (!skb)
return -1;
skb_reserve(skb, local->hw.extra_tx_headroom);
- /* 25 is the size of the common mgmt part (24) plus the size of the
- * common action part (1)
- */
- mgmt = (struct ieee80211_mgmt *)
- skb_put(skb, 25 + sizeof(mgmt->u.action.u.self_prot));
- memset(mgmt, 0, 25 + sizeof(mgmt->u.action.u.self_prot));
+ mgmt = (struct ieee80211_mgmt *) skb_put(skb, hdr_len);
+ memset(mgmt, 0, hdr_len);
mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
IEEE80211_STYPE_ACTION);
memcpy(mgmt->da, da, ETH_ALEN);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 48bbb96..f4dd339 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2278,22 +2278,29 @@ struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,
} else if (ieee80211_vif_is_mesh(&sdata->vif)) {
struct ieee80211_mgmt *mgmt;
u8 *pos;
+ int hdr_len = offsetof(struct ieee80211_mgmt, u.beacon) +
+ sizeof(mgmt->u.beacon);
#ifdef CONFIG_MAC80211_MESH
if (!sdata->u.mesh.mesh_id_len)
goto out;
#endif
- /* headroom, head length, tail length and maximum TIM length */
- skb = dev_alloc_skb(local->tx_headroom + 400 +
- sdata->u.mesh.ie_len);
+ skb = dev_alloc_skb(local->tx_headroom +
+ hdr_len +
+ 2 + /* NULL SSID */
+ 2 + 8 + /* supported rates */
+ 2 + 3 + /* DS params */
+ 2 + (IEEE80211_MAX_SUPP_RATES - 8) +
+ 2 + sdata->u.mesh.mesh_id_len +
+ 2 + sizeof(struct ieee80211_meshconf_ie) +
+ sdata->u.mesh.ie_len);
if (!skb)
goto out;
skb_reserve(skb, local->hw.extra_tx_headroom);
- mgmt = (struct ieee80211_mgmt *)
- skb_put(skb, 24 + sizeof(mgmt->u.beacon));
- memset(mgmt, 0, 24 + sizeof(mgmt->u.beacon));
+ mgmt = (struct ieee80211_mgmt *) skb_put(skb, hdr_len);
+ memset(mgmt, 0, hdr_len);
mgmt->frame_control =
cpu_to_le16(IEEE80211_FTYPE_MGMT | IEEE80211_STYPE_BEACON);
memset(mgmt->da, 0xff, ETH_ALEN);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/5] mac80211: Add HT helper functions
From: Thomas Pedersen @ 2011-10-26 21:47 UTC (permalink / raw)
To: linux-wireless; +Cc: devel, Alexander Simon, johannes, linville
In-Reply-To: <1319665649-21784-1-git-send-email-thomas@cozybit.com>
From: Alexander Simon <an.alexsimon@googlemail.com>
Some refactoring for IBSS HT.
Move HT info and capability IEs building code into separate functions.
Add function to get the channel type from an HT info IE.
Signed-off-by: Alexander Simon <an.alexsimon@googlemail.com>
---
net/mac80211/ieee80211_i.h | 8 +++
net/mac80211/util.c | 116 +++++++++++++++++++++++++++++++++++++------
net/mac80211/work.c | 29 +-----------
3 files changed, 108 insertions(+), 45 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 4c3d1f5..30fc9e7 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1333,6 +1333,12 @@ void ieee80211_recalc_smps(struct ieee80211_local *local);
size_t ieee80211_ie_split(const u8 *ies, size_t ielen,
const u8 *ids, int n_ids, size_t offset);
size_t ieee80211_ie_split_vendor(const u8 *ies, size_t ielen, size_t offset);
+u8 *ieee80211_ie_build_ht_cap(u8 *pos, struct ieee80211_supported_band *sband,
+ u16 cap);
+u8 *ieee80211_ie_build_ht_info(u8 *pos,
+ struct ieee80211_sta_ht_cap *ht_cap,
+ struct ieee80211_channel *channel,
+ enum nl80211_channel_type channel_type);
/* internal work items */
void ieee80211_work_init(struct ieee80211_local *local);
@@ -1361,6 +1367,8 @@ ieee80211_get_channel_mode(struct ieee80211_local *local,
bool ieee80211_set_channel_type(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
enum nl80211_channel_type chantype);
+enum nl80211_channel_type
+ieee80211_ht_info_to_channel_type(struct ieee80211_ht_info *ht_info);
#ifdef CONFIG_MAC80211_NOINLINE
#define debug_noinline noinline
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 7439d26..72b3a2e 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -811,23 +811,8 @@ int ieee80211_build_preq_ies(struct ieee80211_local *local, u8 *buffer,
offset = noffset;
}
- if (sband->ht_cap.ht_supported) {
- u16 cap = sband->ht_cap.cap;
- __le16 tmp;
-
- *pos++ = WLAN_EID_HT_CAPABILITY;
- *pos++ = sizeof(struct ieee80211_ht_cap);
- memset(pos, 0, sizeof(struct ieee80211_ht_cap));
- tmp = cpu_to_le16(cap);
- memcpy(pos, &tmp, sizeof(u16));
- pos += sizeof(u16);
- *pos++ = sband->ht_cap.ampdu_factor |
- (sband->ht_cap.ampdu_density <<
- IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
- memcpy(pos, &sband->ht_cap.mcs, sizeof(sband->ht_cap.mcs));
- pos += sizeof(sband->ht_cap.mcs);
- pos += 2 + 4 + 1; /* ext info, BF cap, antsel */
- }
+ if (sband->ht_cap.ht_supported)
+ pos = ieee80211_ie_build_ht_cap(pos, sband, sband->ht_cap.cap);
/*
* If adding more here, adjust code in main.c
@@ -1362,6 +1347,103 @@ void ieee80211_disable_rssi_reports(struct ieee80211_vif *vif)
}
EXPORT_SYMBOL(ieee80211_disable_rssi_reports);
+u8 *ieee80211_ie_build_ht_cap(u8 *pos, struct ieee80211_supported_band *sband,
+ u16 cap)
+{
+ __le16 tmp;
+
+ *pos++ = WLAN_EID_HT_CAPABILITY;
+ *pos++ = sizeof(struct ieee80211_ht_cap);
+ memset(pos, 0, sizeof(struct ieee80211_ht_cap));
+
+ /* capability flags */
+ tmp = cpu_to_le16(cap);
+ memcpy(pos, &tmp, sizeof(u16));
+ pos += sizeof(u16);
+
+ /* AMPDU parameters */
+ *pos++ = sband->ht_cap.ampdu_factor |
+ (sband->ht_cap.ampdu_density <<
+ IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
+
+ /* MCS set */
+ memcpy(pos, &sband->ht_cap.mcs, sizeof(sband->ht_cap.mcs));
+ pos += sizeof(sband->ht_cap.mcs);
+
+ /* extended capabilities */
+ pos += sizeof(__le16);
+
+ /* BF capabilities */
+ pos += sizeof(__le32);
+
+ /* antenna selection */
+ pos += sizeof(u8);
+
+ return pos;
+}
+
+u8 *ieee80211_ie_build_ht_info(u8 *pos,
+ struct ieee80211_sta_ht_cap *ht_cap,
+ struct ieee80211_channel *channel,
+ enum nl80211_channel_type channel_type)
+{
+ struct ieee80211_ht_info *ht_info;
+ /* Build HT Information */
+ *pos++ = WLAN_EID_HT_INFORMATION;
+ *pos++ = sizeof(struct ieee80211_ht_info);
+ ht_info = (struct ieee80211_ht_info *)pos;
+ ht_info->control_chan =
+ ieee80211_frequency_to_channel(channel->center_freq);
+ switch (channel_type) {
+ case NL80211_CHAN_HT40MINUS:
+ ht_info->ht_param = IEEE80211_HT_PARAM_CHA_SEC_BELOW;
+ break;
+ case NL80211_CHAN_HT40PLUS:
+ ht_info->ht_param = IEEE80211_HT_PARAM_CHA_SEC_ABOVE;
+ break;
+ case NL80211_CHAN_HT20:
+ default:
+ ht_info->ht_param = IEEE80211_HT_PARAM_CHA_SEC_NONE;
+ break;
+ }
+ if (ht_cap->cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40)
+ ht_info->ht_param |= IEEE80211_HT_PARAM_CHAN_WIDTH_ANY;
+ ht_info->operation_mode = 0x0000;
+ ht_info->stbc_param = 0x0000;
+
+ /* It seems that Basic MCS set and Supported MCS set
+ are identical for the first 10 bytes */
+ memset(&ht_info->basic_set, 0, 16);
+ memcpy(&ht_info->basic_set, &ht_cap->mcs, 10);
+
+ return pos + sizeof(struct ieee80211_ht_info);
+}
+
+enum nl80211_channel_type
+ieee80211_ht_info_to_channel_type(struct ieee80211_ht_info *ht_info)
+{
+ enum nl80211_channel_type channel_type;
+
+ if (!ht_info)
+ return NL80211_CHAN_NO_HT;
+
+ switch (ht_info->ht_param & IEEE80211_HT_PARAM_CHA_SEC_OFFSET) {
+ case IEEE80211_HT_PARAM_CHA_SEC_NONE:
+ channel_type = NL80211_CHAN_HT20;
+ break;
+ case IEEE80211_HT_PARAM_CHA_SEC_ABOVE:
+ channel_type = NL80211_CHAN_HT40PLUS;
+ break;
+ case IEEE80211_HT_PARAM_CHA_SEC_BELOW:
+ channel_type = NL80211_CHAN_HT40MINUS;
+ break;
+ default:
+ channel_type = NL80211_CHAN_NO_HT;
+ }
+
+ return channel_type;
+}
+
int ieee80211_add_srates_ie(struct ieee80211_vif *vif, struct sk_buff *skb)
{
struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index 94472eb..fab5092 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -103,7 +103,6 @@ static void ieee80211_add_ht_ie(struct sk_buff *skb, const u8 *ht_info_ie,
u8 *pos;
u32 flags = channel->flags;
u16 cap = sband->ht_cap.cap;
- __le16 tmp;
if (!sband->ht_cap.ht_supported)
return;
@@ -154,34 +153,8 @@ static void ieee80211_add_ht_ie(struct sk_buff *skb, const u8 *ht_info_ie,
}
/* reserve and fill IE */
-
pos = skb_put(skb, sizeof(struct ieee80211_ht_cap) + 2);
- *pos++ = WLAN_EID_HT_CAPABILITY;
- *pos++ = sizeof(struct ieee80211_ht_cap);
- memset(pos, 0, sizeof(struct ieee80211_ht_cap));
-
- /* capability flags */
- tmp = cpu_to_le16(cap);
- memcpy(pos, &tmp, sizeof(u16));
- pos += sizeof(u16);
-
- /* AMPDU parameters */
- *pos++ = sband->ht_cap.ampdu_factor |
- (sband->ht_cap.ampdu_density <<
- IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
-
- /* MCS set */
- memcpy(pos, &sband->ht_cap.mcs, sizeof(sband->ht_cap.mcs));
- pos += sizeof(sband->ht_cap.mcs);
-
- /* extended capabilities */
- pos += sizeof(__le16);
-
- /* BF capabilities */
- pos += sizeof(__le32);
-
- /* antenna selection */
- pos += sizeof(u8);
+ ieee80211_ie_build_ht_cap(pos, sband, cap);
}
static void ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata,
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/5] mac80211: add HT IEs to mesh frames
From: Thomas Pedersen @ 2011-10-26 21:47 UTC (permalink / raw)
To: linux-wireless; +Cc: devel, Thomas Pedersen, johannes, linville
In-Reply-To: <1319665649-21784-1-git-send-email-thomas@cozybit.com>
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Ashok Nagarajan <anagar6@uic.edu>
---
net/mac80211/mesh.c | 43 +++++++++++++++++++++++++++++++++++++++++++
net/mac80211/mesh.h | 4 ++++
net/mac80211/mesh_plink.c | 9 +++++++++
net/mac80211/tx.c | 4 ++++
4 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index a7078fd..2dc76a9 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -341,6 +341,49 @@ int mesh_add_ds_params_ie(struct sk_buff *skb,
return 0;
}
+int mesh_add_ht_cap_ie(struct sk_buff *skb,
+ struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_local *local = sdata->local;
+ struct ieee80211_supported_band *sband;
+ u8 *pos;
+
+ sband = local->hw.wiphy->bands[local->oper_channel->band];
+ if (!sband->ht_cap.ht_supported ||
+ local->_oper_channel_type == NL80211_CHAN_NO_HT)
+ return 0;
+
+ if (skb_tailroom(skb) < 2 + sizeof(struct ieee80211_ht_cap))
+ return -ENOMEM;
+
+ pos = skb_put(skb, 2 + sizeof(struct ieee80211_ht_cap));
+ ieee80211_ie_build_ht_cap(pos, sband, sband->ht_cap.cap);
+
+ return 0;
+}
+
+int mesh_add_ht_info_ie(struct sk_buff *skb,
+ struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_local *local = sdata->local;
+ struct ieee80211_channel *channel = local->oper_channel;
+ enum nl80211_channel_type channel_type = local->_oper_channel_type;
+ struct ieee80211_supported_band *sband =
+ local->hw.wiphy->bands[channel->band];
+ struct ieee80211_sta_ht_cap *ht_cap = &sband->ht_cap;
+ u8 *pos;
+
+ if (!ht_cap->ht_supported || channel_type == NL80211_CHAN_NO_HT)
+ return 0;
+
+ if (skb_tailroom(skb) < 2 + sizeof(struct ieee80211_ht_info))
+ return -ENOMEM;
+
+ pos = skb_put(skb, 2 + sizeof(struct ieee80211_ht_info));
+ ieee80211_ie_build_ht_info(pos, ht_cap, channel, channel_type);
+
+ return 0;
+}
static void ieee80211_mesh_path_timer(unsigned long data)
{
struct ieee80211_sub_if_data *sdata =
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h
index 8c00e2d..0f2c4e6 100644
--- a/net/mac80211/mesh.h
+++ b/net/mac80211/mesh.h
@@ -212,6 +212,10 @@ int mesh_add_vendor_ies(struct sk_buff *skb,
struct ieee80211_sub_if_data *sdata);
int mesh_add_ds_params_ie(struct sk_buff *skb,
struct ieee80211_sub_if_data *sdata);
+int mesh_add_ht_cap_ie(struct sk_buff *skb,
+ struct ieee80211_sub_if_data *sdata);
+int mesh_add_ht_info_ie(struct sk_buff *skb,
+ struct ieee80211_sub_if_data *sdata);
void mesh_rmc_free(struct ieee80211_sub_if_data *sdata);
int mesh_rmc_init(struct ieee80211_sub_if_data *sdata);
void ieee80211s_init(void);
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 351e48c..986af8a 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -169,6 +169,8 @@ static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
2 + (IEEE80211_MAX_SUPP_RATES - 8) +
2 + sdata->u.mesh.mesh_id_len +
2 + sizeof(struct ieee80211_meshconf_ie) +
+ 2 + sizeof(struct ieee80211_ht_cap) +
+ 2 + sizeof(struct ieee80211_ht_info) +
2 + 8 + /* peering IE */
sdata->u.mesh.ie_len);
if (!skb)
@@ -241,6 +243,13 @@ static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
memcpy(pos, &reason, 2);
pos += 2;
}
+
+ if (action != WLAN_SP_MESH_PEERING_CLOSE) {
+ if (mesh_add_ht_cap_ie(skb, sdata) ||
+ mesh_add_ht_info_ie(skb, sdata))
+ return -1;
+ }
+
if (mesh_add_vendor_ies(skb, sdata))
return -1;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index f4dd339..a543d26 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2292,6 +2292,8 @@ struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,
2 + 8 + /* supported rates */
2 + 3 + /* DS params */
2 + (IEEE80211_MAX_SUPP_RATES - 8) +
+ 2 + sizeof(struct ieee80211_ht_cap) +
+ 2 + sizeof(struct ieee80211_ht_info) +
2 + sdata->u.mesh.mesh_id_len +
2 + sizeof(struct ieee80211_meshconf_ie) +
sdata->u.mesh.ie_len);
@@ -2319,6 +2321,8 @@ struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,
mesh_add_ds_params_ie(skb, sdata) ||
ieee80211_add_ext_srates_ie(&sdata->vif, skb) ||
mesh_add_rsn_ie(skb, sdata) ||
+ mesh_add_ht_cap_ie(skb, sdata) ||
+ mesh_add_ht_info_ie(skb, sdata) ||
mesh_add_meshid_ie(skb, sdata) ||
mesh_add_meshconf_ie(skb, sdata) ||
mesh_add_vendor_ies(skb, sdata)) {
--
1.7.5.4
^ permalink raw reply related
* [PATCH 4/5] mac80211: set HT capabilities for mesh peer
From: Thomas Pedersen @ 2011-10-26 21:47 UTC (permalink / raw)
To: linux-wireless; +Cc: devel, Thomas Pedersen, johannes, linville
In-Reply-To: <1319665649-21784-1-git-send-email-thomas@cozybit.com>
Set peer's HT capabilities, and disallow peering if we're on a different
channel type.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Ashok Nagarajan <anagar6@uic.edu>
---
net/mac80211/mesh.c | 25 +++++++++++++++++--------
net/mac80211/mesh_plink.c | 13 ++++++++++---
2 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 2dc76a9..b3a125f 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -76,6 +76,7 @@ static void ieee80211_mesh_housekeeping_timer(unsigned long data)
bool mesh_matches_local(struct ieee802_11_elems *ie, struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct ieee80211_local *local = sdata->local;
/*
* As support for each feature is added, check for matching
@@ -87,15 +88,23 @@ bool mesh_matches_local(struct ieee802_11_elems *ie, struct ieee80211_sub_if_dat
* - MDA enabled
* - Power management control on fc
*/
- if (ifmsh->mesh_id_len == ie->mesh_id_len &&
- memcmp(ifmsh->mesh_id, ie->mesh_id, ie->mesh_id_len) == 0 &&
- (ifmsh->mesh_pp_id == ie->mesh_config->meshconf_psel) &&
- (ifmsh->mesh_pm_id == ie->mesh_config->meshconf_pmetric) &&
- (ifmsh->mesh_cc_id == ie->mesh_config->meshconf_congest) &&
- (ifmsh->mesh_sp_id == ie->mesh_config->meshconf_synch) &&
- (ifmsh->mesh_auth_id == ie->mesh_config->meshconf_auth))
- return true;
-
+ if (!(ifmsh->mesh_id_len == ie->mesh_id_len &&
+ memcmp(ifmsh->mesh_id, ie->mesh_id, ie->mesh_id_len) == 0 &&
+ (ifmsh->mesh_pp_id == ie->mesh_config->meshconf_psel) &&
+ (ifmsh->mesh_pm_id == ie->mesh_config->meshconf_pmetric) &&
+ (ifmsh->mesh_cc_id == ie->mesh_config->meshconf_congest) &&
+ (ifmsh->mesh_sp_id == ie->mesh_config->meshconf_synch) &&
+ (ifmsh->mesh_auth_id == ie->mesh_config->meshconf_auth)))
+ goto mismatch;
+
+ /* disallow peering with mismatched channel types for now */
+ if (ie->ht_info_elem &&
+ (local->_oper_channel_type !=
+ ieee80211_ht_info_to_channel_type(ie->ht_info_elem)))
+ goto mismatch;
+
+ return true;
+mismatch:
return false;
}
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 986af8a..0140e88 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -80,11 +80,15 @@ static inline void mesh_plink_fsm_restart(struct sta_info *sta)
* on it in the lifecycle management section!
*/
static struct sta_info *mesh_plink_alloc(struct ieee80211_sub_if_data *sdata,
- u8 *hw_addr, u32 rates)
+ u8 *hw_addr, u32 rates,
+ struct ieee802_11_elems *elems)
{
struct ieee80211_local *local = sdata->local;
+ struct ieee80211_supported_band *sband;
struct sta_info *sta;
+ sband = local->hw.wiphy->bands[local->oper_channel->band];
+
if (local->num_sta >= MESH_MAX_PLINKS)
return NULL;
@@ -96,6 +100,9 @@ static struct sta_info *mesh_plink_alloc(struct ieee80211_sub_if_data *sdata,
set_sta_flag(sta, WLAN_STA_AUTHORIZED);
set_sta_flag(sta, WLAN_STA_WME);
sta->sta.supp_rates[local->hw.conf.channel->band] = rates;
+ if (elems->ht_cap_elem)
+ ieee80211_ht_cap_ie_to_sta_ht_cap(sband, elems->ht_cap_elem,
+ &sta->sta.ht_cap);
rate_control_rate_init(sta);
return sta;
@@ -276,7 +283,7 @@ void mesh_neighbour_update(u8 *hw_addr, u32 rates,
elems->ie_start, elems->total_len,
GFP_KERNEL);
else
- sta = mesh_plink_alloc(sdata, hw_addr, rates);
+ sta = mesh_plink_alloc(sdata, hw_addr, rates, elems);
if (!sta)
return;
if (sta_info_insert_rcu(sta)) {
@@ -567,7 +574,7 @@ void mesh_rx_plink_frame(struct ieee80211_sub_if_data *sdata, struct ieee80211_m
}
rates = ieee80211_sta_get_rates(local, &elems, rx_status->band);
- sta = mesh_plink_alloc(sdata, mgmt->sa, rates);
+ sta = mesh_plink_alloc(sdata, mgmt->sa, rates, &elems);
if (!sta) {
mpl_dbg("Mesh plink error: plink table full\n");
return;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 5/5] mac80211: allow frame aggregation for mesh
From: Thomas Pedersen @ 2011-10-26 21:47 UTC (permalink / raw)
To: linux-wireless; +Cc: devel, Thomas Pedersen, johannes, linville
In-Reply-To: <1319665649-21784-1-git-send-email-thomas@cozybit.com>
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Ashok Nagarajan <anagar6@uic.edu>
v2:
Remove outdated comments (Christian)
---
net/mac80211/agg-rx.c | 3 ++-
net/mac80211/agg-tx.c | 10 +++-------
net/mac80211/ht.c | 3 ++-
net/mac80211/rx.c | 7 +------
4 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 0cde8df..e8af4b0 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -176,7 +176,8 @@ static void ieee80211_send_addba_resp(struct ieee80211_sub_if_data *sdata, u8 *d
memcpy(mgmt->da, da, ETH_ALEN);
memcpy(mgmt->sa, sdata->vif.addr, ETH_ALEN);
if (sdata->vif.type == NL80211_IFTYPE_AP ||
- sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+ sdata->vif.type == NL80211_IFTYPE_MESH_POINT)
memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
else if (sdata->vif.type == NL80211_IFTYPE_STATION)
memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index 2ac0339..fefc7e5 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -77,7 +77,8 @@ static void ieee80211_send_addba_request(struct ieee80211_sub_if_data *sdata,
memcpy(mgmt->da, da, ETH_ALEN);
memcpy(mgmt->sa, sdata->vif.addr, ETH_ALEN);
if (sdata->vif.type == NL80211_IFTYPE_AP ||
- sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+ sdata->vif.type == NL80211_IFTYPE_MESH_POINT)
memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
else if (sdata->vif.type == NL80211_IFTYPE_STATION)
memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
@@ -371,13 +372,8 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
pubsta->addr, tid);
#endif /* CONFIG_MAC80211_HT_DEBUG */
- /*
- * The aggregation code is not prepared to handle
- * anything but STA/AP due to the BSSID handling.
- * IBSS could work in the code but isn't supported
- * by drivers or the standard.
- */
if (sdata->vif.type != NL80211_IFTYPE_STATION &&
+ sdata->vif.type != NL80211_IFTYPE_MESH_POINT &&
sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
sdata->vif.type != NL80211_IFTYPE_AP)
return -EINVAL;
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index f80a35c..988c7ec 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -195,7 +195,8 @@ void ieee80211_send_delba(struct ieee80211_sub_if_data *sdata,
memcpy(mgmt->da, da, ETH_ALEN);
memcpy(mgmt->sa, sdata->vif.addr, ETH_ALEN);
if (sdata->vif.type == NL80211_IFTYPE_AP ||
- sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+ sdata->vif.type == NL80211_IFTYPE_MESH_POINT)
memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
else if (sdata->vif.type == NL80211_IFTYPE_STATION)
memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index b867bd5..77d3881 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2203,13 +2203,8 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
switch (mgmt->u.action.category) {
case WLAN_CATEGORY_BACK:
- /*
- * The aggregation code is not prepared to handle
- * anything but STA/AP due to the BSSID handling;
- * IBSS could work in the code but isn't supported
- * by drivers or the standard.
- */
if (sdata->vif.type != NL80211_IFTYPE_STATION &&
+ sdata->vif.type != NL80211_IFTYPE_MESH_POINT &&
sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
sdata->vif.type != NL80211_IFTYPE_AP)
break;
--
1.7.5.4
^ permalink raw reply related
* Re: 3.1-rc9 and 3.1 wifi problem , problem continues with 3.1
From: Guy, Wey-Yi @ 2011-10-26 21:11 UTC (permalink / raw)
To: werner
Cc: linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
dave.taht@gmail.com, rientjes@google.com, arend@broadcom.com,
toralf.foerster@gmx.de, ilw@linux.intel.com,
larry.finger@gmail.com
In-Reply-To: <web-633781994@zbackend1.aha.ru>
On Wed, 2011-10-26 at 14:47 -0700, werner wrote:
> As reported, with 3.1-rc9 the wifi of a friend's laptop
> didnt work at all. With 3.0.4 it's working normally.
>
> The problem continues with 3.1
>
> Now I take some files for identify the problem. Below see
> lsmod and dmesg , and enclosed is hwinfo and syslog of
> that laptop as it was running with 3.1 just as wifi didn't
> work. For comparison, on syslog you can see the
> previous boots (I separated them by blank lines), all with
> 3.0.4 , when wifi was working.
>
> I hope that's now enough information to fix that problem.
>
> The driver fail to enable msi, here is in the syslog
"Oct 26 11:39:29 darkstar kernel: hda-intel: unable to grab IRQ 0,
disabling device
Oct 26 11:39:29 darkstar kernel: snd_hda_intel: probe of 0000:01:00.1
failed with error -16
Oct 26 11:39:29 darkstar kernel: iwlagn 0000:03:00.0: pci_enable_msi
failed
"
Thanks
Wey
>
>
> ============= lsmod ========================
> Module Size Used by
> bnep 7766 2
> rfcomm 25786 3
> hidp 10944 2
> bluetooth 120537 16 bnep,rfcomm,hidp
> snd_usb_audio 67370 0
> snd_usbmidi_lib 13290 1 snd_usb_audio
> snd_rawmidi 12740 1 snd_usbmidi_lib
> snd_seq_device 3765 1 snd_rawmidi
> tpm_tis 6429 0
> tpm 9267 1 tpm_tis
> tpm_bios 3680 1 tpm
> i2c_i801 6737 0
> iTCO_wdt 9371 0
> iTCO_vendor_support 1329 1 iTCO_wdt
> iwlagn 175521 0
> mac80211 172429 1 iwlagn
> cfg80211 123540 2 iwlagn,mac80211
> uvcvideo 50646 0
> rtc_cmos 7122 0
> snd_hda_codec_realtek 194904 1
> snd_hda_intel 17064 7
> snd_hda_codec 55426 2
> snd_hda_codec_realtek,snd_hda_intel
> snd_hwdep 4142 2
> snd_usb_audio,snd_hda_codec
> snd_pcm 52489 5
> snd_usb_audio,snd_hda_intel,snd_hda_codec
> snd_timer 13192 3 snd_pcm
> snd 36610 20
> snd_usb_audio,snd_usbmidi_lib,snd_rawmidi,snd_seq_device,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
> soundcore 3803 1 snd
> snd_page_alloc 5101 2 snd_hda_intel,snd_pcm
>
>
>
> ================= dmesg (only last part which is visible)
> ===================
> ... plenty tests deleted ...
>
> Testing event system raw_syscalls: OK
> Running tests on all trace events:
> Testing all events: OK
> kmemleak: Kernel memory leak detector initialized
> kmemleak: Automatic memory scanning thread started
> kAFS: Red Hat AFS client v0.1 registering.
> FS-Cache: Netfs 'afs' registered for caching
> raid6test: testing the 4-disk case...
> raid6test: test_disks(0, 1): faila= 0(D) failb= 1(D)
> OK
>
> ... plenty raid tests deleted
>
> raid6test: complete (257 tests, 0 failures)
> register_blkdev: cannot get major 3 for hd
> drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
> md: Waiting for all devices to be available before
> autodetect
> md: If you don't use raid, use raid=noautodetect
> md: Autodetecting RAID arrays.
> md: Scanned 0 and added 0 devices.
> md: autorun ...
> md: ... autorun DONE.
> kjournald starting. Commit interval 5 seconds
> EXT3-fs (sda1): mounted filesystem with ordered data mode
> VFS: Mounted root (ext3 filesystem) readonly on device
> 8:1.
> devtmpfs: mounted
> Freeing unused kernel memory: 1004k freed
> Write protecting the kernel text: 15588k
> Write protecting the kernel read-only data: 4744k
> udevd (5746): /proc/5746/oom_adj is deprecated, please use
> /proc/5746/oom_score_adj instead.
> snd_hda_intel 0000:00:1b.0: power state changed by ACPI to
> D0
> snd_hda_intel 0000:00:1b.0: power state changed by ACPI to
> D0
> ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 10
> snd_hda_intel 0000:00:1b.0: PCI INT A -> Link[LNKF] -> GSI
> 10 (level, low) -> IRQ 10
> snd_hda_intel 0000:00:1b.0: setting latency timer to 64
> hda_codec: ALC269: BIOS auto-probing.
> input: HDA Digital PCBeep as
> /devices/pci0000:00/0000:00:1b.0/input/input10
> input: HDA Intel Mic as
> /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
> input: HDA Intel Headphone as
> /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
> snd_hda_intel 0000:01:00.1: PCI INT B -> GSI 0 (level,
> low) -> IRQ 0
> hda-intel: unable to grab IRQ 0, disabling device
> snd_hda_intel 0000:01:00.1: PCI INT B disabled
> snd_hda_intel: probe of 0000:01:00.1 failed with error -16
> rtc_cmos 00:08: RTC can wake from S4
> rtc_cmos 00:08: rtc core: registered rtc_cmos as rtc0
> rtc0: alarms up to one month, y3k, 242 bytes nvram, hpet
> irqs
> uvcvideo: Found UVC 1.00 device CNF8015 (04f2:b112)
> input: CNF8015 as
> /devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2:1.0/input/input13
> usbcore: registered new interface driver uvcvideo
> USB Video Class driver (1.1.1)
> cfg80211: Calling CRDA to update world regulatory domain
> Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:
> Copyright(c) 2003-2011 Intel Corporation
> iwlagn 0000:03:00.0: PCI INT A -> Link[LNKB] -> GSI 11
> (level, low) -> IRQ 11
> iwlagn 0000:03:00.0: setting latency timer to 64
> iTCO_vendor_support: vendor-support=0
> iwlagn 0000:03:00.0: pci_resource_len = 0x00002000
> iwlagn 0000:03:00.0: pci_resource_base = fa07c000
> iwlagn 0000:03:00.0: HW Revision ID = 0x0
> iTCO_wdt: Intel TCO WatchDog Timer Driver v1.06
> iwlagn 0000:03:00.0: pci_enable_msi failed
> iwlagn 0000:03:00.0: PCI INT A disabled
> iTCO_wdt: Found a ICH9M TCO device (Version=2,
> TCOBASE=0x0460)
> iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
> i801_smbus 0000:00:1f.3: PCI INT C -> Link[LNKD] -> GSI 10
> (level, low) -> IRQ 10
> EXT3-fs (sda1): using internal journal
> usbcore: registered new interface driver snd-usb-audio
> ---
> Professional hosting for everyone - http://www.host.ru
^ permalink raw reply
* Switching ssb to read 8-bit quantities from SPROM
From: Larry Finger @ 2011-10-26 22:24 UTC (permalink / raw)
To: Michael Buesch, Rafał Miłecki; +Cc: b43-dev, wireless
I tested the effects of changing ssb to read the SSPROM in 8-bit hunks rather
than as 16-bit words in the manner that was just submitted for brcmsmac.
Although this simplifies the calculation of the crc8, it only reduced the size
of the module by 31 bytes, thus I will not be submitting the patch.
When the library version of the crc8 routine was used rather than the one built
into ssb, the size of the driver was increased by 17 bytes.
Larry
^ permalink raw reply
* Re: 3.1-rc9 and 3.1 wifi problem , problem continues with 3.1
From: wwguy @ 2011-10-26 22:21 UTC (permalink / raw)
To: werner
Cc: linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
dave.taht@gmail.com, rientjes@google.com, arend@broadcom.com,
toralf.foerster@gmx.de, ilw@linux.intel.com,
larry.finger@gmail.com
In-Reply-To: <web-633781994@zbackend1.aha.ru>
[-- Attachment #1: Type: text/plain, Size: 667 bytes --]
On Wed, 2011-10-26 at 14:47 -0700, werner wrote:
> As reported, with 3.1-rc9 the wifi of a friend's laptop
> didnt work at all. With 3.0.4 it's working normally.
>
> The problem continues with 3.1
>
> Now I take some files for identify the problem. Below see
> lsmod and dmesg , and enclosed is hwinfo and syslog of
> that laptop as it was running with 3.1 just as wifi didn't
> work. For comparison, on syslog you can see the
> previous boots (I separated them by blank lines), all with
> 3.0.4 , when wifi was working.
>
> I hope that's now enough information to fix that problem.
>
>
> Werner Landgraf
could you try this test patch
Thanks
Wey
[-- Attachment #2: 0001-iwlwifi-allow-pci_enable_msi-fail.patch --]
[-- Type: text/x-patch, Size: 1126 bytes --]
>From 64a1b22cc9d179d69c66b23619691ba2a13ee646 Mon Sep 17 00:00:00 2001
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Wed, 26 Oct 2011 15:15:38 -0700
Subject: [PATCH 1/1] iwlwifi: allow pci_enable_msi fail
Continue the init process even fail to enable msi
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-pci.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-pci.c b/drivers/net/wireless/iwlwifi/iwl-pci.c
index 35d4551..911186f 100644
--- a/drivers/net/wireless/iwlwifi/iwl-pci.c
+++ b/drivers/net/wireless/iwlwifi/iwl-pci.c
@@ -429,10 +429,9 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_write_config_byte(pdev, PCI_CFG_RETRY_TIMEOUT, 0x00);
err = pci_enable_msi(pdev);
- if (err) {
- dev_printk(KERN_ERR, &pdev->dev, "pci_enable_msi failed");
- goto out_iounmap;
- }
+ if (err)
+ dev_printk(KERN_ERR, &pdev->dev,
+ "pci_enable_msi failed(0X%x)", err);
/* TODO: Move this away, not needed if not MSI */
/* enable rfkill interrupt: hw bug w/a */
--
1.7.0.4
^ permalink raw reply related
* RTL8188RU no injection?
From: Roman Proud @ 2011-10-26 22:29 UTC (permalink / raw)
To: linux-wireless
Hi there,
i hope you guys can help me.
I wanted a new Wifi card, because mine has no injection, what i need sometimes.
So i forced the Internet to find that a 8187 would be best for. So i
bought the 8188 (newer = better?)... i never had thought about so much
difference in just one number... it was horrible to even get the card
work, first no monitor mode works, but now it does (i dunno why
O_o)... The only thing i miss is Package injection.
So my Question. Is it there? is it in the driver and i just have to do
some magic again like i did with the monitor mode?
If not, is there any Patch? (i didn't find anything...)
Or should i simply send the damn thing back and get me an 8187? (its
not that simple, and i like hacking into my linux, so one of the first
both, would be nicer)
Greetings
Roman
^ permalink raw reply
* Re: RTL8188RU no injection?
From: Larry Finger @ 2011-10-26 23:23 UTC (permalink / raw)
To: Roman Proud; +Cc: linux-wireless
In-Reply-To: <CAF7qGM4BL10gn2786kW73sAk8f-y8CzX0rx2BQsY_Q96W=pfog@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]
On 10/26/2011 05:29 PM, Roman Proud wrote:
> Hi there,
>
> i hope you guys can help me.
> I wanted a new Wifi card, because mine has no injection, what i need sometimes.
>
> So i forced the Internet to find that a 8187 would be best for. So i
> bought the 8188 (newer = better?)... i never had thought about so much
> difference in just one number... it was horrible to even get the card
> work, first no monitor mode works, but now it does (i dunno why
> O_o)... The only thing i miss is Package injection.
Well, your research should have shown that the 8187 chip is an 802.11g version,
while the 8188 works with 802.11n. That should have given you a clue that the
driver would be VERY different.
> So my Question. Is it there? is it in the driver and i just have to do
> some magic again like i did with the monitor mode?
> If not, is there any Patch? (i didn't find anything...)
> Or should i simply send the damn thing back and get me an 8187? (its
> not that simple, and i like hacking into my linux, so one of the first
> both, would be nicer)
What kernel are you using? If you want the latest version of wireless code, you
should be running the version found in the git repo at
git://git.infradead.org/users/linville/wireless-next.git. Your next-best option
would be to get the bleeding-edge version of compat-wireless and build it for
your current kernel.
There is a bug in rtlwifi that affects monitor mode in rtl8192cu, rtl8192ce,
rtl8192se, and rtl8192de. I think it is fixed by the attached patch. At least
monitor mode works here after the patch is applied. Please let me know if it
works for you.
Larry
[-- Attachment #2: rtl8192cu_monitor --]
[-- Type: text/plain, Size: 1489 bytes --]
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/core.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/core.c
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/core.c
@@ -375,6 +375,7 @@ static void rtl_op_configure_filter(stru
rtlpriv->cfg->maps[MAC_RCR_AB]);
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_LOUD,
("Disable receive multicast frame.\n"));
+ *new_flags |= FIF_ALLMULTI;
}
}
@@ -387,6 +388,7 @@ static void rtl_op_configure_filter(stru
mac->rx_conf &= ~rtlpriv->cfg->maps[MAC_RCR_ACRC32];
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_LOUD,
("Disable receive FCS error frame.\n"));
+ *new_flags |= FIF_FCSFAIL;
}
}
@@ -400,6 +402,7 @@ static void rtl_op_configure_filter(stru
rtlpriv->cfg->ops->set_chk_bssid(hw, false);
} else {
rtlpriv->cfg->ops->set_chk_bssid(hw, true);
+ *new_flags |= FIF_BCN_PRBRESP_PROMISC;
}
}
}
@@ -414,6 +417,7 @@ static void rtl_op_configure_filter(stru
mac->rx_conf &= ~rtlpriv->cfg->maps[MAC_RCR_ACF];
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_LOUD,
("Disable receive control frame.\n"));
+ *new_flags |= FIF_CONTROL;
}
}
@@ -426,6 +430,7 @@ static void rtl_op_configure_filter(stru
mac->rx_conf &= ~rtlpriv->cfg->maps[MAC_RCR_AAP];
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_LOUD,
("Disable receive other BSS's frame.\n"));
+ *new_flags |= FIF_OTHER_BSS;
}
}
}
^ permalink raw reply
* Re: RTL8188RU no injection?
From: Larry Finger @ 2011-10-26 23:30 UTC (permalink / raw)
To: Roman Proud; +Cc: linux-wireless
In-Reply-To: <CAF7qGM4BL10gn2786kW73sAk8f-y8CzX0rx2BQsY_Q96W=pfog@mail.gmail.com>
On 10/26/2011 05:29 PM, Roman Proud wrote:
Forget the patch I just sent. Monitor mode works with the standard
wireless-testing kernel.
How do you do Package Injection? Is that done through mac80211?
Larry
^ permalink raw reply
* Re: RTL8188RU no injection?
From: Larry Finger @ 2011-10-26 23:45 UTC (permalink / raw)
To: Roman Proud; +Cc: linux-wireless
In-Reply-To: <CAF7qGM4BL10gn2786kW73sAk8f-y8CzX0rx2BQsY_Q96W=pfog@mail.gmail.com>
On 10/26/2011 05:29 PM, Roman Proud wrote:
> Hi there,
>
> i hope you guys can help me.
> I wanted a new Wifi card, because mine has no injection, what i need sometimes.
>
> So i forced the Internet to find that a 8187 would be best for. So i
> bought the 8188 (newer = better?)... i never had thought about so much
> difference in just one number... it was horrible to even get the card
> work, first no monitor mode works, but now it does (i dunno why
> O_o)... The only thing i miss is Package injection.
>
> So my Question. Is it there? is it in the driver and i just have to do
> some magic again like i did with the monitor mode?
> If not, is there any Patch? (i didn't find anything...)
> Or should i simply send the damn thing back and get me an 8187? (its
> not that simple, and i like hacking into my linux, so one of the first
> both, would be nicer)
I found that packetspammer works just fine with rtl8192cu.
Larry
^ permalink raw reply
* Fwd: iwlagn is getting very shaky
From: Richard Yao @ 2011-10-27 0:05 UTC (permalink / raw)
To: wey-yi.w.guy
Cc: Norbert Preining, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, ipw3945-devel@lists.sourceforge.net,
ilw@linux.intel.com, Pekka Enberg, David Rientjes
In-Reply-To: <CABDyM6S9XK64n374AKCu5YUq4PBAmaB0jCgE9+snnM9XeQo1yg@mail.gmail.com>
Dear Wey,
Here is the message that I sent earlier.
Yours truly,
Richard Yao
---------- Forwarded message ----------
From: Richard Yao <ryao@cs.stonybrook.edu>
Date: Wed, Oct 26, 2011 at 12:19 AM
Subject: Re: iwlagn is getting very shaky
To: linux-kernel@vger.kernel.org
Cc: preining@logic.at
Dear Everyone,
I have always had issues with Wi-Fi at my university, although they
became particularly acute. The problem is characterized by an
inordinate number of Tx excessive retries like what Norbert posted. I
had been holding off on reporting this out of fear that my report
wouldn't be good enough, but now that I see Norbert reported it, I
thought I would contribute my findings.
When I looked into this, I found that the wireless spectrum on my
university is absurdly crowded. "iwlist wlan0 scan" reveals roughly
100 access points at any given time, many of which have the same SSID.
It is worst in the library, which probably one of the most densely
populated buildings. This appears to be linked to the hidden node
problem:
http://en.wikipedia.org/wiki/Hidden_node_problem
I found a few issues in the wireless stack that appear to exacerbate
this problem. The first of which is a kernel problem. The iwlagn
driver does not support "auto" for the rts and frag settings, so they
default to off. I tried fiddling with various settings, but the only
one that seems to make a difference is rts, which at the moment I have
set to 0, which should turn it on and transmit a request to send for
all traffic. I configured my laptop to set rts to 0 on boot and the
results were remarkable. I went from having to wait 30 minutes to an
hour to get a connection that would only last for 2 minutes if I was
lucky to being able to obtain a relatively stable connection within a
few minutes.
I also encountered another kernel issue, but I haven't seen it in a
while. That issue was characterized by "iwlagn 0000:03:00.0: Stopping
AGG while state not ON or starting". After that went into the dmesg
output, it looked like I was transmitting, but I never saw a single
response from the outside world until I did "modprobe -r iwlagn &&
modprobe iwlagn". I believe that this issue was present in kernel
3.1.0-rc4, but I could be off by an rc or two. It normally occurred
within 5 to 15 mnutes and only occurred if I had passed 11n_disable=1
to the kernel module. I don't pass that anymore, so I don't know if it
is still a problem.
With that said, I discovered issues in other areas of the wireless
stack. One is that Network Manager has a 25-second hard-coded timeout
(in nm-device-wifi.c) when controlling WPA Supplicant. Ignoring the
hard-coded part, having the time-out isn't so bad until you consider
that WPA Supplicant will enter an infinite retry loop whenever Network
Manager asks it to try connecting to an access point that is either
malfunctioning or cannot hear your wireless NIC. Furthermore, if you
are in an area where multiple access points use the same SSID, WPA
supplicant will try to connect to each one with its own 9 second
timeout, so Network Manager will kill it before it has gone through
the entire list. I don't know if the 9 second timeout is hard coded,
but the kernel lists 3 direct probe attempts in the dmesg output and
if all 3 fail, WPA Supplicant will wait precisely 9 seconds (from the
first one) before it tries something else. I imgaine that if someone
patched the stack to implements some callbacks, things would become
much better when they don't work the first time. With that said, WPA
Supplicant needs a callback from the kernel when association fails and
either WPA Supplicant, Network Manager or both need to be patched so
that WPA Supplicant will not enter an infinite retry loop and instead
it will give Network Manager a failure callback so that it can try
something else.
This might be the wrong mailing list to discuss issues that reside
entirely in userland, but since I described a few other issues that
were sort of a mix of both, I think I will throw in the other two that
I found for completeness. With that said, another issue that sometimes
happens is that the kernel loses the wireless access point
association. If I do this manually, I can just use iwconfig to make
the kerenl reassociate, but if that happens with Network Manager, it
kills the entire connection and starts from scratch. This leads us to
the last issue I identified, which is that dhclient can be horribly
slow at times such that even if things work perfectly, getting a DHCP
lease takes what feels like ages. This can be fixed by implementing
RFC 4436 like Apple did in its products. It can also be worked around
by configuring it to make an attempt every few seconds rather than
every minute, which coincidentally, is the exact time that it takes
for dhclient to time itself out and quit, making Network Manager kill
an otherwise good connection. I reported this last year to my
distribution, which has since changed the default config file, but in
the course of diagnosing this year's problems, I managed to find
various LUG mailing lists discussing this problem. Their workaround
was to run dhclient manually, which causes zombie processes to be made
and it really doesn't seem like the right solution to this issue.
Anyway, that is everything that I know about this issue. I am right
now sitting on as many as three other issues in other parts of the
kernel, but I don't plan to report them until I understand them well
enough to either write patches or post how to reliably reproduce them.
The last time I posted something on the mailing list, someone named
Ted yelled at me for asking a stupid question. If that happens again,
I will probably just unsubscribe and let that be the end of it. I have
only used Linux for less than 2 years and I am not paid to do this, so
please be nice.
Yours truly,
Richard Yao
On Wed, Oct 19, 2011 at 2:01 AM, Norbert Preining <preining@logic.at> wrote:
> Hi everyone
>
> (please Cc),
>
> I am currently running 3.1.0-rc10, and I am having a hard time with
> the wlan network here at the university.
>
> For quite some time, like 10min, it is fine, then suddently the
> iwlagn driver gives up on me and connection is dropped.
>
> In the log file I see:
> [ 172.137011] iwlagn 0000:06:00.0: Tx aggregation enabled on ra = 00:24:c4:ab:bd:ef tid = 0
> [ 821.841016] iwlagn 0000:06:00.0: Tx aggregation enabled on ra = 00:24:c4:ab:bd:ef tid = 6
> [ 1095.580735] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
> [ 1095.780076] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
> [ 1095.980101] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
> [ 1096.180117] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
> [ 1105.255464] wlan0: deauthenticating from 00:24:c4:ab:bd:ef by local choice (reason=2)
> [ 1105.255519] iwlagn 0000:06:00.0: Stopping AGG while state not ON or starting
> [ 1105.265581] cfg80211: Calling CRDA for country: JP
> [ 1105.271476] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 1)
> [ 1105.468105] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 2)
> [ 1105.668110] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 3)
> [ 1105.868090] wlan0: authentication with 00:24:c4:ab:bd:e0 timed out
> [ 1113.667890] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
> [ 1113.864116] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
> [ 1114.064095] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
> [ 1114.264109] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
>
> Somewhere around 1100 the connection is gone and never comes back again.
>
> I tried removing the driver module from the kernel and reinserting it,
> tried to turn on and off the hardware swithc (rfkill), all without
> no success, the wlan connection remains dead until I reboot.
>
> I am not sure exactely when it started, I guess somewhere in the
> 3.1 cycle, before I was permanently working wiht wlan, now I always
> plug in the cable.
>
> If there is any way to track down this, or any suggestions how I can
> debug it, please let me know.
>
> Hardware: Sony VGN-Z11, Intel(R) WiFi Link 5100 AGN, REV=0x54
> L1 Enabled; Disabling L0S
> device EEPROM VER=0x11e, CALIB=0x4
> Device SKU: 0Xf0
> Tunable channels: 13 802.11bg, 24 802.11a channels
> loaded firmware version 8.83.5.1 build 33692 (EXP)
>
>
> On the other hand, the same laptop with the very same configuration
> works very nicely in my flat's wlan, which is some dirt cheap Japanese
> only wlan router.
>
> Best wishes and thanks a lot
>
> Norbert
> ------------------------------------------------------------------------
> Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
> JAIST, Japan TeX Live & Debian Developer
> DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
> ------------------------------------------------------------------------
> DITHERINGTON (n)
> Sudden access to panic experienced by one who realises that he is
> being drawn inexorably into a clabby (q.v.) conversation, i.e. one he
> has no hope of enjoying, benefiting from or understanding.
> --- Douglas Adams, The Meaning of Liff
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: How to enable clock/power from a wlan device driver
From: Bob Copeland @ 2011-10-27 1:39 UTC (permalink / raw)
To: Dmitry Tarnyagin; +Cc: linux-wireless
In-Reply-To: <CAMG6FYh6dPVQuvoTQsOAqbe_WrMMj7qji8T45DWmdrk-RNb-Bw@mail.gmail.com>
On Wed, Oct 26, 2011 at 8:35 AM, Dmitry Tarnyagin <abi.dmitryt@gmail.com> wrote:
> 3. Driver can call platform callback and request platform code to
> enable the clock.
> For my understanding clocks and power are platform-specific.
Beats me what is best for your needs, but in light of the above it
seems #3 fits the bill?
This is the way other wireless drivers have done it -- e.g. wl12xx has
a set_power() callback and the platform device uses it to disable the
clock when the device is in low power mode.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* RE: iwlagn is getting very shaky
From: Guy, Wey-Yi W @ 2011-10-27 3:48 UTC (permalink / raw)
To: Richard Yao
Cc: Norbert Preining, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, ipw3945-devel@lists.sourceforge.net,
ilw@linux.intel.com, Pekka Enberg, David Rientjes
In-Reply-To: <CABDyM6R-BBV1_oci2vMoxcybT=0cxPRfHELvtrQTRfSf6WO9Eg@mail.gmail.com>
Hi Richard,
Thanks so much for the information, we will look into it asap and get back to you.
Thanks
Wey
-----Original Message-----
From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of Richard Yao
Sent: Thursday, October 27, 2011 2:06 AM
To: Guy, Wey-Yi W
Cc: Norbert Preining; linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; ipw3945-devel@lists.sourceforge.net; ilw@linux.intel.com; Pekka Enberg; David Rientjes
Subject: Fwd: iwlagn is getting very shaky
Dear Wey,
Here is the message that I sent earlier.
Yours truly,
Richard Yao
---------- Forwarded message ----------
From: Richard Yao <ryao@cs.stonybrook.edu>
Date: Wed, Oct 26, 2011 at 12:19 AM
Subject: Re: iwlagn is getting very shaky
To: linux-kernel@vger.kernel.org
Cc: preining@logic.at
Dear Everyone,
I have always had issues with Wi-Fi at my university, although they became particularly acute. The problem is characterized by an inordinate number of Tx excessive retries like what Norbert posted. I had been holding off on reporting this out of fear that my report wouldn't be good enough, but now that I see Norbert reported it, I thought I would contribute my findings.
When I looked into this, I found that the wireless spectrum on my university is absurdly crowded. "iwlist wlan0 scan" reveals roughly
100 access points at any given time, many of which have the same SSID.
It is worst in the library, which probably one of the most densely populated buildings. This appears to be linked to the hidden node
problem:
http://en.wikipedia.org/wiki/Hidden_node_problem
I found a few issues in the wireless stack that appear to exacerbate this problem. The first of which is a kernel problem. The iwlagn driver does not support "auto" for the rts and frag settings, so they default to off. I tried fiddling with various settings, but the only one that seems to make a difference is rts, which at the moment I have set to 0, which should turn it on and transmit a request to send for all traffic. I configured my laptop to set rts to 0 on boot and the results were remarkable. I went from having to wait 30 minutes to an hour to get a connection that would only last for 2 minutes if I was lucky to being able to obtain a relatively stable connection within a few minutes.
I also encountered another kernel issue, but I haven't seen it in a while. That issue was characterized by "iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting". After that went into the dmesg output, it looked like I was transmitting, but I never saw a single response from the outside world until I did "modprobe -r iwlagn && modprobe iwlagn". I believe that this issue was present in kernel 3.1.0-rc4, but I could be off by an rc or two. It normally occurred within 5 to 15 mnutes and only occurred if I had passed 11n_disable=1 to the kernel module. I don't pass that anymore, so I don't know if it is still a problem.
With that said, I discovered issues in other areas of the wireless stack. One is that Network Manager has a 25-second hard-coded timeout (in nm-device-wifi.c) when controlling WPA Supplicant. Ignoring the hard-coded part, having the time-out isn't so bad until you consider that WPA Supplicant will enter an infinite retry loop whenever Network Manager asks it to try connecting to an access point that is either malfunctioning or cannot hear your wireless NIC. Furthermore, if you are in an area where multiple access points use the same SSID, WPA supplicant will try to connect to each one with its own 9 second timeout, so Network Manager will kill it before it has gone through the entire list. I don't know if the 9 second timeout is hard coded, but the kernel lists 3 direct probe attempts in the dmesg output and if all 3 fail, WPA Supplicant will wait precisely 9 seconds (from the first one) before it tries something else. I imgaine that if someone patched the stack to implements some callbacks, things would become much better when they don't work the first time. With that said, WPA Supplicant needs a callback from the kernel when association fails and either WPA Supplicant, Network Manager or both need to be patched so that WPA Supplicant will not enter an infinite retry loop and instead it will give Network Manager a failure callback so that it can try something else.
This might be the wrong mailing list to discuss issues that reside entirely in userland, but since I described a few other issues that were sort of a mix of both, I think I will throw in the other two that I found for completeness. With that said, another issue that sometimes happens is that the kernel loses the wireless access point association. If I do this manually, I can just use iwconfig to make the kerenl reassociate, but if that happens with Network Manager, it kills the entire connection and starts from scratch. This leads us to the last issue I identified, which is that dhclient can be horribly slow at times such that even if things work perfectly, getting a DHCP lease takes what feels like ages. This can be fixed by implementing RFC 4436 like Apple did in its products. It can also be worked around by configuring it to make an attempt every few seconds rather than every minute, which coincidentally, is the exact time that it takes for dhclient to time itself out and quit, making Network Manager kill an otherwise good connection. I reported this last year to my distribution, which has since changed the default config file, but in the course of diagnosing this year's problems, I managed to find various LUG mailing lists discussing this problem. Their workaround was to run dhclient manually, which causes zombie processes to be made and it really doesn't seem like the right solution to this issue.
Anyway, that is everything that I know about this issue. I am right now sitting on as many as three other issues in other parts of the kernel, but I don't plan to report them until I understand them well enough to either write patches or post how to reliably reproduce them.
The last time I posted something on the mailing list, someone named Ted yelled at me for asking a stupid question. If that happens again, I will probably just unsubscribe and let that be the end of it. I have only used Linux for less than 2 years and I am not paid to do this, so please be nice.
Yours truly,
Richard Yao
On Wed, Oct 19, 2011 at 2:01 AM, Norbert Preining <preining@logic.at> wrote:
> Hi everyone
>
> (please Cc),
>
> I am currently running 3.1.0-rc10, and I am having a hard time with
> the wlan network here at the university.
>
> For quite some time, like 10min, it is fine, then suddently the iwlagn
> driver gives up on me and connection is dropped.
>
> In the log file I see:
> [ 172.137011] iwlagn 0000:06:00.0: Tx aggregation enabled on ra =
> 00:24:c4:ab:bd:ef tid = 0 [ 821.841016] iwlagn 0000:06:00.0: Tx
> aggregation enabled on ra = 00:24:c4:ab:bd:ef tid = 6 [ 1095.580735]
> wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3) [ 1095.780076]
> wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3) [ 1095.980101]
> wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3) [ 1096.180117]
> wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out [ 1105.255464]
> wlan0: deauthenticating from 00:24:c4:ab:bd:ef by local choice
> (reason=2) [ 1105.255519] iwlagn 0000:06:00.0: Stopping AGG while
> state not ON or starting [ 1105.265581] cfg80211: Calling CRDA for
> country: JP [ 1105.271476] wlan0: authenticate with 00:24:c4:ab:bd:e0
> (try 1) [ 1105.468105] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try
> 2) [ 1105.668110] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 3) [
> 1105.868090] wlan0: authentication with 00:24:c4:ab:bd:e0 timed out [
> 1113.667890] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3) [
> 1113.864116] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3) [
> 1114.064095] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3) [
> 1114.264109] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
>
> Somewhere around 1100 the connection is gone and never comes back again.
>
> I tried removing the driver module from the kernel and reinserting it,
> tried to turn on and off the hardware swithc (rfkill), all without no
> success, the wlan connection remains dead until I reboot.
>
> I am not sure exactely when it started, I guess somewhere in the
> 3.1 cycle, before I was permanently working wiht wlan, now I always
> plug in the cable.
>
> If there is any way to track down this, or any suggestions how I can
> debug it, please let me know.
>
> Hardware: Sony VGN-Z11, Intel(R) WiFi Link 5100 AGN, REV=0x54
> L1 Enabled; Disabling L0S
> device EEPROM VER=0x11e, CALIB=0x4
> Device SKU: 0Xf0
> Tunable channels: 13 802.11bg, 24 802.11a channels loaded firmware
> version 8.83.5.1 build 33692 (EXP)
>
>
> On the other hand, the same laptop with the very same configuration
> works very nicely in my flat's wlan, which is some dirt cheap Japanese
> only wlan router.
>
> Best wishes and thanks a lot
>
> Norbert
> ----------------------------------------------------------------------
> -- Norbert Preining preining@{jaist.ac.jp, logic.at,
> debian.org} JAIST, Japan TeX Live &
> Debian Developer
> DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5
> B094
> ----------------------------------------------------------------------
> --
> DITHERINGTON (n)
> Sudden access to panic experienced by one who realises that he is
> being drawn inexorably into a clabby (q.v.) conversation, i.e. one he
> has no hope of enjoying, benefiting from or understanding.
> --- Douglas Adams, The Meaning of Liff
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
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: Switching ssb to read 8-bit quantities from SPROM
From: Michael Büsch @ 2011-10-27 4:59 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Buesch, Rafał Miłecki, b43-dev, wireless
In-Reply-To: <4EA888AE.30406@lwfinger.net>
On Wed, 26 Oct 2011 17:24:46 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> I tested the effects of changing ssb to read the SSPROM in 8-bit hunks rather
> than as 16-bit words in the manner that was just submitted for brcmsmac.
> Although this simplifies the calculation of the crc8, it only reduced the size
> of the module by 31 bytes, thus I will not be submitting the patch.
>
> When the library version of the crc8 routine was used rather than the one built
> into ssb, the size of the driver was increased by 17 bytes.
Well, if this doesn't cause regressions due to the changed reads, I'm OK
with it (as in I don't really care either way).
But it has to be tested on b44, too.
--
Greetings, Michael.
^ permalink raw reply
* Re: problem with intel 5300
From: Mikael Abrahamsson @ 2011-10-27 6:01 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1319463944.31823.79.camel@wwguy-huron>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 420 bytes --]
On Mon, 24 Oct 2011, Guy, Wey-Yi wrote:
> very happy to hear that, thank you very much for reporting
Well, yesterday I ran into problems. Wifi was quite unstable, speeds were
changing rapidly between 6 and 150 megabit/s.
Attaching logs, at 20:39 I rmmod:ed iwlagn and modprobed it again, after
that things went back to normal and it's been working fine ever since.
--
Mikael Abrahamsson email: swmike@swm.pp.se
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 171958 bytes --]
^ permalink raw reply
* Re: [PATCH] ath6kl: add support for WPS
From: Kalle Valo @ 2011-10-27 7:53 UTC (permalink / raw)
To: Aarthi Thiruvengadam; +Cc: linux-wireless
In-Reply-To: <1319567152-19789-1-git-send-email-aarthi.thiruvengadam@qca.qualcomm.com>
On 10/25/2011 09:25 PM, Aarthi Thiruvengadam wrote:
> Add control flag CONNECT_WPS_FLAG if a WPS IE is present in the
> Association Request IEs. This flag is needed when the station must
> connect to a WPS-enabled AP.
Thanks, applied. There was a conflict due to multivif patches which I
fixed manually, please check that I didn't break anything.
Kalle
^ 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