* Re: Performance problems with Netgear WNDAP350
From: Sujith Manoharan @ 2013-09-10 8:37 UTC (permalink / raw)
To: Seth Forshee; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <20130909212544.GA27771@thinkpad-t410>
Seth Forshee wrote:
> I posted some wireshark traces in case someone else can find something
> else informative that I've missed. They're at
> http://people.canonical.com/~sforshee/wndap350/:
>
> * iperf-iwlwifi.pcapng.gz: Trace from iperf client on Linux STA with
> iwlwifi
> * iperf-server.pcapng.gz: Trace from the iperf server for the same test
> as iperf-iwlwifi
> * iperf-osx.pcapng.gz: Trace from iperf client on OSX, using Broadcom
> wireless
The link with the iwlwifi client seems to be drowning in RTS/CTS exchanges
compared with the osx client.
iwlwifi: total: 109087, RTS - 9782 (9.0 %)
osx: total: 522581, RTS - 8366 (1.6 %)
Sujith
^ permalink raw reply
* Re: Always send management frames at MCS-0??
From: Sujith Manoharan @ 2013-09-10 8:10 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org, hostap@lists.shmoo.com
In-Reply-To: <522E1D31.2090403@candelatech.com>
Ben Greear wrote:
> I had a user request that we support always sending management frames
> (such as EAPOL) at the lowest rate. Evidently, other equipment does this,
> where as normal-ish supplicant/linux tends to send them at much higher
> rates.
>
> Any suggestions on how to go about doing this properly?
If this is with ath9k_rate_control, then it is a known bug:
https://bugzilla.redhat.com/show_bug.cgi?id=927191
Sujith
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Arend van Spriel @ 2013-09-10 7:59 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130909192346.GC1955@tuxdriver.com>
On 09/09/2013 09:23 PM, John W. Linville wrote:
> Arend, Kalle, Johannes, Luca, etc -- anyone want to talk about driver
> developments and/or issues between drivers and mac80211 or other
> parts of the stack?
Hi John
Because of personal reasons I am not attending this year. I would have
loved to celebrate my birthday in New Orleans and have a couple of beers
with you guys. Oh well. Guess I owe you.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 12/12] wlcore: always register dummy hardirq
From: Luca Coelho @ 2013-09-10 7:50 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-12-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> From: Arik Nemtsov <arik@wizery.com>
>
> This keeps the kernel happy when using edge-irqs and requesting a
> threaded irq.
>
> Signed-off-by: Arik Nemtsov <arik@wizery.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
Ouch, I think this is not going to fit at all with the DT patches I
sent.
BTW, someone should probably take over those patches, rework according
to the reviews and submit them again, as I don't think I'll have the
time to rework them anytime soon... :(
--
Luca.
^ permalink raw reply
* Re: [PATCH 11/12] wl18xx: print new RDL versions during boot
From: Luca Coelho @ 2013-09-10 7:47 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-11-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> From: Victor Goldenshtein <victorg@ti.com>
>
> Extract and print info for the new RDL 5, 6, 7 and 8.
> Replace const struct with function which translates
> the RDL number to string.
>
> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
> Signed-off-by: Barak Bercovitz <barak@wizery.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
Why convert the array with a function? The array looks much cleaner to
me.
[...[
> diff --git a/drivers/net/wireless/ti/wl18xx/main.c b/drivers/net/wireless/ti/wl18xx/main.c
> index b47eb62..aef0c91 100644
> --- a/drivers/net/wireless/ti/wl18xx/main.c
> +++ b/drivers/net/wireless/ti/wl18xx/main.c
> @@ -1228,16 +1228,46 @@ static u32 wl18xx_ap_get_mimo_wide_rate_mask(struct wl1271 *wl,
> }
> }
>
> +static const char *wl18xx_rdl_name(enum wl18xx_rdl_num rdl_num)
> +{
> + switch (rdl_num) {
> + case RDL_1_HP:
> + return "183xH";
> + case RDL_2_SP:
> + return "183x or 180x";
> + case RDL_3_HP:
> + return "187xH";
> + case RDL_4_SP:
> + return "187x";
> + case RDL_5_SP:
> + return "RDL11 - Not Supported";
> + case RDL_6_SP:
> + return "180xD";
> + case RDL_7_SP:
> + return "RDL13 - Not Supported (1893Q)";
> + case RDL_8_SP:
> + return "18xxQ";
> + default:
> + return "UNTRIMMED";
This may become misleading if we get more RDLs versions in the future.
And the untrimmed case is probably reporting 0? Or something predefined,
hopefully, otherwise how can we know that we wouldn't randomly get a
valid value?
Also, in the unsupported cases, it would probably be better to bail out?
--
Luca.
^ permalink raw reply
* Re: [PATCH 09/12] wlcore: fix regulatory domain bit translation
From: Luca Coelho @ 2013-09-10 7:39 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-9-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> From: Ido Reis <idor@ti.com>
>
> This is a fix for channels 52,56,60,64 bit translation.
>
> Reported-by: Yaniv Machani <yanivma@ti.com>
> Signed-off-by: Ido Reis <idor@ti.com>
> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
> drivers/net/wireless/ti/wlcore/cmd.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/cmd.c b/drivers/net/wireless/ti/wlcore/cmd.c
> index e3ae425..1cb3296 100644
> --- a/drivers/net/wireless/ti/wlcore/cmd.c
> +++ b/drivers/net/wireless/ti/wlcore/cmd.c
> @@ -1613,8 +1613,10 @@ static int wlcore_get_reg_conf_ch_idx(enum ieee80211_band band, u16 ch)
> case IEEE80211_BAND_5GHZ:
> if (ch >= 8 && ch <= 16)
> idx = ((ch-8)/4 + 18);
> - else if (ch >= 34 && ch <= 64)
> + else if (ch >= 34 && ch <= 48)
> idx = ((ch-34)/2 + 3 + 18);
> + else if (ch >= 52 && ch <= 64)
> + idx = ((ch-52)/4 + 11 + 18);
> else if (ch >= 100 && ch <= 140)
> idx = ((ch-100)/4 + 15 + 18);
> else if (ch >= 149 && ch <= 165)
Hmmm... I don't have a clue what is going on here. I don't know how I
let this function pass as is originally, shame on me. :)
The change probably makes things work better, since someone apparently
saw a bug in real life and reported it, but can anyone explain what is
going on during this translation? Aren't we losing data here? Eg.
channels 8, 9, 10 and 11 all use the same bit in the firmware command
bitmask?
--
Luca.
^ permalink raw reply
* Re: beginner build question
From: Christian Lamparter @ 2013-09-10 7:34 UTC (permalink / raw)
To: Brian O'Connor; +Cc: linux-wireless
In-Reply-To: <CAHhaCVh_etgA1aoSur5shtduCbk9R-zuya8sBKu90A9M_Kj6qg@mail.gmail.com>
Hello Brain,
On Tuesday 10 September 2013 07:27:39 Brian O'Connor wrote:
> Thanks for getting back to me. I've run into another issue:
>
> # note the extra / before r92su
> $ sudo make load
> insmod /r92su/r92su.ko
> Error: could not load module /r92su/r92su.ko: No such file or directory
> make: *** [load] Error 1
Ok, apparently $(PWD) is not available on all shells?
<http://patchwork.coreboot.org/patch/2002/>
[Should be fixed now]
> # so I manually run
> $ sudo insmod r92su/r92su.ko
> Error: could not insert module r92su/r92su.ko: Unknown symbol in module
>
> $ dmesg
> ...
> [ 2066.923259] r92su: module verification failed: signature and/or required key missing - tainting kernel
Well, there's not much I can do for now. r92su is a unofficial module.
> [ 2066.923332] r92su: Unknown symbol cfg80211_scan_done (err 0)
> [ 2066.923362] r92su: Unknown symbol ieee80211_amsdu_to_8023s (err 0)
> [ 2066.923386] r92su: Unknown symbol ieee80211_data_from_8023 (err 0)
> [ 2066.923403] r92su: Unknown symbol cfg80211_disconnected (err 0)
> [ 2066.923432] r92su: Unknown symbol wiphy_register (err 0)
> [ 2066.923442] r92su: Unknown symbol wiphy_new (err 0)
> [ 2066.923451] r92su: Unknown symbol cfg80211_put_bss (err 0)
> [ 2066.923461] r92su: Unknown symbol cfg80211_inform_bss (err 0)
> [ 2066.923478] r92su: Unknown symbol cfg80211_ibss_joined (err 0)
> [ 2066.923496] r92su: Unknown symbol cfg80211_michael_mic_failure (err 0)
> [ 2066.923508] r92su: Unknown symbol cfg80211_connect_result (err 0)
> [ 2066.923527] r92su: Unknown symbol wiphy_unregister (err 0)
> [ 2066.923546] r92su: Unknown symbol cfg80211_get_bss (err 0)
> [ 2066.923576] r92su: Unknown symbol ieee80211_data_to_8023 (err 0)
> [ 2066.923597] r92su: Unknown symbol ieee80211_hdrlen (err 0)
> [ 2066.923615] r92su: Unknown symbol ieee80211_frequency_to_channel (err 0)
> [ 2066.923634] r92su: Unknown symbol cfg80211_unlink_bss (err 0)
> [ 2066.923644] r92su: Unknown symbol wiphy_free (err 0)
insmod doesn't load any dependent modules.
(In this case all that's missing is: cfg80211 - the new
makefile should take care of that)
> [ 2233.171269] r8712u 2-4:1.0 wlan0: r8712_got_addbareq_event_callback: mac = c8:d7:19:xx:xx:xx, seq = 10528, tid = 2
Ah, unload r8712u before loading r92su [else, r92su won't control the device].
modprobe -r r8712u
If r92su works and you want to stick with it for the time, you can
blacklist r8712u. AFAICT, you just have to follow the instruction at
<https://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/rescuemode_drivers-blacklisting.html>
Regards
Christian
^ permalink raw reply
* Re: [PATCH 07/12] wlcore: cleanup scan debug prints
From: Luca Coelho @ 2013-09-10 7:19 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-7-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> From: Victor Goldenshtein <victorg@ti.com>
>
> Remove scan debug dumps which are rarely used.
> Make scan debug prints more clear and short.
>
> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
This is fine, these dumps were used when the firmware scan APIs were
changing all the time and we were having lots of problems following it.
It can be removed now to reduce excessive output.
Some nitpicks below.
[...]
> diff --git a/drivers/net/wireless/ti/wlcore/scan.c b/drivers/net/wireless/ti/wlcore/scan.c
> index f407101..bbe0bc4 100644
> --- a/drivers/net/wireless/ti/wlcore/scan.c
> +++ b/drivers/net/wireless/ti/wlcore/scan.c
> @@ -174,17 +174,7 @@ wlcore_scan_get_channels(struct wl1271 *wl,
> /* if radar is set, we ignore the passive flag */
> (radar ||
> !!(flags & IEEE80211_CHAN_PASSIVE_SCAN) == passive)) {
> - wl1271_debug(DEBUG_SCAN, "band %d, center_freq %d ",
> - req_channels[i]->band,
> - req_channels[i]->center_freq);
> - wl1271_debug(DEBUG_SCAN, "hw_value %d, flags %X",
> - req_channels[i]->hw_value,
> - req_channels[i]->flags);
> - wl1271_debug(DEBUG_SCAN, "max_power %d",
> - req_channels[i]->max_power);
> - wl1271_debug(DEBUG_SCAN, "min_dwell_time %d max dwell time %d",
> - min_dwell_time_active,
> - max_dwell_time_active);
> +
>
Unnecessary extra line here.
[...]
> @@ -222,6 +212,18 @@ wlcore_scan_get_channels(struct wl1271 *wl,
> *n_pactive_ch);
> }
>
> + wl1271_debug(DEBUG_SCAN, "freq %04d, ch. %03d, flags 0x%02X, power %02d, min/max_dwell %02d/%02d%s%s",
Left-padding with zeros is quite ugly with the decimals here.
--
Luca.
^ permalink raw reply
* Re: [PATCH 02/12] wlcore: add new plt power-mode: CHIP_AWAKE
From: Luca Coelho @ 2013-09-10 6:56 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: Eliad Peller, linux-wireless@vger.kernel.org
In-Reply-To: <CA+XVXfdiudFgdXVAugkHVBLPVgLyrsokosCyhpNd5c5G7DOcOg@mail.gmail.com>
On Tue, 2013-09-10 at 08:47 +0200, Arik Nemtsov wrote:
> On Tue, Sep 10, 2013 at 9:33 AM, Luca Coelho <luca@coelho.fi> wrote:
> > On Tue, 2013-09-03 at 17:33 +0300, Eliad Peller wrote:
> >> From: Yair Shapira <yair.shapira@ti.com>
> >>
> >> Under this mode the chip is powered on including sdio
> >> but no FW is downloaded and run, interrupts are not enabled, etc...
> >>
> >> This mode is intended to allow RTTT to bridge sdio as a transport
> >> to the chip.
> >>
> >> Driver only provides sdio access using the dev_mem debugfs file.
> >>
> >> Some fixes done to the code that ensures that PLT mode and normal
> >> driver power mode (ifconfig/add_interface) are mutually excluded.
> >>
> >> Signed-off-by: Yair Shapira <yair.shapira@ti.com>
> >> Signed-off-by: Eliad Peller <eliad@wizery.com>
> >> ---
> >
> > I had some comments to this patch internally while I was still at TI.
> > Namely, I asked why do we need a new way of doing this if this is
> > already possible via debugsfs (using the gpio_power file)?
>
> Are you commenting on the correct patch? Seems this is just a patch to
> prevent "ifconfig up" during PLT mode..
Yes, I'm commenting on the right patch. It allows the chip power
(namely the WLAN_EN GPIO pin) to be set directly, without loading the
firmware and doing other initialization stuff. This can already be
controlled via the gpio_power debugfs file. I've used that a bunch of
times, including with the RTTT tool.
Okay, this patch has a few more protections (eg. not allowing an
interface to be added while the chip is powered in this way), but this
could also be added on top of the existing implementation.
--
Luca.
^ permalink raw reply
* Re: [PATCH 02/12] wlcore: add new plt power-mode: CHIP_AWAKE
From: Arik Nemtsov @ 2013-09-10 6:47 UTC (permalink / raw)
To: Luca Coelho; +Cc: Eliad Peller, linux-wireless@vger.kernel.org
In-Reply-To: <1378794813.4799.35.camel@porter.coelho.fi>
On Tue, Sep 10, 2013 at 9:33 AM, Luca Coelho <luca@coelho.fi> wrote:
> On Tue, 2013-09-03 at 17:33 +0300, Eliad Peller wrote:
>> From: Yair Shapira <yair.shapira@ti.com>
>>
>> Under this mode the chip is powered on including sdio
>> but no FW is downloaded and run, interrupts are not enabled, etc...
>>
>> This mode is intended to allow RTTT to bridge sdio as a transport
>> to the chip.
>>
>> Driver only provides sdio access using the dev_mem debugfs file.
>>
>> Some fixes done to the code that ensures that PLT mode and normal
>> driver power mode (ifconfig/add_interface) are mutually excluded.
>>
>> Signed-off-by: Yair Shapira <yair.shapira@ti.com>
>> Signed-off-by: Eliad Peller <eliad@wizery.com>
>> ---
>
> I had some comments to this patch internally while I was still at TI.
> Namely, I asked why do we need a new way of doing this if this is
> already possible via debugsfs (using the gpio_power file)?
Are you commenting on the correct patch? Seems this is just a patch to
prevent "ifconfig up" during PLT mode..
^ permalink raw reply
* Re: [PATCH 06/12] wlcore: send EAPOL frames with voice priority
From: Luca Coelho @ 2013-09-10 6:47 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-6-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> From: Igal Chernobelsky <igalc@ti.com>
>
> Send EAPOL frames with voice priority by setting TX_HW_ATTR_EAPOL_FRAME
> new bit in tx attribute. Sending EAPOL with voice priority fixes
> re-key timeout during heavy traffic issue.
>
> Signed-off-by: Igal Chernobelsky <igalc@ti.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
This seems to be the same problem that Ben had and debugged by himself
[1]. Fixing this in hostapd/wpa_supplicant seems more appropriate?
This patch seems to take an advantage of some sort of hack in the
firmware that will change the priority by itself when the
TX_HW_ATTR_EAPOL_GRAME bit is set. If we have a good reason to use this
patch, we need to take care of the firmware version as well. This
probably doesn't work with the latest published firmware.
[1] http://mid.gmane.org/522E18E5.1020503@candelatech.com
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 05/12] wl18xx: increase the number of allowed BA sessions
From: Luca Coelho @ 2013-09-10 6:39 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-5-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> From: Victor Goldenshtein <victorg@ti.com>
>
> The current fw (actually starting from fw 8.5.0.0.58)
> supports 8 rx BA sessions.
>
> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
The latest firmware version published at linux-firmware.git is
8.5.0.0.55 (wl18xx-fw-2.bin), so this patch cannot be taken into the
official tree yet.
Please publish a newer version of the firmware (with appropriate
increase in the filename version), since I cannot do that myself
anymore.
--
Luca.
^ permalink raw reply
* [PATCH 1/1] net: ath9k: Use NULL instead of false
From: Sachin Kamat @ 2013-09-10 6:20 UTC (permalink / raw)
To: linux-wireless
Cc: ath9k-devel, netdev, mcgrof, jouni, vthiagar, senthilb, linville,
sachin.kamat
The function returns a pointer. Hence return NULL instead of false.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/net/wireless/ath/ath9k/dfs_pri_detector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c b/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c
index 5ba4b6f..c718fc3 100644
--- a/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c
+++ b/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c
@@ -392,7 +392,7 @@ static struct pri_sequence *pri_detector_add_pulse(struct pri_detector *de,
if (!pseq_handler_create_sequences(de, ts, max_updated_seq)) {
pri_detector_reset(de, ts);
- return false;
+ return NULL;
}
ps = pseq_handler_check_detection(de);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 03/12] wlcore: disable elp sleep while in plt mode
From: Luca Coelho @ 2013-09-10 6:34 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-3-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:33 +0300, Eliad Peller wrote:
> From: Yair Shapira <yair.shapira@ti.com>
>
> We now disable elp sleep during plt mode to allow normal operation of
> plt tools such as calibrator.
>
> Having elp_sleep enabled during plt mode is actually not required and
> in fact it disrupt plt operations such as rx statistics etc.
>
> Signed-off-by: Yair Shapira <yair.shapira@ti.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
I also had a comment internally about this one. Why do we need this?
AFAICT this would never happen in real life, since the firmware is not
even loaded at this point. Is there any real life situation where we
try to go into ELP while in PLT mode?
--
Luca.
^ permalink raw reply
* Re: [PATCH 02/12] wlcore: add new plt power-mode: CHIP_AWAKE
From: Luca Coelho @ 2013-09-10 6:33 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-2-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:33 +0300, Eliad Peller wrote:
> From: Yair Shapira <yair.shapira@ti.com>
>
> Under this mode the chip is powered on including sdio
> but no FW is downloaded and run, interrupts are not enabled, etc...
>
> This mode is intended to allow RTTT to bridge sdio as a transport
> to the chip.
>
> Driver only provides sdio access using the dev_mem debugfs file.
>
> Some fixes done to the code that ensures that PLT mode and normal
> driver power mode (ifconfig/add_interface) are mutually excluded.
>
> Signed-off-by: Yair Shapira <yair.shapira@ti.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
I had some comments to this patch internally while I was still at TI.
Namely, I asked why do we need a new way of doing this if this is
already possible via debugsfs (using the gpio_power file)?
--
Cheers,
Luca.
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Luca Coelho @ 2013-09-10 6:28 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130909192346.GC1955@tuxdriver.com>
Hi John,
On Mon, 2013-09-09 at 15:23 -0400, John W. Linville wrote:
> Arend, Kalle, Johannes, Luca, etc -- anyone want to talk about driver
> developments and/or issues between drivers and mac80211 or other
> parts of the stack?
Unfortunately I didn't get "sponsorship" to join the summit this year.
Second one (for different reasons) that I'll miss in a row. Hopefully
next time I'll be there.
Have fun! :)
--
Cheers,
Luca.
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Mark Cave-Ayland @ 2013-09-10 5:58 UTC (permalink / raw)
To: Larry Finger; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522E896E.7000607@lwfinger.net>
On 10/09/13 03:52, Larry Finger wrote:
> We now know that the beacons are being lost. The last one was at
> 90600.642566 as shown below:
>
> Sep 10 00:29:48 kentang kernel: [90599.513526] rtlwifi: mode 2, state 2,
> is_beacon 1, is_probe_resp 0, length 153
> Sep 10 00:29:50 kentang kernel: [90600.642566] rtlwifi: mode 2, state 2,
> is_beacon 1, is_probe_resp 0, length 153
> Sep 10 00:29:57 kentang kernel: [90607.829051]
> rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to reconnect now
> Sep 10 00:29:57 kentang kernel: [90607.829058] wlan1: Connection to AP
> 00:1f:9f:d5:a8:3b lost
> Sep 10 00:29:57 kentang kernel: [90607.830086] cfg80211: Calling CRDA to
> update world regulatory domain
>
> We have to conclude that your interface has been shut down as we have
> gotten no beacons or RX data packets received. Unfortunately, my
> restricting the output to only your AP does not let me know if any data
> are being received. I hate to do this, but the attached patch will dump
> all packets again with no limit. Once you get a disconnect, then you can
> stop the run before the log gets too full.
No worries - disk space is reasonably cheap these days ;)
dmesg output:
http://www.ilande.co.uk/tmp/rtl8192cu_patch-4-dmesg.txt
wpa_supplicant output:
http://www.ilande.co.uk/tmp/rtl8192cu_patch-4-wpa_supplicant.txt
I noticed that I got several re-authentication attempts in the dmesg
output without the corresponding rtl_watchdog_wq_callback() line being
emitted - this is again something I don't see with zd1211rw and iwlwifi.
Once these drivers are associated, they seem to stay in that state for
hours.
Whilst checking various parts of my kernel, I noticed for the first time
during testing that my current kernel configuration doesn't have SMP
enabled. This got me thinking that perhaps there are other build options
which could have an effect on the driver. Hence I also uploaded a copy
of my .config file to http://www.ilande.co.uk/tmp/rtl8192cu-config in
the hope that maybe this can help you recreate the issue locally?
ATB,
Mark.
^ permalink raw reply
* Re: beginner build question
From: Brian O'Connor @ 2013-09-10 5:27 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <1781136.IRflOffuSs@blech>
Hi Christian,
Thanks for getting back to me. I've run into another issue:
# note the extra / before r92su
$ sudo make load
insmod /r92su/r92su.ko
Error: could not load module /r92su/r92su.ko: No such file or directory
make: *** [load] Error 1
# so I manually run
$ sudo insmod r92su/r92su.ko
Error: could not insert module r92su/r92su.ko: Unknown symbol in module
$ dmesg
...
[ 2066.923259] r92su: module verification failed: signature and/or
required key missing - tainting kernel
[ 2066.923332] r92su: Unknown symbol cfg80211_scan_done (err 0)
[ 2066.923362] r92su: Unknown symbol ieee80211_amsdu_to_8023s (err 0)
[ 2066.923386] r92su: Unknown symbol ieee80211_data_from_8023 (err 0)
[ 2066.923403] r92su: Unknown symbol cfg80211_disconnected (err 0)
[ 2066.923432] r92su: Unknown symbol wiphy_register (err 0)
[ 2066.923442] r92su: Unknown symbol wiphy_new (err 0)
[ 2066.923451] r92su: Unknown symbol cfg80211_put_bss (err 0)
[ 2066.923461] r92su: Unknown symbol cfg80211_inform_bss (err 0)
[ 2066.923478] r92su: Unknown symbol cfg80211_ibss_joined (err 0)
[ 2066.923496] r92su: Unknown symbol cfg80211_michael_mic_failure (err 0)
[ 2066.923508] r92su: Unknown symbol cfg80211_connect_result (err 0)
[ 2066.923527] r92su: Unknown symbol wiphy_unregister (err 0)
[ 2066.923546] r92su: Unknown symbol cfg80211_get_bss (err 0)
[ 2066.923576] r92su: Unknown symbol ieee80211_data_to_8023 (err 0)
[ 2066.923597] r92su: Unknown symbol ieee80211_hdrlen (err 0)
[ 2066.923615] r92su: Unknown symbol ieee80211_frequency_to_channel (err 0)
[ 2066.923634] r92su: Unknown symbol cfg80211_unlink_bss (err 0)
[ 2066.923644] r92su: Unknown symbol wiphy_free (err 0)
[ 2233.171269] r8712u 2-4:1.0 wlan0:
r8712_got_addbareq_event_callback: mac = c8:d7:19:xx:xx:xx, seq =
10528, tid = 2
Any idea? I would be happy to provide more debugging if it helps.
Thanks,
Brian
On Fri, Sep 6, 2013 at 3:21 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> Hello,
>
> On Friday, September 06, 2013 02:27:26 AM Brian O'Connor wrote:
>> I am trying to compile rtl8192su in Ubuntu 13.04 and I get the
>> following error when I "make all":
>>
>> make -C /lib/modules/3.10.10-031010-generic/build
>> M=/home/media/rtl8192su/r92su CONFIG_R92SU=m CONFIG_R92SU_DEBUGFS=y
>> CONFIG_R92SU_WPC=y all EXTRA_CFLAGS="-DDEBUG -DCONFIG_R92SU=m
> ^^^
>> -DCONFIG_R92SU_DEBUGFS=y -DCONFIG_R92SU_WPC=y"
>> make[1]: Entering directory `/usr/src/linux-headers-3.10.10-031010-generic'
>> make[1]: *** No rule to make target `vmlinux', needed by `all'. Stop.
>> make[1]: Leaving directory `/usr/src/linux-headers-3.10.10-031010-generic'
>> make: *** [all] Error 2
>>
>> Any suggestions?
> Thanks for reporting this. I fixed the project's readme.
> <https://github.com/chunkeey/rtl8192su/commit/d1934e155840ccd273a429d85f1f2aa407ba49b7>
>
> Just run "make" instead of "make all".
>
> Regards
>
> Chr
>
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Larry Finger @ 2013-09-10 2:52 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522E5D83.9060103@ilande.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]
On 09/09/2013 06:45 PM, Mark Cave-Ayland wrote:
> dmesg output:
> http://www.ilande.co.uk/tmp/rtl8192cu_patch-3-dmesg.txt
>
> wpa_supplicant output:
> http://www.ilande.co.uk/tmp/rtl8192cu_patch-3-wpa_supplicant.txt
>
> Now the interesting part was as you can see from the logs, I managed to get a
> reasonably long association to the AP towards the end so I tried running
> dhclient against the wlan1 interface - this was slow, taking about 60s to
> complete, but it did eventually return with an IP address. With that in place, I
> tried pinging 8.8.8.8 and ended up with a very poor connection, with the ping
> exit banner reporting 87% packet loss :(
We now know that the beacons are being lost. The last one was at 90600.642566 as
shown below:
Sep 10 00:29:48 kentang kernel: [90599.513526] rtlwifi: mode 2, state 2,
is_beacon 1, is_probe_resp 0, length 153
Sep 10 00:29:50 kentang kernel: [90600.642566] rtlwifi: mode 2, state 2,
is_beacon 1, is_probe_resp 0, length 153
Sep 10 00:29:57 kentang kernel: [90607.829051]
rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to reconnect now
Sep 10 00:29:57 kentang kernel: [90607.829058] wlan1: Connection to AP
00:1f:9f:d5:a8:3b lost
Sep 10 00:29:57 kentang kernel: [90607.830086] cfg80211: Calling CRDA to update
world regulatory domain
We have to conclude that your interface has been shut down as we have gotten no
beacons or RX data packets received. Unfortunately, my restricting the output to
only your AP does not let me know if any data are being received. I hate to do
this, but the attached patch will dump all packets again with no limit. Once you
get a disconnect, then you can stop the run before the log gets too full.
Larry
[-- Attachment #2: rtl8192cu_dump_AP_off --]
[-- Type: text/plain, Size: 1709 bytes --]
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/usb.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/usb.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/usb.c
@@ -484,6 +484,8 @@ static void _rtl_usb_rx_process_agg(stru
if (unicast)
rtlpriv->link_info.num_rx_inperiod++;
}
+ /* static bcn for roaming */
+ rtl_beacon_statistic(hw, skb);
}
}
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/core.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/core.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/core.c
@@ -184,6 +184,7 @@ static int rtl_op_add_interface(struct i
rtlpriv->cfg->maps
[RTL_IBSS_INT_MASKS]);
}
+ mac->link_state = MAC80211_LINKED;
break;
case NL80211_IFTYPE_ADHOC:
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_LOUD,
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/base.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/base.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/base.c
@@ -1288,6 +1288,10 @@ void rtl_beacon_statistic(struct ieee802
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
+ pr_info("mode %d, state %d, is_beacon %d, is_probe_resp %d, length %d\n",
+ rtlpriv->mac80211.opmode, rtlpriv->mac80211.link_state, ieee80211_is_beacon(hdr->frame_control),
+ ieee80211_is_probe_resp(hdr->frame_control), skb->len);
+
if (rtlpriv->mac80211.opmode != NL80211_IFTYPE_STATION)
return;
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Mark Cave-Ayland @ 2013-09-09 23:45 UTC (permalink / raw)
To: Larry Finger; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522E5416.4010901@lwfinger.net>
On 10/09/13 00:04, Larry Finger wrote:
>> I also tried another experiment which was to change your patch so that
>> instead
>> of logging just the first 100 beacons to dmesg, log every 10th beacon
>> (count %
>> 10) to dmesg instead. This showed that even when the timeouts are
>> occurring
>> against the AP, I'm still seeing a continual stream of beacons from other
>> stations on the network.
>
> Looking at only every 10th one could be systematically missing the ones
> from your AP.
Oh sure - what I was looking to prove was whether it was all beacons
that weren't getting through, or just the ones from the AP when the
timeout occurred.
>> This makes me wonder if Oleksij is correct in that the problem is that
>> not all
>> the frames coming from the USB interface are being picked up by the
>> driver.
>> Perhaps not all incoming USB RX buffers are being scanned (causing
>> some queued
>> frames to be lost) or maybe USB transfers can contain more than 1
>> frame and
>> rtlwifi is only catching the first frame within each notified transfer?
>
> None of those suppositions make any sense.
Well I freely admit that I don't have much knowledge of the kernel USB
layers (only from some old embedded systems years ago), so it was really
just a case of thinking out loud...
>> To double check whether it was a general ehci-pci problem, I tried
>> plugging in a
>> spare zd1211rw dongle and that worked absolutely fine. So I think
>> that's a
>> reasonable indication that general USB function is okay.
>
> I do not suspect any USB problem unless it is in rtl8192cu.
Okay.
> Could you please run the attached patch? It will only print messages for
> your AP, and print enough to still be getting them when the AP timeout
> occurs.
Done.
dmesg output:
http://www.ilande.co.uk/tmp/rtl8192cu_patch-3-dmesg.txt
wpa_supplicant output:
http://www.ilande.co.uk/tmp/rtl8192cu_patch-3-wpa_supplicant.txt
Now the interesting part was as you can see from the logs, I managed to
get a reasonably long association to the AP towards the end so I tried
running dhclient against the wlan1 interface - this was slow, taking
about 60s to complete, but it did eventually return with an IP address.
With that in place, I tried pinging 8.8.8.8 and ended up with a very
poor connection, with the ping exit banner reporting 87% packet loss :(
ATB,
Mark.
^ permalink raw reply
* Re: Always send management frames at MCS-0??
From: Ben Greear @ 2013-09-09 23:10 UTC (permalink / raw)
To: Krishna Chaitanya; +Cc: linux-wireless@vger.kernel.org, hostap@lists.shmoo.com
In-Reply-To: <CABPxzYLaLUdCXULmx7mV5Gk7L_RrnG4Zq-vO6XRCUt0pvm9SJA@mail.gmail.com>
On 09/09/2013 12:15 PM, Krishna Chaitanya wrote:
> On Tue, Sep 10, 2013 at 12:40 AM, Ben Greear <greearb@candelatech.com> wrote:
>> I had a user request that we support always sending management frames
>> (such as EAPOL) at the lowest rate. Evidently, other equipment does this,
>> where as normal-ish supplicant/linux tends to send them at much higher
>> rates.
>>
>> Any suggestions on how to go about doing this properly?
>>
>> Any opinions on whether it's a good idea or not?
>
> EAPOL frames are data frams from WLAN perspective
> and are unicast, thats why we send at highest possible
> MCS supported. There is no advantage in forcing them to
> go at lower rates.
>
Would forcing them to a lower rate at least theoretically improve
the chance that the packets are properly delivered?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Larry Finger @ 2013-09-09 23:04 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522E463E.4040701@ilande.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]
On 09/09/2013 05:05 PM, Mark Cave-Ayland wrote:
> On 09/09/13 20:03, Larry Finger wrote:
>
>> There were no secrets in that dump, but it did reveal a major clue.
>>
>> A response from your system for your AP was:
>>
>> mode 2, state 0, is_beacon 0, is_probe_resp 1, length 147
>>
>> For the number of beacons to be updated, the state has to be 2 or 3. My
>> system has scan_ssid=1 in the wpa_supplicant configuration file. When
>> the scan finishes, then a value of 2 is set into the mode variable.
>>
>> The attached updated patch should set the correct mode even if scanning
>> is not enabled.
>
> Aha! This patch is definitely a step in the right direction - with this applied,
> wpa_supplicant now associates immediately with the AP without the initial delay :)
>
> However... I'm still seeing the same "rtlwifi:rtl_watchdog_wq_callback():<0-0>
> AP off, try to reconnect now" message appearing in dmesg after every 10s or so.
> I've uploaded the updated dmesg output to
> http://www.ilande.co.uk/tmp/rtl8192cu_patch-2-dmesg.txt for you to take a look at.
>
> I also tried another experiment which was to change your patch so that instead
> of logging just the first 100 beacons to dmesg, log every 10th beacon (count %
> 10) to dmesg instead. This showed that even when the timeouts are occurring
> against the AP, I'm still seeing a continual stream of beacons from other
> stations on the network.
Looking at only every 10th one could be systematically missing the ones from
your AP.
> This makes me wonder if Oleksij is correct in that the problem is that not all
> the frames coming from the USB interface are being picked up by the driver.
> Perhaps not all incoming USB RX buffers are being scanned (causing some queued
> frames to be lost) or maybe USB transfers can contain more than 1 frame and
> rtlwifi is only catching the first frame within each notified transfer?
None of those suppositions make any sense.
> To double check whether it was a general ehci-pci problem, I tried plugging in a
> spare zd1211rw dongle and that worked absolutely fine. So I think that's a
> reasonable indication that general USB function is okay.
I do not suspect any USB problem unless it is in rtl8192cu.
Could you please run the attached patch? It will only print messages for your
AP, and print enough to still be getting them when the AP timeout occurs.
Thanks,
Larry
[-- Attachment #2: rtl8192cu_dump_AP_off --]
[-- Type: text/plain, Size: 2225 bytes --]
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/usb.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/usb.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/usb.c
@@ -484,6 +484,8 @@ static void _rtl_usb_rx_process_agg(stru
if (unicast)
rtlpriv->link_info.num_rx_inperiod++;
}
+ /* static bcn for roaming */
+ rtl_beacon_statistic(hw, skb);
}
}
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/core.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/core.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/core.c
@@ -184,6 +184,7 @@ static int rtl_op_add_interface(struct i
rtlpriv->cfg->maps
[RTL_IBSS_INT_MASKS]);
}
+ mac->link_state = MAC80211_LINKED;
break;
case NL80211_IFTYPE_ADHOC:
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_LOUD,
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/base.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/base.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/base.c
@@ -1287,6 +1287,17 @@ void rtl_beacon_statistic(struct ieee802
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
+ static int count;
+
+ /* and only beacons from the associated BSSID, please */
+ if (compare_ether_addr(hdr->addr3, rtlpriv->mac80211.bssid))
+ return;
+
+ if (count++ < 1200) {
+ pr_info("mode %d, state %d, is_beacon %d, is_probe_resp %d, length %d\n",
+ rtlpriv->mac80211.opmode, rtlpriv->mac80211.link_state, ieee80211_is_beacon(hdr->frame_control),
+ ieee80211_is_probe_resp(hdr->frame_control), skb->len);
+ }
if (rtlpriv->mac80211.opmode != NL80211_IFTYPE_STATION)
return;
@@ -1303,10 +1314,6 @@ void rtl_beacon_statistic(struct ieee802
if (skb->len <= 40 + FCS_LEN)
return;
- /* and only beacons from the associated BSSID, please */
- if (compare_ether_addr(hdr->addr3, rtlpriv->mac80211.bssid))
- return;
-
rtlpriv->link_info.bcn_rx_inperiod++;
}
EXPORT_SYMBOL_GPL(rtl_beacon_statistic);
^ permalink raw reply
* Re: [PATCH] ath10k: define ath10k_debug_start/_stop as static inline
From: Kalle Valo @ 2013-09-09 22:34 UTC (permalink / raw)
To: Bartosz Markowski; +Cc: ath10k, linux-wireless
In-Reply-To: <1378741845-30080-1-git-send-email-bartosz.markowski@tieto.com>
Bartosz Markowski <bartosz.markowski@tieto.com> writes:
> Otherwise if CONFIG_ATH10K_DEBUGFS won't be set we will
> end up with multiple definitions and compilation failure
> in each place the header is included.
>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Doh, I broke this. Sorry about that. Path applied, thanks for fixing
this.
--
Kalle Valo
^ permalink raw reply
* Re: No connection with TP-Link TL-WN823N (rtl8192cu)
From: Dan Williams @ 2013-09-09 22:15 UTC (permalink / raw)
To: Larry Finger; +Cc: Vincent Thiele, linux-wireless
In-Reply-To: <522E4315.4040806@lwfinger.net>
On Mon, 2013-09-09 at 16:52 -0500, Larry Finger wrote:
> On 09/09/2013 03:40 PM, Vincent Thiele wrote:
> > I use TL-WN823N usb-stick with ubuntu but native drivers disconnect
> > few seconds after boot. For wlan i need to install this package:
> > https://code.google.com/p/realtek-8188cus-wireless-drivers-3444749-ubuntu-1304/.
> > But this package can not be used with a kernel > 3.9. Please fix the
> > native drivers. Best regards
>
> I am sorry that you are having problems with your system, but your log was
> essentially useless. I saw one disconnect due to reason 4 (disassociation due to
> inactivity).
>
> There were many changes in the rtl8192cu driver for kernel 3.11, and you need to
> run it, or a backports version of the wireless code. Your 3.8.0 kernel is too old.
>
> I have been running rtl8192cu for the past 24 hours without a permanent
> disconnect. Under NetworkManager, I see some reason 7 deauthentications, but
Running wpa_supplicant with debugging on might shed some light on these;
basically:
mv /usr/sbin/wpa_supplicant /
killall -TERM wpa_supplicant
/wpa_supplicant -dddtu <piped to your favorite log file>
and NM should automatically reconnect, and then we can figure out what's
going on in the supplicant.
Dan
> running under ifup, there have been no disassociations or deauthentications in
> over 6 hours.
>
> I am using openSUSE KDE. There may be a problem with the Ubuntu user code as it
> seems to operate differently.
>
> Larry
>
> --
> 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: RTL8192CU continually reconnecting
From: Mark Cave-Ayland @ 2013-09-09 22:05 UTC (permalink / raw)
To: Larry Finger; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522E1B7D.5010107@lwfinger.net>
On 09/09/13 20:03, Larry Finger wrote:
> There were no secrets in that dump, but it did reveal a major clue.
>
> A response from your system for your AP was:
>
> mode 2, state 0, is_beacon 0, is_probe_resp 1, length 147
>
> For the number of beacons to be updated, the state has to be 2 or 3. My
> system has scan_ssid=1 in the wpa_supplicant configuration file. When
> the scan finishes, then a value of 2 is set into the mode variable.
>
> The attached updated patch should set the correct mode even if scanning
> is not enabled.
Aha! This patch is definitely a step in the right direction - with this
applied, wpa_supplicant now associates immediately with the AP without
the initial delay :)
However... I'm still seeing the same
"rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to reconnect now"
message appearing in dmesg after every 10s or so. I've uploaded the
updated dmesg output to
http://www.ilande.co.uk/tmp/rtl8192cu_patch-2-dmesg.txt for you to take
a look at.
I also tried another experiment which was to change your patch so that
instead of logging just the first 100 beacons to dmesg, log every 10th
beacon (count % 10) to dmesg instead. This showed that even when the
timeouts are occurring against the AP, I'm still seeing a continual
stream of beacons from other stations on the network.
This makes me wonder if Oleksij is correct in that the problem is that
not all the frames coming from the USB interface are being picked up by
the driver. Perhaps not all incoming USB RX buffers are being scanned
(causing some queued frames to be lost) or maybe USB transfers can
contain more than 1 frame and rtlwifi is only catching the first frame
within each notified transfer?
To double check whether it was a general ehci-pci problem, I tried
plugging in a spare zd1211rw dongle and that worked absolutely fine. So
I think that's a reasonable indication that general USB function is okay.
ATB,
Mark.
^ 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