* Re: [PATCH v2] cfg80211: merge in beacon ies of hidden bss.
From: Johannes Berg @ 2011-11-04 8:26 UTC (permalink / raw)
To: Dmitry Tarnyagin; +Cc: linux-wireless
In-Reply-To: <CAMG6FYg__nsSLa93AmzcMgckg8HG3FjD3LxpyDfA77WTsVm0oA@mail.gmail.com>
On Thu, 2011-11-03 at 22:59 +0100, Dmitry Tarnyagin wrote:
> + /* Absence of SSID or zero-sized SSID is used as
> + * an indication of the hidden bss. */
> + if (!ie2 || !ie2[1])
> + return 0;
I don't think that's right -- I never saw anything w/o an SSID IE except
for mesh networks I think. Also this has different semantics from the
regular rb-tree search which will return -1 if not present (which is
actually a bug).
> + /* Key comparator must use same algorithm in any rb-tree
> + * search function (order is important), otherwise ordering
> + * of items in the tree is broken and search gives incorrect
> + * results. This code uses same order as cmp_ies() does.
> + *
> + * The only difference is that this code searchs for zeroed
> + * SSID ie (another indication of the hidden bss). */
> + ielen = min(ie1[1], ie2[1]);
> + for (i = 0; i < ielen; i++)
> + if (ie2[i + 2])
> + return -1;
> + return ie2[1] - ie1[1];
Since we need to fix cmp_ie() anyway, how about we change it there as
well. I'm going to post a patch.
> @@ -587,6 +681,21 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
>
> kref_put(&res->ref, bss_release);
> } else {
> + struct cfg80211_internal_bss *hidden;
> +
> + /* First check if the beacon is a probe response from
> + * a hidden bss. If so, copy beacon ies (with nullified
> + * ssid) into the probe response bss entry (with real ssid).
> + * It is required basically for PSM implementation
> + * (probe responses do not contain tim ie) */
> +
> + /* TODO: The code is not trying to update existing probe
> + * response bss entries when beacon ies are
> + * getting changed. */
> + hidden = rb_find_hidden_bss(dev, res);
> + if (hidden)
> + copy_hidden_ies(res, hidden);
> +
This is nicer, though I'd prefer the TODO was addressed as well since
now we'll forever show stale data, this seems a bit bad.
johannes
^ permalink raw reply
* Re: A new driver is going to be released
From: Johannes Berg @ 2011-11-04 8:12 UTC (permalink / raw)
To: Dmitry Tarnyagin; +Cc: Dan Williams, Larry Finger, linux-wireless
In-Reply-To: <CAMG6FYgD9DDa+eJgALi3LLF1yQO3ujaxAskpEf1kvcJ19rYwxA@mail.gmail.com>
On Fri, 2011-11-04 at 06:32 +0100, Dmitry Tarnyagin wrote:
> On Fri, Nov 4, 2011 at 3:01 AM, Dan Williams <dcbw@redhat.com> wrote:
> > It looks like it's mac80211-based and already in drivers/staging/
> > according to the git tree Dmitry pointed to.
> >
> Correct. But I would move it to drivers/net/wireless during submission.
A word of caution: don't attempt that in its current state.
johannes
^ permalink raw reply
* Re: A new driver is going to be released
From: Kalle Valo @ 2011-11-04 8:06 UTC (permalink / raw)
To: Dmitry Tarnyagin; +Cc: linux-wireless
In-Reply-To: <CAMG6FYiNW-1ijghpgQ6R_9HujVEp8d53DQ-vjfJrw_hZamM8Jw@mail.gmail.com>
Dmitry Tarnyagin <abi.dmitryt@gmail.com> writes:
> I'm about to release cw1200 driver to the community
Nice!
> (more or less latest code is available here:
> http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=shortlog;h=refs/heads/linux-3.0-ux500
> as well).
I can't access it. I get "404 - Reading tree failed" when I try to
access the tree through gitweb:
http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=tree;h=%5Crefs/heads/linux-3.0-ux500;hb=%5Crefs/heads/linux-3.0-ux500
--
Kalle Valo
^ permalink raw reply
* Re: A new driver is going to be released
From: Dmitry Tarnyagin @ 2011-11-04 5:32 UTC (permalink / raw)
To: Dan Williams; +Cc: Larry Finger, linux-wireless
In-Reply-To: <1320372088.29008.0.camel@dcbw.foobar.com>
On Fri, Nov 4, 2011 at 3:01 AM, Dan Williams <dcbw@redhat.com> wrote:
> It looks like it's mac80211-based and already in drivers/staging/
> according to the git tree Dmitry pointed to.
>
Correct. But I would move it to drivers/net/wireless during submission.
^ permalink raw reply
* Re: iwlagn master mode
From: Julian Calaby @ 2011-11-04 5:21 UTC (permalink / raw)
To: Richard Yao; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CABDyM6TFm3HPTiJybCkg4fUetKaF2P+qM8DUnHJ5Y+yJAG2i4g@mail.gmail.com>
Hi Richard,
On Fri, Nov 4, 2011 at 12:14, Richard Yao <ryao@cs.stonybrook.edu> wrote:
> Someone I know had to boot into his Mac Book Air's recovery mode and
> he needed a wireless connection. Since the university's wireless
> network was inaccessible to both of us, I tried setting up an access
> point via my laptop so he could connect to the internet through my
> computer's wired ethernet connection. I quickly learned that master
> mode wasn't supported, which made this impossible.
>
> Is it possible to get master mode support in the iwlagn driver?
As far as I know, it is supported.
In the case you describe, you have a two options:
1. Use Network Manager or equivalent to set up an "AdHoc" network
("Create New Wireless Network")
2. Use hostapd to set up the access point. See here:
http://wireless.kernel.org/en/users/Documentation/hostapd
You cannot set master mode without using hostapd.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Norbert Preining @ 2011-11-04 4:58 UTC (permalink / raw)
To: Guy, Wey-Yi
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: <1320204101.31823.140.camel@wwguy-huron>
Hi Wey,
On Di, 01 Nov 2011, Guy, Wey-Yi wrote:
> after the firmware reloaded, is the traffic resume? or it is continuous
> without traffic?
Ok, I compiled a new kernel from todays git, and I see that there
are kernel bugs, but after the hardware restart traffic gets through.
While suspending I have:
[ 6630.948551] WARNING: at drivers/pci/pci-driver.c:607 pci_has_legacy_pm_support.isra.8+0x53/0x59()
[ 6630.948557] Hardware name: VGN-Z11VN_B
[ 6630.948561] Modules linked in: sony_laptop rfcomm bnep snd_hrtimer binfmt_misc dm_crypt dm_mod isofs btrfs zlib_deflate crc32c libcrc32c vfat fat fuse loop uinput snd_hda_codec_realtek arc4 iwlwifi snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm firewire_ohci mac80211 snd_seq_dummy snd_seq_oss snd_seq_midi firewire_core cfg80211 snd_rawmidi snd_seq_midi_event btusb snd_seq snd_timer mxm_wmi bluetooth snd_seq_device crc16 snd rfkill joydev crc_itu_t tpm_infineon soundcore snd_page_alloc
[ 6630.948655] Pid: 11390, comm: kworker/u:8 Not tainted 3.1.0+ #42
[ 6630.948660] Call Trace:
[ 6630.948674] [<ffffffff8103843d>] warn_slowpath_common+0x83/0x9b
[ 6630.948683] [<ffffffff8103846f>] warn_slowpath_null+0x1a/0x1c
[ 6630.948692] [<ffffffff811aa983>] pci_has_legacy_pm_support.isra.8+0x53/0x59
[ 6630.948701] [<ffffffff811aaf94>] pci_pm_suspend+0x34/0x104
[ 6630.948711] [<ffffffff8127f50b>] pm_op+0x8b/0x149
[ 6630.948719] [<ffffffff8127f72f>] __device_suspend+0x106/0x196
[ 6630.948727] [<ffffffff8127f7de>] async_suspend+0x1f/0x5d
[ 6630.948737] [<ffffffff81058251>] async_run_entry_fn+0x9e/0x131
[ 6630.948746] [<ffffffff810581b3>] ? async_schedule+0x17/0x17
[ 6630.948756] [<ffffffff8104dd60>] process_one_work+0x17b/0x2bd
[ 6630.948764] [<ffffffff8104c3a5>] ? need_to_create_worker+0x12/0x26
[ 6630.948773] [<ffffffff8104ee5b>] worker_thread+0xdb/0x15f
[ 6630.948780] [<ffffffff8104ed80>] ? manage_workers.isra.24+0x171/0x171
[ 6630.948789] [<ffffffff81052541>] kthread+0x84/0x8c
[ 6630.948800] [<ffffffff81408a14>] kernel_thread_helper+0x4/0x10
[ 6630.948809] [<ffffffff810524bd>] ? kthread_worker_fn+0x148/0x148
[ 6630.948817] [<ffffffff81408a10>] ? gs_change+0xb/0xb
[ 6630.948824] ---[ end trace 9f0907b3f72ff4c6 ]---
(several of them)
Then I get some WARNINGS from iwl:
[ 6662.601340] WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-pcie.c:1101 iwl_trans_pcie_tx+0x180/0x661 [iwlwifi]()
[ 6662.601343] Hardware name: VGN-Z11VN_B
[ 6662.601345] Modules linked in: sony_laptop rfcomm bnep snd_hrtimer binfmt_misc dm_crypt dm_mod isofs btrfs zlib_deflate crc32c libcrc32c vfat fat fuse loop uinput snd_hda_codec_realtek arc4 iwlwifi snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm firewire_ohci mac80211 snd_seq_dummy snd_seq_oss snd_seq_midi firewire_core cfg80211 snd_rawmidi snd_seq_midi_event btusb snd_seq snd_timer mxm_wmi bluetooth snd_seq_device crc16 snd rfkill joydev crc_itu_t tpm_infineon soundcore snd_page_alloc
[ 6662.601386] Pid: 11391, comm: kworker/u:9 Tainted: G W 3.1.0+ #42
[ 6662.601388] Call Trace:
[ 6662.601390] <IRQ> [<ffffffff8103843d>] warn_slowpath_common+0x83/0x9b
[ 6662.601399] [<ffffffff8103846f>] warn_slowpath_null+0x1a/0x1c
[ 6662.601407] [<ffffffffa0223b04>] iwl_trans_pcie_tx+0x180/0x661 [iwlwifi]
[ 6662.601412] [<ffffffff810d32a5>] ? kmem_cache_alloc+0x44/0xb9
[ 6662.601419] [<ffffffffa020b9f4>] iwlagn_tx_skb+0x862/0x901 [iwlwifi]
[ 6662.601425] [<ffffffffa0201f8c>] iwlagn_mac_tx+0x131/0x1a2 [iwlwifi]
[ 6662.601434] [<ffffffffa01d8bc6>] ? ieee80211_tx_h_fragment+0x16/0x22c [mac80211]
[ 6662.601443] [<ffffffffa01ccf14>] __ieee80211_tx+0x176/0x1cf [mac80211]
[ 6662.601449] [<ffffffffa01d8b38>] ? ieee80211_tx_h_calculate_duration+0x4c/0x65 [mac80211]
[ 6662.601459] [<ffffffffa01cdcda>] ieee80211_tx+0x97/0xaf [mac80211]
[ 6662.601469] [<ffffffffa01cebd6>] ieee80211_tx_pending+0xf0/0x1c3 [mac80211]
[ 6662.601473] [<ffffffff8103db22>] tasklet_action+0x77/0xc2
[ 6662.601477] [<ffffffff8103dc63>] __do_softirq+0xbc/0x1a5
[ 6662.601481] [<ffffffff81408b0c>] call_softirq+0x1c/0x30
[ 6662.601483] <EOI> [<ffffffff8100359e>] do_softirq+0x38/0x6e
[ 6662.601489] [<ffffffff8103d929>] _local_bh_enable_ip.isra.12+0x7d/0xa0
[ 6662.601492] [<ffffffff8103d95a>] local_bh_enable_ip+0xe/0x10
[ 6662.601496] [<ffffffff81406d22>] _raw_spin_unlock_bh+0x23/0x25
[ 6662.601503] [<ffffffffa01bcc64>] ieee80211_agg_tx_operational+0x99/0xa4 [mac80211]
[ 6662.601512] [<ffffffffa01bd7b2>] ieee80211_process_addba_resp+0xb8/0xf2 [mac80211]
[ 6662.601516] [<ffffffff81064740>] ? do_raw_spin_trylock+0xc/0x2a
[ 6662.601525] [<ffffffffa01c4a26>] ieee80211_iface_work+0x130/0x2b5 [mac80211]
[ 6662.601534] [<ffffffffa01c48f6>] ? ieee80211_teardown_sdata+0xcc/0xcc [mac80211]
[ 6662.601538] [<ffffffff8104dd60>] process_one_work+0x17b/0x2bd
[ 6662.601541] [<ffffffff8104c3a5>] ? need_to_create_worker+0x12/0x26
[ 6662.601545] [<ffffffff8104ee5b>] worker_thread+0xdb/0x15f
[ 6662.601548] [<ffffffff8104ed80>] ? manage_workers.isra.24+0x171/0x171
[ 6662.601552] [<ffffffff81052541>] kthread+0x84/0x8c
[ 6662.601556] [<ffffffff81408a14>] kernel_thread_helper+0x4/0x10
[ 6662.601559] [<ffffffff810524bd>] ? kthread_worker_fn+0x148/0x148
[ 6662.601563] [<ffffffff81408a10>] ? gs_change+0xb/0xb
Then I get the hanging queue:
[ 6672.360098] iwlwifi 0000:06:00.0: Queue 11 stuck for 10000 ms.
[ 6672.360109] iwlwifi 0000:06:00.0: Current read_ptr 251 write_ptr 0
[ 6672.360117] iwlwifi 0000:06:00.0: On demand firmware reload
[ 6672.360548] ieee80211 phy0: Hardware restart was requested
[ 6672.360643] iwlwifi 0000:06:00.0: L1 Enabled; Disabling L0S
[ 6672.363667] iwlwifi 0000:06:00.0: Radio type=0x1-0x2-0x0
After that network manager tries to connect to my univerity network,
and I get another
[ 6702.613501] WARNING: at include/net/mac80211.h:3570 rate_control_send_low+0xa5/0x165 [mac80211]()
[ 6702.613508] Hardware name: VGN-Z11VN_B
[ 6702.613513] Modules linked in: sony_laptop rfcomm bnep snd_hrtimer binfmt_misc dm_crypt dm_mod isofs btrfs zlib_deflate crc32c libcrc32c vfat fat fuse loop uinput snd_hda_codec_realtek arc4 iwlwifi snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm firewire_ohci mac80211 snd_seq_dummy snd_seq_oss snd_seq_midi firewire_core cfg80211 snd_rawmidi snd_seq_midi_event btusb snd_seq snd_timer mxm_wmi bluetooth snd_seq_device crc16 snd rfkill joydev crc_itu_t tpm_infineon soundcore snd_page_alloc
[ 6702.613654] Pid: 11391, comm: kworker/u:9 Tainted: G W 3.1.0+ #42
[ 6702.613661] Call Trace:
[ 6702.613678] [<ffffffff8103843d>] warn_slowpath_common+0x83/0x9b
[ 6702.613689] [<ffffffff8103846f>] warn_slowpath_null+0x1a/0x1c
[ 6702.613715] [<ffffffffa01c6139>] rate_control_send_low+0xa5/0x165 [mac80211]
[ 6702.613735] [<ffffffffa02061be>] rs_get_rate+0x146/0x254 [iwlwifi]
[ 6702.613763] [<ffffffffa01c65a1>] rate_control_get_rate+0x86/0x14c [mac80211]
[ 6702.613776] [<ffffffff81406ea7>] ? _raw_spin_unlock_irqrestore+0x25/0x30
] ieee80211_tx_h_rate_ctrl+0x1cb/0x3e4 [mac80211]
[ 6702.613834] [<ffffffffa01d13d7>] ? ieee80211_send_probe_req+0x50/0x58 [mac80211]
[ 6702.613863] [<ffffffffa01cdab9>] invoke_tx_handlers+0x69/0xf5 [mac80211]
[ 6702.613892] [<ffffffffa01cdcc2>] ieee80211_tx+0x7f/0xaf [mac80211]
[ 6702.613922] [<ffffffffa01ce162>] ieee80211_xmit+0x89/0x97 [mac80211]
[ 6702.613950] [<ffffffffa01ced00>] ieee80211_tx_skb+0x57/0x5f [mac80211]
[ 6702.613976] [<ffffffffa01c0088>] ieee80211_send_nullfunc+0x5f/0x64 [mac80211]
[ 6702.613999] [<ffffffffa01bc349>] ieee80211_offchannel_return+0x94/0x1a5 [mac80211]
[ 6702.614012] [<ffffffff8104494f>] ? mod_timer+0x90/0x99
[ 6702.614038] [<ffffffffa01c3de0>] ieee80211_work_work+0xf9c/0x105d [mac80211]
[ 6702.614049] [<ffffffff8100074b>] ? __unlazy_fpu.part.3+0x9/0x61
[ 6702.614059] [<ffffffff81000d06>] ? __switch_to+0xd3/0x200
[ 6702.614070] [<ffffffff8102b30c>] ? need_resched+0x23/0x2d
[ 6702.614096] [<ffffffffa01c2e44>] ? free_work+0x19/0x19 [mac80211]
[ 6702.614108] [<ffffffff8104dd60>] process_one_work+0x17b/0x2bd
[ 6702.614118] [<ffffffff8104c3a5>] ? need_to_create_worker+0x12/0x26
[ 6702.614129] [<ffffffff8104ee5b>] worker_thread+0xdb/0x15f
[ 6702.614138] [<ffffffff8104ed80>] ? manage_workers.isra.24+0x171/0x171
[ 6702.614149] [<ffffffff81052541>] kthread+0x84/0x8c
[ 6702.614160] [<ffffffff81408a14>] kernel_thread_helper+0x4/0x10
[ 6702.614172] [<ffffffff810524bd>] ? kthread_worker_fn+0x148/0x148
[ 6702.614181] [<ffffffff81408a10>] ? gs_change+0xb/0xb
Networkanager[2263]: <info> (wlan0): supplicant interface state: completed -> authenticating
[ 6702.812109] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
[ 6703.012130] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
[ 6703.212113] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
and another few (3) WARNING in include/net/mac80211.h:3570 rate_control_send_low+0xa5/0x165
and the final hickup:
[ 6712.366859] wlan0: deauthenticating from 00:24:c4:ab:bd:ef by local choice (reason=2)
[ 6712.366964] iwlwifi 0000:06:00.0: Stopping AGG while state not ON or starting for 0 on 0 (0)
wpa_supplicant[2339]: Trying to authenticate with 00:24:c4:ab:bd:e0 (SSID='XXXXXXXX' freq=2412 MHz)
wpa_supplicant[2339]: CTRL-EVENT-DISCONNECTED bssid=00:24:c4:ab:bd:e0 reason=2
[ 6712.381957] cfg80211: Calling CRDA to update world regulatory domain
After that NM succeeds and the connections seems to be stable.
I have no idea if that helps you in any way?!
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
------------------------------------------------------------------------
BALLYCUMBER
One of the six half-read books lying somewhere in your bed.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* [PATCH v4 4/4] mac80211: simplify mesh frame queue mapping and QoS
From: Thomas Pedersen @ 2011-11-04 4:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Javier Cardona, Thomas Pedersen, johannes, linville
In-Reply-To: <1320379873-30884-1-git-send-email-thomas@cozybit.com>
From: Javier Cardona <javier@cozybit.com>
We only need to set the skb queue twice:
1. by the netdev, on local TX.
2. when forwarding a mesh frame.
We only need to set the qos header twice:
1. by mac80211, on local TX.
2. when putting a frame on the mpath->frame_queue
We also don't need the RA in order to set the proper queue mapping since
all mesh STAs are QoS, indicate this and do it once when the frame is
received. Also fixes an issue where the QoS header and queue mapping was not
set for unicast forwarded frames.
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
v4: simplify skb_set_queue and set_qos_hdr calls (Thomas)
I'm sneaking this revision in since John hasn't applied these yet. Sorry for
any inconvenince, but I figured this would be better than submitting a
different patch later which reverts 80% of v3. These
changes take this patch from 14 insertions(+), 4 deletions(-) to:
net/mac80211/mesh_hwmp.c | 1 +
net/mac80211/mesh_pathtbl.c | 3 ---
net/mac80211/rx.c | 5 ++---
net/mac80211/wme.c | 2 +-
4 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index b22b223..a7afb2d 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -1043,6 +1043,7 @@ int mesh_nexthop_lookup(struct sk_buff *skb,
skb_to_free = skb_dequeue(&mpath->frame_queue);
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
+ ieee80211_set_qos_hdr(sdata, skb);
skb_queue_tail(&mpath->frame_queue, skb);
if (skb_to_free)
mesh_path_discard_frame(skb_to_free, sdata);
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index 332b5ff1..a861652 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -213,7 +213,6 @@ void mesh_path_assign_nexthop(struct mesh_path *mpath, struct sta_info *sta)
struct ieee80211_hdr *hdr;
struct sk_buff_head tmpq;
unsigned long flags;
- struct ieee80211_sub_if_data *sdata = mpath->sdata;
rcu_assign_pointer(mpath->next_hop, sta);
@@ -224,8 +223,6 @@ void mesh_path_assign_nexthop(struct mesh_path *mpath, struct sta_info *sta)
while ((skb = __skb_dequeue(&mpath->frame_queue)) != NULL) {
hdr = (struct ieee80211_hdr *) skb->data;
memcpy(hdr->addr1, sta->sta.addr, ETH_ALEN);
- skb_set_queue_mapping(skb, ieee80211_select_queue(sdata, skb));
- ieee80211_set_qos_hdr(sdata, skb);
__skb_queue_tail(&tmpq, skb);
}
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 45ace14..8f11888 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1941,6 +1941,7 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
compare_ether_addr(sdata->vif.addr, hdr->addr3) == 0)
return RX_CONTINUE;
+ skb_set_queue_mapping(skb, ieee80211_select_queue(sdata, skb));
mesh_hdr->ttl--;
if (status->rx_flags & IEEE80211_RX_RA_MATCH) {
@@ -1965,12 +1966,10 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
memset(info, 0, sizeof(*info));
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
info->control.vif = &rx->sdata->vif;
+ info->control.jiffies = jiffies;
if (is_multicast_ether_addr(fwd_hdr->addr1)) {
IEEE80211_IFSTA_MESH_CTR_INC(&sdata->u.mesh,
fwded_mcast);
- skb_set_queue_mapping(fwd_skb,
- ieee80211_select_queue(sdata, fwd_skb));
- ieee80211_set_qos_hdr(sdata, fwd_skb);
} else {
int err;
/*
diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
index a440a4a..c6c5ee8 100644
--- a/net/mac80211/wme.c
+++ b/net/mac80211/wme.c
@@ -83,7 +83,7 @@ u16 ieee80211_select_queue(struct ieee80211_sub_if_data *sdata,
break;
#ifdef CONFIG_MAC80211_MESH
case NL80211_IFTYPE_MESH_POINT:
- ra = skb->data;
+ qos = true;
break;
#endif
case NL80211_IFTYPE_STATION:
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 3/4] mac80211: check if frame is really part of this BA
From: Thomas Pedersen @ 2011-11-04 4:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1320379873-30884-1-git-send-email-thomas@cozybit.com>
There was an an implicit assumption that any QoS data frame received
from a STA/TID with an active BA session was sent to this vif as part of
a BA. This is not true if IFF_PROMISC is enabled and the frame was
destined for a different peer, for example. Don't treat these frames as
part of a BA from the sending STA.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
v3: use RX_RA_MATCH instead of checking the address directly (Johannes)
net/mac80211/rx.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index bbe7b50..45ace14 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -744,6 +744,7 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
struct ieee80211_local *local = rx->local;
struct ieee80211_hw *hw = &local->hw;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
+ struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
struct sta_info *sta = rx->sta;
struct tid_ampdu_rx *tid_agg_rx;
u16 sc;
@@ -777,6 +778,10 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
ack_policy != IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)
goto dont_reorder;
+ /* not actually part of this BA session */
+ if (!(status->rx_flags & IEEE80211_RX_RA_MATCH))
+ goto dont_reorder;
+
/* new, potentially un-ordered, ampdu frame - process it */
/* reset session timer */
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 2/4] mac80211: QoS multicast frames have No Ack policy
From: Thomas Pedersen @ 2011-11-04 4:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1320379873-30884-1-git-send-email-thomas@cozybit.com>
Previously QoS multicast frames had the Normal Acknowledgment QoS
control bits set. This would cause broadcast frames to be discarded by
peers with which we have a BA session, since their sequence number would
fall outside the allowed range. Set No Ack QoS control bits on multicast
QoS frames and filter these in de-aggregation code.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
v2: Use proper QoS Ack Policy ctl field mask (Christian)
v3: Clean up conditional (Johannes)
---
include/linux/ieee80211.h | 1 +
net/mac80211/rx.c | 9 ++++++++-
net/mac80211/wme.c | 3 ++-
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 48363c3..bc61e69 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -128,6 +128,7 @@
#define IEEE80211_QOS_CTL_ACK_POLICY_NOACK 0x0020
#define IEEE80211_QOS_CTL_ACK_POLICY_NO_EXPL 0x0040
#define IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK 0x0060
+#define IEEE80211_QOS_CTL_ACK_POLICY_MASK 0x0060
/* A-MSDU 802.11n */
#define IEEE80211_QOS_CTL_A_MSDU_PRESENT 0x0080
/* Mesh Control 802.11s */
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index b867bd5..bbe7b50 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -747,7 +747,7 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
struct sta_info *sta = rx->sta;
struct tid_ampdu_rx *tid_agg_rx;
u16 sc;
- int tid;
+ u8 tid, ack_policy;
if (!ieee80211_is_data_qos(hdr->frame_control))
goto dont_reorder;
@@ -760,6 +760,8 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
if (!sta)
goto dont_reorder;
+ ack_policy = *ieee80211_get_qos_ctl(hdr) &
+ IEEE80211_QOS_CTL_ACK_POLICY_MASK;
tid = *ieee80211_get_qos_ctl(hdr) & IEEE80211_QOS_CTL_TID_MASK;
tid_agg_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[tid]);
@@ -770,6 +772,11 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
if (unlikely(hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_NULLFUNC)))
goto dont_reorder;
+ /* not part of a BA session */
+ if (ack_policy != IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK &&
+ ack_policy != IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)
+ goto dont_reorder;
+
/* new, potentially un-ordered, ampdu frame - process it */
/* reset session timer */
diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
index fd52e69..a440a4a 100644
--- a/net/mac80211/wme.c
+++ b/net/mac80211/wme.c
@@ -147,7 +147,8 @@ void ieee80211_set_qos_hdr(struct ieee80211_sub_if_data *sdata,
tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
- if (unlikely(sdata->local->wifi_wme_noack_test))
+ if (unlikely(sdata->local->wifi_wme_noack_test) ||
+ is_multicast_ether_addr(hdr->addr1))
ack_policy |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
/* qos header is 2 bytes */
*p++ = ack_policy | tid;
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 1/4] mac80211: Avoid filling up mesh preq queue with redundant requests
From: Thomas Pedersen @ 2011-11-04 4:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Javier Cardona, johannes, linville
From: Javier Cardona <javier@cozybit.com>
Don't accept redundant PREQs for a given destination. This fixes a
problem under high load:
kernel: [20386.250913] mesh_queue_preq: 235 callbacks suppressed
kernel: [20386.253335] Mesh HWMP (mesh0): PREQ node queue full
kernel: [20386.253352] Mesh HWMP (mesh0): PREQ node queue full
(...)
The 802.11s protocol has a provision to limit the rate of path requests
(PREQs) are transmitted (dot11MeshHWMPpreqMinInterval) but there was no
limit on the rate at which PREQs were being queued up. There is a valid
reason for queuing PREQs: this way we can even out PREQ bursts. But
queueing multiple PREQs for the same destination is useless.
Reported-by: Pedro Larbig <pedro.larbig@carhs.de>
Signed-off-by: Javier Cardona <javier@cozybit.com>
---
v3: move mpath flag update inside state_lock (Johannes)
net/mac80211/mesh.h | 3 +++
net/mac80211/mesh_hwmp.c | 15 +++++++++++++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h
index 8c00e2d..b3745e8 100644
--- a/net/mac80211/mesh.h
+++ b/net/mac80211/mesh.h
@@ -31,6 +31,8 @@
* @MESH_PATH_FIXED: the mesh path has been manually set and should not be
* modified
* @MESH_PATH_RESOLVED: the mesh path can has been resolved
+ * @MESH_PATH_REQ_QUEUED: there is an unsent path request for this destination
+ * already queued up, waiting for the discovery process to start.
*
* MESH_PATH_RESOLVED is used by the mesh path timer to
* decide when to stop or cancel the mesh path discovery.
@@ -41,6 +43,7 @@ enum mesh_path_flags {
MESH_PATH_SN_VALID = BIT(2),
MESH_PATH_FIXED = BIT(3),
MESH_PATH_RESOLVED = BIT(4),
+ MESH_PATH_REQ_QUEUED = BIT(5),
};
/**
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 9a1f8bb..b22b223 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -867,9 +867,19 @@ static void mesh_queue_preq(struct mesh_path *mpath, u8 flags)
return;
}
+ spin_lock_bh(&mpath->state_lock);
+ if (mpath->flags & MESH_PATH_REQ_QUEUED) {
+ spin_unlock_bh(&mpath->state_lock);
+ spin_unlock_bh(&ifmsh->mesh_preq_queue_lock);
+ return;
+ }
+
memcpy(preq_node->dst, mpath->dst, ETH_ALEN);
preq_node->flags = flags;
+ mpath->flags |= MESH_PATH_REQ_QUEUED;
+ spin_unlock_bh(&mpath->state_lock);
+
list_add_tail(&preq_node->list, &ifmsh->preq_queue.list);
++ifmsh->preq_queue_len;
spin_unlock_bh(&ifmsh->mesh_preq_queue_lock);
@@ -921,6 +931,7 @@ void mesh_path_start_discovery(struct ieee80211_sub_if_data *sdata)
goto enddiscovery;
spin_lock_bh(&mpath->state_lock);
+ mpath->flags &= ~MESH_PATH_REQ_QUEUED;
if (preq_node->flags & PREQ_Q_F_START) {
if (mpath->flags & MESH_PATH_RESOLVING) {
spin_unlock_bh(&mpath->state_lock);
@@ -1028,8 +1039,7 @@ int mesh_nexthop_lookup(struct sk_buff *skb,
mesh_queue_preq(mpath, PREQ_Q_F_START);
}
- if (skb_queue_len(&mpath->frame_queue) >=
- MESH_FRAME_QUEUE_LEN)
+ if (skb_queue_len(&mpath->frame_queue) >= MESH_FRAME_QUEUE_LEN)
skb_to_free = skb_dequeue(&mpath->frame_queue);
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
@@ -1061,6 +1071,7 @@ void mesh_path_timer(unsigned long data)
} else if (mpath->discovery_retries < max_preq_retries(sdata)) {
++mpath->discovery_retries;
mpath->discovery_timeout *= 2;
+ mpath->flags &= ~MESH_PATH_REQ_QUEUED;
spin_unlock_bh(&mpath->state_lock);
mesh_queue_preq(mpath, 0);
} else {
--
1.7.5.4
^ permalink raw reply related
* Re: [ath9k-devel] [RFC v2 2/2] ath9k: integrate initial DFS module
From: Peter Stuge @ 2011-11-04 3:00 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: Christian Lamparter, ath9k-devel, linux-wireless, rodrigue
In-Reply-To: <4EB2CE96.4060702@neratec.com>
Zefir Kurtisi wrote:
> Just clarify whether you do not like the CONFIG_ prefix or the fact
> that it can't be enabled.
It's IMO always stupid to add dead code. No exceptions for
$random_authority_which_has_no_jurisdiction_for_billions_of_users.
//Peter
^ permalink raw reply
* Re: A new driver is going to be released
From: Dan Williams @ 2011-11-04 2:01 UTC (permalink / raw)
To: Larry Finger; +Cc: Dmitry Tarnyagin, linux-wireless
In-Reply-To: <4EB33B67.6080806@lwfinger.net>
On Thu, 2011-11-03 at 20:09 -0500, Larry Finger wrote:
> On 11/03/2011 05:40 PM, Dmitry Tarnyagin wrote:
> > Hi,
> >
> > I'm about to release cw1200 driver to the community (more or less
> > latest code is available here:
> > http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=shortlog;h=refs/heads/linux-3.0-ux500
> > as well).
> >
> > Technical question: how is it usually done in terms of commit history?
> > Should I preserve the history and release all the changes in the
> > driver separately or should I squash everything to a single commit
> > or...?
>
> The details of what it took to get your driver to this point are not going to be
> of much interest in the future. The "official" history starts with acceptance
> into the kernel. Two things to keep in mind: (1) the kernel source must compile
> at each step of the way to allow for bisection, thus any changes to Kconfig and
> Makefile must be in the last patch, and (2) each commit should be small enough
> that it is relatively easy to review.
>
> As I do not know the complexity of the driver, it is a little difficult to make
> suggestions; however, one way to accomplish the above is to add each source file
> in a separate patch. The maintainer may submit the final version as a single
> commit, but that is their choice.
>
> Your sending this mail to the wireless ML indicates that you plan to submit the
> driver to the drivers/net/wireless/ part of the source tree. As long as the
> driver employs mac80211, that is appropriate. The other option is
> drivers/staging/. Drivers for that section of the source tree usually are not
> held to standards as high as the wireless section.
It looks like it's mac80211-based and already in drivers/staging/
according to the git tree Dmitry pointed to.
Dan
^ permalink raw reply
* iwlagn master mode
From: Richard Yao @ 2011-11-04 1:14 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Someone I know had to boot into his Mac Book Air's recovery mode and
he needed a wireless connection. Since the university's wireless
network was inaccessible to both of us, I tried setting up an access
point via my laptop so he could connect to the internet through my
computer's wired ethernet connection. I quickly learned that master
mode wasn't supported, which made this impossible.
Is it possible to get master mode support in the iwlagn driver?
By the way, I am not on the mailing list. Please CC replies to me.
Yours truly,
Richard yao
^ permalink raw reply
* Re: A new driver is going to be released
From: Larry Finger @ 2011-11-04 1:09 UTC (permalink / raw)
To: Dmitry Tarnyagin; +Cc: linux-wireless
In-Reply-To: <CAMG6FYiNW-1ijghpgQ6R_9HujVEp8d53DQ-vjfJrw_hZamM8Jw@mail.gmail.com>
On 11/03/2011 05:40 PM, Dmitry Tarnyagin wrote:
> Hi,
>
> I'm about to release cw1200 driver to the community (more or less
> latest code is available here:
> http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=shortlog;h=refs/heads/linux-3.0-ux500
> as well).
>
> Technical question: how is it usually done in terms of commit history?
> Should I preserve the history and release all the changes in the
> driver separately or should I squash everything to a single commit
> or...?
The details of what it took to get your driver to this point are not going to be
of much interest in the future. The "official" history starts with acceptance
into the kernel. Two things to keep in mind: (1) the kernel source must compile
at each step of the way to allow for bisection, thus any changes to Kconfig and
Makefile must be in the last patch, and (2) each commit should be small enough
that it is relatively easy to review.
As I do not know the complexity of the driver, it is a little difficult to make
suggestions; however, one way to accomplish the above is to add each source file
in a separate patch. The maintainer may submit the final version as a single
commit, but that is their choice.
Your sending this mail to the wireless ML indicates that you plan to submit the
driver to the drivers/net/wireless/ part of the source tree. As long as the
driver employs mac80211, that is appropriate. The other option is
drivers/staging/. Drivers for that section of the source tree usually are not
held to standards as high as the wireless section.
Please be certain that all code submitted passes all tests cleanly including
checkpatch, sparse including endianess, and smatch.
Good luck,
Larry
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Richard Yao @ 2011-11-04 0:56 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: Norbert Preining, 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: <1320204101.31823.140.camel@wwguy-huron>
Dear Wey,
My situation is very similar to Norbert's. At my house, I have no
issues at all, but at my university, I tend to have issues. In the
past, using 11n_disable=1 would cause the wireless interface to break
until I executed "modprobe -r iwlagn && modprobe iwlagn" as root. That
was around Linux 3.0-rc4. I haven't tried it since, but what seems to
help is "iwconfig wlan0 rts 0", but even that is not perfect. I just
gave "modprobe -r iwlagn && modprobe iwlagn 11n_disable=1" another try
and it makes no difference.
Issues with the campus Wi-Fi are not isolated to Linux users. I
suspect it has something to do with the 100 or so access points that I
see when I do "iwlist wlan0 scan" at my university and the 4 that I
see when I do that off campus. I don't want to imagine how many
devices are trying to use the available bandwidth. I imagine that
implementing "auto" for rts would improve both my and Norbert's
situations.
Yours truly,
Richard Yao
On Tue, Nov 1, 2011 at 11:21 PM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
> Hi Norbert,
>
> On Tue, 2011-11-01 at 20:13 -0700, Norbert Preining wrote:
>> Hi all,
>>
>> On Mi, 26 Okt 2011, Norbert Preining wrote:
>> > On Di, 25 Okt 2011, wwguy wrote:
>> > > so this is different problem, right? it looks different compare to what
>> > > you described before which is cause by queue stopped.
>> >
>> > I assume that this is a different regression concerning 3.1.0 released.
>>
>> Is there any progress on that? Currently linux git status is unusable
>> with respect to iwlwifi?
>>
>> Are there any changes planned before rc1?
>>
> after the firmware reloaded, is the traffic resume? or it is continuous
> without traffic?
>
> Looks like the different "queue stuck" problem you are seeing. you
> mention you only seeing this at university but not home. So what the
> differences are?
> what Band/channel you are using, also, if you disable 11n, are you still
> seeing the problem?
>
> you also mention it is might related to suspend/resume, could you please
> give a better description why you think it might be related
>
> Thanks
> Wey
>
>
>
> --
> 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: b43 scans wifi networks with old firmware only.
From: Larry Finger @ 2011-11-04 0:37 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: roman-vl, linux-wireless
In-Reply-To: <CACna6rx5eZ+JsS+X=FyPFo9J1+=tkzsujHMHCPFPY=+O_yxS1Q@mail.gmail.com>
On 11/03/2011 05:37 PM, Rafał Miłecki wrote:
> 2011/11/3 Larry Finger<Larry.Finger@lwfinger.net>:
>> On 11/03/2011 06:21 AM, Roman V.Leon. wrote:
>>>
>>> Hello Gents.
>>> I have problem with b43 driver 5.100.138, it's not scanning networks for
>>> unknown reason. I have broadcom wifi card PCIID is 14e4:4315, linux kern
>>> ver. is 3.0. When i'm trying to launch iwlist scan, i'm getting "no scan
>>> results".
>>>
>>> for example:
>>> sudo ifconfig wlan0 up
>>> sudo iwlist wlan0 scan
>>> No scan results.
>>>
>>> With the older driver 5.10.56.2808, i see normal scan results. If you need
>>> any more information, i will send.
>>
>> The condition you report is known. Broadcom changed the TX/RX header
>> structure with firmware versions greater than 600, as shown by a 'dmesg |
>> grep firmware'. Those changes are not implemented in b43 until kernel 3.2.
>>
>> These numbers are not b43 driver numbers, nor are they firmware numbers
>> reported by b43. They are the versions of Broadcom drivers.
>>
>> If you look at
>> http://wireless.kernel.org/en/users/Drivers/b43#firmwareinstallation, you
>> will see that firmware should be extracted from Broadcom driver 5.100.138
>> "if you are using kernel 3.2 or newer". For older kernels you should extract
>> firmware from the 5.10.56.27.3 of the Broadcom proprietary driver. Of
>> course, 5.10.56.2808 will also work.
>>
>> You could also get those changes by employing a bleeding-edge version of
>> compat-wireless. In that case, firmware from 5.100.138 would work.
>
> Should we/can we send patch for at least 3.0.x and 3.1.x kernels
> adding error on loading too new firmware?
I think adding an error would have been appropriate. We certainly cannot prevent
versionitis; however, getting a patch into those kernels that is not in mainline
might be a problem.
Larry
^ permalink raw reply
* Re: [PATCH v3] net:rfkill: add a gpio setup function into GPIO rfkill
From: Ingvar Hagelund @ 2011-11-03 23:45 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <bebe7f8a-897c-4096-9aaf-e3f63151bbfc@claudius.linpro.no>
Reference: Email from Sangwook Lee, 2011-09-29 to this list and to lkml, with this subject, see http://article.gmane.org/gmane.linux.kernel/1197024/
Now, when I compile compat-wireless-2011-11-03 on my G3 iBook (ppc32) against linux-3.1.0 (Fedora based kernel package 3.1.0-7.fc16.ppc), I get the following errors, so it seems that Lee's patch was not merged (yet), though those structs 'gpio_runtime_setup' and 'gpio_runtime_close' are used in the rfkill-gpio module:
CC [M] /home/ingvar/src/compat-wireless-latest/compat-wireless-2011-11-03/net/rfkill/rfkill-gpio.o
/home/ingvar/src/compat-wireless-latest/compat-wireless-2011-11-03/net/rfkill/rfkill-gpio.c: In function 'rfkill_gpio_probe':
/home/ingvar/src/compat-wireless-latest/compat-wireless-2011-11-03/net/rfkill/rfkill-gpio.c:104:11: error: 'struct rfkill_gpio_platform_data' has no member named 'gpio_runtime_setup'
/home/ingvar/src/compat-wireless-latest/compat-wireless-2011-11-03/net/rfkill/rfkill-gpio.c:105:14: error: 'struct rfkill_gpio_platform_data' has no member named 'gpio_runtime_setup'
/home/ingvar/src/compat-wireless-latest/compat-wireless-2011-11-03/net/rfkill/rfkill-gpio.c: In function 'rfkill_gpio_remove':
/home/ingvar/src/compat-wireless-latest/compat-wireless-2011-11-03/net/rfkill/rfkill-gpio.c:195:11: error: 'struct rfkill_gpio_platform_data' has no member named 'gpio_runtime_close'
/home/ingvar/src/compat-wireless-latest/compat-wireless-2011-11-03/net/rfkill/rfkill-gpio.c:196:8: error: 'struct rfkill_gpio_platform_data' has no member named 'gpio_runtime_close'
make[3]: *** [/home/ingvar/src/compat-wireless-latest/compat-wireless-2011-11-03/net/rfkill/rfkill-gpio.o] Error 1
make[2]: *** [/home/ingvar/src/compat-wireless-latest/compat-wireless-2011-11-03/net/rfkill] Error 2
make[1]: *** [_module_/home/ingvar/src/compat-wireless-latest/compat-wireless-2011-11-03] Error 2
make[1]: Leaving directory `/usr/src/kernels/3.1.0-7.fc16.ppc'
make: *** [modules] Error 2
Adding Lee's patch (or even only the headers) seems to work.
Just fyi.
Ingvar
^ permalink raw reply
* Re: [PATCH v2] cfg80211: merge in beacon ies of hidden bss.
From: Vitaly Wool @ 2011-11-03 22:51 UTC (permalink / raw)
To: Dmitry Tarnyagin; +Cc: linux-wireless
In-Reply-To: <CAMG6FYg__nsSLa93AmzcMgckg8HG3FjD3LxpyDfA77WTsVm0oA@mail.gmail.com>
Hi Dmitry,
On Thu, Nov 3, 2011 at 10:59 PM, Dmitry Tarnyagin <abi.dmitryt@gmail.com> wrote:
> The problem with PSM when a hidden SSID was used was originally
> reported by Juuso Oikarinen.
>
> - When generally scanning, the AP is getting a bss entry with
> a zero SSID.
> - When associationg, a probe-req is sent to the AP with the SSID,
> and as a result a probe-responseis received with the hidden
> SSID in place. As a consequence, a second bss entry is created
> for the AP, now with the real SSID.
> - After association, mac80211 executes ieee80211_recalc_ps(),
> but does not switch to powersave becuse the beacon-ies are missing.
>
> As result, the STA does not ever enter PSM.
>
> The patch merges in beacon ies of hidden bss from beacon to the probe
> response, creating a consistant set of ies in place.
>
> Change-Id: I7d10f8546484f51b803b5c003c8208e471b7522b
> Signed-off-by: Dmitry Tarnyagin <dmitry.tarnyagin@stericsson.com>
as a matter of fact, I haven't had a chance to look into your patch in
great detail. But what I can say is that it does work for me, tested
against 2 access points and with 2 different chips (STE's CW1100 and
TI's WL1271L), so let me add
Tested-by: Vitaly Wool <vitalywool@gmail.com>
Thanks,
Vitaly
^ permalink raw reply
* A new driver is going to be released
From: Dmitry Tarnyagin @ 2011-11-03 22:40 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm about to release cw1200 driver to the community (more or less
latest code is available here:
http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=shortlog;h=refs/heads/linux-3.0-ux500
as well).
Technical question: how is it usually done in terms of commit history?
Should I preserve the history and release all the changes in the
driver separately or should I squash everything to a single commit
or...?
Thank you and with best regards,
Dmitry
^ permalink raw reply
* Re: b43 scans wifi networks with old firmware only.
From: Rafał Miłecki @ 2011-11-03 22:37 UTC (permalink / raw)
To: Larry Finger; +Cc: roman-vl, linux-wireless
In-Reply-To: <4EB2AF44.7090102@lwfinger.net>
2011/11/3 Larry Finger <Larry.Finger@lwfinger.net>:
> On 11/03/2011 06:21 AM, Roman V.Leon. wrote:
>>
>> Hello Gents.
>> I have problem with b43 driver 5.100.138, it's not scanning networks for
>> unknown reason. I have broadcom wifi card PCIID is 14e4:4315, linux kern
>> ver. is 3.0. When i'm trying to launch iwlist scan, i'm getting "no scan
>> results".
>>
>> for example:
>> sudo ifconfig wlan0 up
>> sudo iwlist wlan0 scan
>> No scan results.
>>
>> With the older driver 5.10.56.2808, i see normal scan results. If you need
>> any more information, i will send.
>
> The condition you report is known. Broadcom changed the TX/RX header
> structure with firmware versions greater than 600, as shown by a 'dmesg |
> grep firmware'. Those changes are not implemented in b43 until kernel 3.2.
>
> These numbers are not b43 driver numbers, nor are they firmware numbers
> reported by b43. They are the versions of Broadcom drivers.
>
> If you look at
> http://wireless.kernel.org/en/users/Drivers/b43#firmwareinstallation, you
> will see that firmware should be extracted from Broadcom driver 5.100.138
> "if you are using kernel 3.2 or newer". For older kernels you should extract
> firmware from the 5.10.56.27.3 of the Broadcom proprietary driver. Of
> course, 5.10.56.2808 will also work.
>
> You could also get those changes by employing a bleeding-edge version of
> compat-wireless. In that case, firmware from 5.100.138 would work.
Should we/can we send patch for at least 3.0.x and 3.1.x kernels
adding error on loading too new firmware?
--
Rafał
^ permalink raw reply
* [PATCH v2] cfg80211: merge in beacon ies of hidden bss.
From: Dmitry Tarnyagin @ 2011-11-03 21:59 UTC (permalink / raw)
To: linux-wireless
The problem with PSM when a hidden SSID was used was originally
reported by Juuso Oikarinen.
- When generally scanning, the AP is getting a bss entry with
a zero SSID.
- When associationg, a probe-req is sent to the AP with the SSID,
and as a result a probe-responseis received with the hidden
SSID in place. As a consequence, a second bss entry is created
for the AP, now with the real SSID.
- After association, mac80211 executes ieee80211_recalc_ps(),
but does not switch to powersave becuse the beacon-ies are missing.
As result, the STA does not ever enter PSM.
The patch merges in beacon ies of hidden bss from beacon to the probe
response, creating a consistant set of ies in place.
Change-Id: I7d10f8546484f51b803b5c003c8208e471b7522b
Signed-off-by: Dmitry Tarnyagin <dmitry.tarnyagin@stericsson.com>
---
net/wireless/scan.c | 115 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 112 insertions(+), 3 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index dd0d4c5..817c79c 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -325,8 +325,8 @@ static bool is_mesh(struct cfg80211_bss *a,
sizeof(struct ieee80211_meshconf_ie) - 2) == 0;
}
-static int cmp_bss(struct cfg80211_bss *a,
- struct cfg80211_bss *b)
+static int cmp_bss_core(struct cfg80211_bss *a,
+ struct cfg80211_bss *b)
{
int r;
@@ -348,7 +348,15 @@ static int cmp_bss(struct cfg80211_bss *a,
b->len_information_elements);
}
- r = memcmp(a->bssid, b->bssid, ETH_ALEN);
+ return memcmp(a->bssid, b->bssid, ETH_ALEN);
+}
+
+static int cmp_bss(struct cfg80211_bss *a,
+ struct cfg80211_bss *b)
+{
+ int r;
+
+ r = cmp_bss_core(a, b);
if (r)
return r;
@@ -359,6 +367,50 @@ static int cmp_bss(struct cfg80211_bss *a,
b->len_information_elements);
}
+static int cmp_hidden_bss(struct cfg80211_bss *a,
+ struct cfg80211_bss *b)
+{
+ const u8 *ie1;
+ const u8 *ie2;
+ size_t ielen;
+ int i;
+ int r;
+
+ r = cmp_bss_core(a, b);
+ if (r)
+ return r;
+
+ ie1 = cfg80211_find_ie(WLAN_EID_SSID,
+ a->information_elements,
+ a->len_information_elements);
+ ie2 = cfg80211_find_ie(WLAN_EID_SSID,
+ b->information_elements,
+ b->len_information_elements);
+
+ /* Absence of SSID or zero-sized SSID is used as
+ * an indication of the hidden bss. */
+ if (!ie2 || !ie2[1])
+ return 0;
+
+ /* It should not happen, but let's try to keep semantics
+ * (-1 means "lesser"). */
+ if (WARN_ON(!ie1))
+ return -1;
+
+ /* Key comparator must use same algorithm in any rb-tree
+ * search function (order is important), otherwise ordering
+ * of items in the tree is broken and search gives incorrect
+ * results. This code uses same order as cmp_ies() does.
+ *
+ * The only difference is that this code searchs for zeroed
+ * SSID ie (another indication of the hidden bss). */
+ ielen = min(ie1[1], ie2[1]);
+ for (i = 0; i < ielen; i++)
+ if (ie2[i + 2])
+ return -1;
+ return ie2[1] - ie1[1];
+}
+
struct cfg80211_bss *cfg80211_get_bss(struct wiphy *wiphy,
struct ieee80211_channel *channel,
const u8 *bssid,
@@ -475,6 +527,48 @@ rb_find_bss(struct cfg80211_registered_device *dev,
}
static struct cfg80211_internal_bss *
+rb_find_hidden_bss(struct cfg80211_registered_device *dev,
+ struct cfg80211_internal_bss *res)
+{
+ struct rb_node *n = dev->bss_tree.rb_node;
+ struct cfg80211_internal_bss *bss;
+ int r;
+
+ while (n) {
+ bss = rb_entry(n, struct cfg80211_internal_bss, rbn);
+ r = cmp_hidden_bss(&res->pub, &bss->pub);
+
+ if (r == 0)
+ return bss;
+ else if (r < 0)
+ n = n->rb_left;
+ else
+ n = n->rb_right;
+ }
+
+ return NULL;
+}
+
+static void
+copy_hidden_ies(struct cfg80211_internal_bss *res,
+ struct cfg80211_internal_bss *hidden)
+{
+ if (unlikely(res->pub.beacon_ies))
+ return;
+ if (WARN_ON(!hidden->pub.beacon_ies))
+ return;
+
+ res->pub.beacon_ies = kmalloc(hidden->pub.len_beacon_ies, GFP_ATOMIC);
+ if (unlikely(!res->pub.beacon_ies))
+ return;
+
+ res->beacon_ies_allocated = true;
+ res->pub.len_beacon_ies = hidden->pub.len_beacon_ies;
+ memcpy(res->pub.beacon_ies, hidden->pub.beacon_ies,
+ res->pub.len_beacon_ies);
+}
+
+static struct cfg80211_internal_bss *
cfg80211_bss_update(struct cfg80211_registered_device *dev,
struct cfg80211_internal_bss *res)
{
@@ -587,6 +681,21 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
kref_put(&res->ref, bss_release);
} else {
+ struct cfg80211_internal_bss *hidden;
+
+ /* First check if the beacon is a probe response from
+ * a hidden bss. If so, copy beacon ies (with nullified
+ * ssid) into the probe response bss entry (with real ssid).
+ * It is required basically for PSM implementation
+ * (probe responses do not contain tim ie) */
+
+ /* TODO: The code is not trying to update existing probe
+ * response bss entries when beacon ies are
+ * getting changed. */
+ hidden = rb_find_hidden_bss(dev, res);
+ if (hidden)
+ copy_hidden_ies(res, hidden);
+
/* this "consumes" the reference */
list_add_tail(&res->list, &dev->bss_list);
rb_insert_bss(dev, res);
--
With best regards,
Dmitry
^ permalink raw reply related
* Re: [PATCH] cfg80211: merge in beacon ies of hidden bss.
From: Dmitry Tarnyagin @ 2011-11-03 21:12 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <CAB3XZEeaF+Vy+7THnh62Q2ZeH0oWLa6W=JZZNegUA9TeVdwFWw@mail.gmail.com>
Hi Eliad,
>> + if (!ie1 && !ie2)
>> + return 0;
>> + if (!ie1 || !ie2)
>> + return -1;
>> + ielen = min(ie1[1], ie2[1]);
>> + for (i = 0; i < ielen; ++i)
>> + if (ie2[i + 2])
>> + return -1;
>> + return ie2[1] - ie1[1];
>
> you don't account for the ssid = "" case.
>
Yes, true. And also incorrectly handle !ie2 case. I'll fix it.
>> +static int
>> +merge_hidden_ies(struct cfg80211_internal_bss *res,
[...]
>
> i think the "merge" here is a bit misleading - there is no actual merge.
> you copy the beacon_ies from the beacon, but we still end up with 2 bss nodes.
> your solution does workaround the specific psm problem, but we still
> end up with a duplicate bss conf node that will never get updated
> (because the beacons will update the "original" bss node).
>
Yes, correct. I'm addressing only the obvious PSM problem now.
Further implementation is a subject of a discussion.
> i guess this problem already exists with the current code.
> not sure what is the correct way solve it, though.
> maybe check for both the hidden name and the actual name?
>
The whole idea of multi-ssid list of bss'es is a bit unclear for me.
That is the benefit of having ssid ie as a part of the key in the tree?
Are there multi-ssid APs which broadcasts different ies (apart form ssid)
on the same bssid in real live?
If not, I'm thinking about a separate refcounted list of bss ies keeping
all bss information except ssid. But it is a quite big change, definitely
not for this commit.
Thank you and with best regards,
Dmitry
^ permalink raw reply
* Re: b43 scans wifi networks with old firmware only.
From: Roman V.Leon. @ 2011-11-03 20:22 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <4EB2AF44.7090102@lwfinger.net>
> On 11/03/2011 06:21 AM, Roman V.Leon. wrote:
>> Hello Gents.
>> I have problem with b43 driver 5.100.138, it's not scanning networks for
>> unknown reason. I have broadcom wifi card PCIID is 14e4:4315, linux kern
>> ver. is 3.0. When i'm trying to launch iwlist scan, i'm getting "no scan
>> results".
>>
>> for example:
>> sudo ifconfig wlan0 up
>> sudo iwlist wlan0 scan
>> No scan results.
>>
>> With the older driver 5.10.56.2808, i see normal scan results. If you
>> need
>> any more information, i will send.
>
> The condition you report is known. Broadcom changed the TX/RX header
> structure with firmware versions greater than 600, as shown by a 'dmesg
> | grep firmware'. Those changes are not implemented in b43 until kernel
> 3.2.
>
> These numbers are not b43 driver numbers, nor are they firmware numbers
> reported by b43. They are the versions of Broadcom drivers.
>
> If you look at
> http://wireless.kernel.org/en/users/Drivers/b43#firmwareinstallation,
> you will see that firmware should be extracted from Broadcom driver
> 5.100.138 "if you are using kernel 3.2 or newer". For older kernels you
> should extract firmware from the 5.10.56.27.3 of the Broadcom
> proprietary driver. Of course, 5.10.56.2808 will also work.
>
> You could also get those changes by employing a bleeding-edge version of
> compat-wireless. In that case, firmware from 5.100.138 would work.
>
> Larry
>
OK, Larry. Now I see. Thank you very much!
--
Cheers,
Roman V.Leon.
^ permalink raw reply
* Compat-wireless release for 2011-11-03 is baked
From: Compat-wireless cronjob account @ 2011-11-03 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
814862 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3523 - % of code consists of backport work
^ permalink raw reply
* [PATCH] ath9k: Improve debugfs printout for stations.
From: greearb @ 2011-11-03 18:33 UTC (permalink / raw)
To: linux-wireless, ath9k-devel; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
Add interface address so it can be mapped to a local
interface. Add max-ampdu and mpdu-density.
Print out the tid->baw_size
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 1c269f5... 3d3b44f... M drivers/net/wireless/ath/ath9k/ath9k.h
:100644 100644 327aa28... 8e7e57c... M drivers/net/wireless/ath/ath9k/debug.c
:100644 100644 93fbe6f... f8c87d3... M drivers/net/wireless/ath/ath9k/main.c
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/debug.c | 13 +++++++++----
drivers/net/wireless/ath/ath9k/main.c | 6 ++++--
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 1c269f5..3d3b44f 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -252,6 +252,7 @@ struct ath_node {
#ifdef CONFIG_ATH9K_DEBUGFS
struct list_head list; /* for sc->nodes */
struct ieee80211_sta *sta; /* station struct we're part of */
+ struct ieee80211_vif *vif; /* interface with which we're associated */
#endif
struct ath_atx_tid tid[WME_NUM_TID];
struct ath_atx_ac ac[WME_NUM_AC];
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 327aa28..8e7e57c 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -708,24 +708,29 @@ static ssize_t read_file_stations(struct file *file, char __user *user_buf,
len += snprintf(buf + len, size - len,
"Stations:\n"
- " tid: addr sched paused buf_q-empty an ac\n"
+ " tid: addr sched paused buf_q-empty an ac baw\n"
" ac: addr sched tid_q-empty txq\n");
spin_lock(&sc->nodes_lock);
list_for_each_entry(an, &sc->nodes, list) {
+ unsigned short ma = an->maxampdu;
+ if (ma == 0)
+ ma = 65535; /* see ath_lookup_rate */
len += snprintf(buf + len, size - len,
- "%pM\n", an->sta->addr);
+ "iface: %pM sta: %pM max-ampdu: %hu mpdu-density: %uus\n",
+ an->vif->addr, an->sta->addr, ma,
+ (unsigned int)(an->mpdudensity));
if (len >= size)
goto done;
for (q = 0; q < WME_NUM_TID; q++) {
struct ath_atx_tid *tid = &(an->tid[q]);
len += snprintf(buf + len, size - len,
- " tid: %p %s %s %i %p %p\n",
+ " tid: %p %s %s %i %p %p %hu\n",
tid, tid->sched ? "sched" : "idle",
tid->paused ? "paused" : "running",
skb_queue_empty(&tid->buf_q),
- tid->an, tid->ac);
+ tid->an, tid->ac, tid->baw_size);
if (len >= size)
goto done;
}
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 93fbe6f..f8c87d3 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -630,7 +630,8 @@ set_timer:
}
}
-static void ath_node_attach(struct ath_softc *sc, struct ieee80211_sta *sta)
+static void ath_node_attach(struct ath_softc *sc, struct ieee80211_sta *sta,
+ struct ieee80211_vif *vif)
{
struct ath_node *an;
an = (struct ath_node *)sta->drv_priv;
@@ -640,6 +641,7 @@ static void ath_node_attach(struct ath_softc *sc, struct ieee80211_sta *sta)
list_add(&an->list, &sc->nodes);
spin_unlock(&sc->nodes_lock);
an->sta = sta;
+ an->vif = vif;
#endif
if (sc->sc_flags & SC_OP_TXAGGR) {
ath_tx_node_init(sc, an);
@@ -1798,7 +1800,7 @@ static int ath9k_sta_add(struct ieee80211_hw *hw,
struct ath_node *an = (struct ath_node *) sta->drv_priv;
struct ieee80211_key_conf ps_key = { };
- ath_node_attach(sc, sta);
+ ath_node_attach(sc, sta, vif);
if (vif->type != NL80211_IFTYPE_AP &&
vif->type != NL80211_IFTYPE_AP_VLAN)
--
1.7.3.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox