Re: Issues with urtwn
El día Saturday, December 20, 2014 a las 11:41:43AM -0800, Adrian Chadd escribió: It's a race condition in the scan handling. :( When scan is cancelled (eg because something cancels it, or the state transitions to IDLE or something because the VAP resets) then it should be setting a flag to cancel things and the VAP should come out of powerstate. However, there seems to be some conditions where the scan is coming out of that loop because it's been aborted/stopped, so it's not complete - but then it stays in powersave mode because whatever's supposed to either change it (eg a state change, a received becaon, TIM coming in, etc) doesn't follow. So it stays in power save. The driver routines are called without the comlock held, so that's a small, narrow window for some state change to come through that doesn't trigger the scan code to see the scan is canceled and finish the scan (which would reset the vap powersave state.) I've added another cancel check in scan_task(). Please update this and see what happens! Hi Adrian, It works fine now, see the attached log. Thanks and ¡Feliz Navidad! matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. Dec 21 10:15:41 unixarea kernel: ugen4.3: vendor 0x7392 at usbus4 Dec 21 10:15:41 unixarea kernel: urtwn0: vendor 0x7392 product 0x7811, class 0/0, rev 2.00/2.00, addr 3 on usbus4 Dec 21 10:15:41 unixarea kernel: urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R Dec 21 10:15:41 unixarea kernel: wlan0: Ethernet address: 80:1f:02:ee:16:37 Dec 21 10:15:42 unixarea wpa_supplicant[929]: Successfully initialized wpa_supplicant Dec 21 10:15:46 unixarea wpa_supplicant[930]: wlan0: Trying to associate with 00:13:f7:0d:08:48 (SSID='tarara' freq=2442 MHz) Dec 21 10:15:46 unixarea wpa_supplicant[930]: wlan0: Associated with 00:13:f7:0d:08:48 Dec 21 10:15:46 unixarea kernel: wlan0: link state changed to UP Dec 21 10:15:46 unixarea dhclient[995]: send_packet: No buffer space available Dec 21 10:15:51 unixarea wpa_supplicant[930]: wlan0: WPA: Key negotiation completed with 00:13:f7:0d:08:48 [PTK=CCMP GTK=CCMP] Dec 21 10:15:51 unixarea wpa_supplicant[930]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:13:f7:0d:08:48 completed [id=1 id_str=] Dec 21 10:15:52 unixarea dhclient: New IP Address (wlan0): 192.168.2.101 Dec 21 10:15:52 unixarea dhclient: New Subnet Mask (wlan0): 255.255.255.0 Dec 21 10:15:52 unixarea dhclient: New Broadcast Address (wlan0): 192.168.2.255 Dec 21 10:15:52 unixarea dhclient: New Routers (wlan0): 192.168.2.1 Dec 21 10:16:33 unixarea ipmon[518]: missed 1 ipf log entries: 0 1 Dec 21 10:16:33 unixarea ipmon[518]: 10:16:33.246627 wlan0 @0:3 p 192.168.2.101 - 193.149.48.8 PR icmp len 20 84 icmp echo/0 K-S OUT Dec 21 10:17:02 unixarea ipmon[518]: 10:17:02.758277 wlan0 @0:14 p 192.168.2.101,32308 - 178.254.11.41,80 PR tcp len 20 60 -S K-S OUT ... Dec 21 10:20:43 unixarea ipmon[518]: 10:20:43.551190 wlan0 @0:14 p 192.168.2.101,17676 - 178.254.11.41,80 PR tcp len 20 60 -S K-S OUT Dec 21 10:20:46 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 351546 duration 150 Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: chan 7g - 1g [active, dwell min 20ms max 150ms] Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: stopped, [ticks 351715, dwell min 20 scanend 351698] Dec 21 10:20:46 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 351751 duration 150 Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: chan 7g - 6g [active, dwell min 20ms max 150ms] Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: stopped, [ticks 351919, dwell min 20 scanend 351902] Dec 21 10:20:46 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 351956 duration 150 Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: chan 7g - 11g [active, dwell min 20ms max 150ms] Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: stopped, [ticks 352124, dwell min 20 scanend 352107] Dec 21 10:20:46 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 352161 duration 150 Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: chan 7g - 7g [active, dwell min 20ms max 150ms] Dec 21 10:20:46 unixarea kernel: [00:13:f7:0d:08:48] new probe_resp on chan 7 (bss chan 7) tarara rssi 84 Dec 21 10:20:46 unixarea kernel: [00:13:f7:0d:08:48] caps 0x431 bintval 100 erp 0x100 country [NL 1-13,20] Dec 21 10:20:46 unixarea kernel: [00:13:f7:0d:08:48] new probe_resp on chan 7 (bss chan 7) tarara rssi 84 Dec 21 10:20:46 unixarea kernel: [00:13:f7:0d:08:48] caps 0x431 bintval 100 erp 0x100 country [NL 1-13,20] Dec 21 10:20:46 unixarea kernel: wlan0: ieee80211_cancel_anyscan: cancel active scan Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: done, [ticks 352209, dwell min 20
Re: Issues with urtwn
Sweet, which version of -HEAD did you end up updating to? -adrian On 21 December 2014 at 02:17, Matthias Apitz g...@unixarea.de wrote: El día Saturday, December 20, 2014 a las 11:41:43AM -0800, Adrian Chadd escribió: It's a race condition in the scan handling. :( When scan is cancelled (eg because something cancels it, or the state transitions to IDLE or something because the VAP resets) then it should be setting a flag to cancel things and the VAP should come out of powerstate. However, there seems to be some conditions where the scan is coming out of that loop because it's been aborted/stopped, so it's not complete - but then it stays in powersave mode because whatever's supposed to either change it (eg a state change, a received becaon, TIM coming in, etc) doesn't follow. So it stays in power save. The driver routines are called without the comlock held, so that's a small, narrow window for some state change to come through that doesn't trigger the scan code to see the scan is canceled and finish the scan (which would reset the vap powersave state.) I've added another cancel check in scan_task(). Please update this and see what happens! Hi Adrian, It works fine now, see the attached log. Thanks and ¡Feliz Navidad! matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
Ok. You should also update iee80211_sta.c and ieee80211_power.c. I fixed some issues there too relating to this. -adrian On 21 December 2014 at 08:40, Matthias Apitz g...@unixarea.de wrote: El día Sunday, December 21, 2014 a las 08:07:28AM -0800, Adrian Chadd escribió: Sweet, which version of -HEAD did you end up updating to? I'm running HEAD r269739 (from August this year) and updated only src/sys/net80211/ieee80211_scan.c yesterday night to: r275964 | adrian | 2014-12-20 20:41:31 +0100 (sáb 20 de dic de 2014) | 11 líneas Document where in scan_task the scan state can change, and potentially deal/log a warning if the scan flags change during one of those race windows. ... Thanks matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
Hi, Ok. I think I understand what's going on. The net80211 stack didn't always call vap-iv_sta_ps(vap, 0) to wake things up when it saw something in TIM. In fact, this was for the most part commented out. ieee80211_sta_tim_notify() now gets called, but I only use that to transition from IEEE80211_S_SLEEP - IEEE80211_S_RUN, because the net80211 stack is doing software-driven STA sleep mode. So in the scan code, it's putting the VAP state to sleep to buffer transmit frames, doing some scan stuff, but then being brought out of scan before it finishes. So, in scan_task() it likely sees scandone=0, so it leaves the VAP in powersave mode hoping it'll do another channel scan soon, or it'll stop scanning because it's being dragged out of bgscan state. Would someone please try this again, but run it with scan debugging enabled (wlandebug +scan) ? The scan_task() routine has some useful debugging just before it may wake up the VAP; I'd like to see what that says (whether it says done or stopped in it.) I bet it's that we don't have some glue to wake things up if we have started a bgscan and it's canceled due to existing traffic wanting to go out _and_ the AP says there's traffic buffered for us. It's also shady that we're buffering outbound frames because we're still in STA power-save mode. I thought that would trigger releasing STA power-save! Grr. But, it turns out that in scan_task(), it clears IEEE80211_F_SCAN before continuing, so ieee80211_start_pkt() won't call ieee80211_cancel_anyscan() to cancel things. So hm! So, what I'd like to figure out: * if we finish scan_task() and scandone=0, then we need to find how it was called. * It's assuming that a background scan will continue scanning, or we'll drop out because the AP tells us we have frames. * .. we're not forcing the VAP out of powersave when the AP has a TIM bit set for us - and we should fix this! * .. and in this particular situation, bgscan isn't continuing, and thus we're not continuing to scan! Grr What's going on. -adrian On 23 November 2014 at 08:38, Matthias Apitz g...@unixarea.de wrote: El día Monday, November 03, 2014 a las 09:43:14AM -0800, Adrian Chadd escribió: Ah, chances are it's being loaded automatically at startup when devd loads your USB wifi module. Just make sure you've commented out the wlan devices (but not options!) and rebuilt your kernel to not have wlan included. The problem is reproducible fine: I'm running in a loop SCP traffic up and down to my ISP host; when the background scan every five minutes takes place the traffic gets STALLED and IP comes not to work again: Nov 23 17:13:33 unixarea dhclient: New Broadcast Address (wlan0): 192.168.2.255 Nov 23 17:13:33 unixarea dhclient: New Routers (wlan0): 192.168.2.1 Nov 23 17:18:33 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 36537257 duration 150 Nov 23 17:18:33 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Nov 23 17:18:33 unixarea kernel: wlan0: scan_task: chan 7g - 1g [active, dwell min 20ms max 150ms] Nov 23 17:18:33 unixarea kernel: wlan0: scan_task: stopped, [ticks 36537415, dwell min 20 scanend 36537408] from now the interface does not let pass frames anymore Nov 23 17:18:33 unixarea kernel: wlan0: ieee80211_sta_tim_notify: TIM=1 Nov 23 17:18:34 unixarea last message repeated 3 times Nov 23 17:18:34 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 40, 1 now queued Nov 23 17:18:34 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 0, 2 now queued Nov 23 17:18:34 unixarea kernel: wlan0: ieee80211_sta_tim_notify: TIM=1 Nov 23 17:18:35 unixarea last message repeated 14 times Nov 23 17:18:35 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 0, 3 now queued Nov 23 17:18:35 unixarea kernel: wlan0: ieee80211_sta_tim_notify: TIM=1 ... I tested the same in an older 10-ALPHA4 laptop (running r255948 from October 2013) with the same physical WLAN card; there is no problem with the bg scans every 5 minutes, it just goes ahead after any scan; this is an issue in head. matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
El día Monday, November 03, 2014 a las 09:43:14AM -0800, Adrian Chadd escribió: Ah, chances are it's being loaded automatically at startup when devd loads your USB wifi module. Just make sure you've commented out the wlan devices (but not options!) and rebuilt your kernel to not have wlan included. The problem is reproducible fine: I'm running in a loop SCP traffic up and down to my ISP host; when the background scan every five minutes takes place the traffic gets STALLED and IP comes not to work again: Nov 23 17:13:33 unixarea dhclient: New Broadcast Address (wlan0): 192.168.2.255 Nov 23 17:13:33 unixarea dhclient: New Routers (wlan0): 192.168.2.1 Nov 23 17:18:33 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 36537257 duration 150 Nov 23 17:18:33 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Nov 23 17:18:33 unixarea kernel: wlan0: scan_task: chan 7g - 1g [active, dwell min 20ms max 150ms] Nov 23 17:18:33 unixarea kernel: wlan0: scan_task: stopped, [ticks 36537415, dwell min 20 scanend 36537408] from now the interface does not let pass frames anymore Nov 23 17:18:33 unixarea kernel: wlan0: ieee80211_sta_tim_notify: TIM=1 Nov 23 17:18:34 unixarea last message repeated 3 times Nov 23 17:18:34 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 40, 1 now queued Nov 23 17:18:34 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 0, 2 now queued Nov 23 17:18:34 unixarea kernel: wlan0: ieee80211_sta_tim_notify: TIM=1 Nov 23 17:18:35 unixarea last message repeated 14 times Nov 23 17:18:35 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 0, 3 now queued Nov 23 17:18:35 unixarea kernel: wlan0: ieee80211_sta_tim_notify: TIM=1 ... I tested the same in an older 10-ALPHA4 laptop (running r255948 from October 2013) with the same physical WLAN card; there is no problem with the bg scans every 5 minutes, it just goes ahead after any scan; this is an issue in head. matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
El día Monday, November 03, 2014 a las 09:43:14AM -0800, Adrian Chadd escribió: Ah, chances are it's being loaded automatically at startup when devd loads your USB wifi module. Just make sure you've commented out the wlan devices (but not options!) and rebuilt your kernel to not have wlan included. I commented out only the 'device wlan' but this gives errors on linkage of the kernel, like: if_ath.o: In function `ath_ioctl_ratestats': /usr/src/sys/dev/ath/if_ath.c:6381: undefined reference to `ieee80211_find_node' if_ath.o: In function `ath_chan_change': /usr/src/sys/dev/ath/if_ath.c:5306: undefined reference to `ieee80211_chan2mode' if_ath.o: In function `ath_init': /usr/src/sys/dev/ath/if_ath.c:2455: undefined reference to `ieee80211_start_all' if_ath.o: In function `ath_vap_create': (many) Thx matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
El día Monday, November 03, 2014 a las 06:46:33AM +0100, Matthias Apitz escribió: El día Sunday, November 02, 2014 a las 10:46:13AM -0800, Adrian Chadd escribió: It's not forcing the adapter itself into ps mode - it's just net80211 doing an off-channel scan thing. Someone has to debug/fix this scan hang thing, I'm out of energy atm :( I'm willing to dig into this and will start with instrumenting net80211/ieee80211_scan.c with more debug messages; from there the power save is activated: ... While I can compile sys/modules/wlan/wlan.ko, I do not see how to make it undload / loadable from there; is it essential that it is loaded at boot time? The man page has no information about this :-( matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
Ah, chances are it's being loaded automatically at startup when devd loads your USB wifi module. Just make sure you've commented out the wlan devices (but not options!) and rebuilt your kernel to not have wlan included. -adrian On 3 November 2014 01:55, Matthias Apitz g...@unixarea.de wrote: El día Monday, November 03, 2014 a las 06:46:33AM +0100, Matthias Apitz escribió: El día Sunday, November 02, 2014 a las 10:46:13AM -0800, Adrian Chadd escribió: It's not forcing the adapter itself into ps mode - it's just net80211 doing an off-channel scan thing. Someone has to debug/fix this scan hang thing, I'm out of energy atm :( I'm willing to dig into this and will start with instrumenting net80211/ieee80211_scan.c with more debug messages; from there the power save is activated: ... While I can compile sys/modules/wlan/wlan.ko, I do not see how to make it undload / loadable from there; is it essential that it is loaded at boot time? The man page has no information about this :-( matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
Hi,
I do not understand why I have these 'powersave on/off' transitions:
Nov 2 09:01:06 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode
on
Nov 2 09:01:08 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode
off
Nov 2 09:06:08 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode
on
Nov 2 09:06:10 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode
off
Nov 2 09:11:11 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode
on
Nov 2 09:11:12 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode
off
# ifconfig wlan0 -powersave
# ifconfig -v wlan0 | fgrep power
AES-CCM 3:128-bit powersavemode OFF powersavesleep 100 txpower 0
i.e. it seems to be OFF, I even can not set it to on:
# ifconfig wlan0 powersave
ifconfig: SIOCS80211: Operation not supported
What I do can set is the powersavesleep interval to zero:
# ifconfig wlan0 powersavesleep 0
# ifconfig -v wlan0 | fgrep power
AES-CCM 3:128-bit powersavemode OFF powersavesleep 0 txpower 0
But this does not help either.
I fgrep'ed throu the src/sys and it seems that the power save mode
on/off message comes out from
/usr/src/sys/net80211/ieee80211_power.c
/*
* Handle power-save state change in station mode.
*/
void
ieee80211_sta_pwrsave(struct ieee80211vap *vap, int enable)
{
struct ieee80211_node *ni = vap-iv_bss;
if (!((enable != 0) ^ ((ni-ni_flags IEEE80211_NODE_PWR_MGT) != 0)))
return;
IEEE80211_NOTE(vap, IEEE80211_MSG_POWER, ni,
sta power save mode %s, enable ? on : off);
but this does not answer the question why is switching it on/off.
Is it worth to compile a hard change an let return
ieee80211_sta_pwrsave() without doing anything?
Any ideas?
matthias
--
Matthias Apitz | /\ ASCII Ribbon Campaign:
E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X- No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
El día Sunday, November 02, 2014 a las 07:24:02AM -0800, Nathan Whitehorn escribió: Are you running wpa_supplicant? If you can connect to a plain network with ifconfig, these will stop. -Nathan I do run wpa_supplicant. But I don't understand what you mean with If you can connect to a plain network with ifconfig ... wlan0 has an IP addr (via DHCP from the AP) and I can connect. What do you mean with to a plain network with ifconfig ...? Thx matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
It's not forcing the adapter itself into ps mode - it's just net80211 doing an off-channel scan thing. Someone has to debug/fix this scan hang thing, I'm out of energy atm :( -adrian On 2 November 2014 07:31, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 11/02/14 07:29, Matthias Apitz wrote: El día Sunday, November 02, 2014 a las 07:24:02AM -0800, Nathan Whitehorn escribió: Are you running wpa_supplicant? If you can connect to a plain network with ifconfig, these will stop. -Nathan I do run wpa_supplicant. But I don't understand what you mean with If you can connect to a plain network with ifconfig ... wlan0 has an IP addr (via DHCP from the AP) and I can connect. What do you mean with to a plain network with ifconfig ...? Thx matthias You can connect to an unencrypted network by doing ifconfig wlan0 -bgscan ssid blah. The issue is that wpa_supplicant is doing scanning in the background, which forces the adapter into power-save mode. -Nathan ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
El día Sunday, November 02, 2014 a las 10:46:13AM -0800, Adrian Chadd escribió:
It's not forcing the adapter itself into ps mode - it's just net80211
doing an off-channel scan thing.
Someone has to debug/fix this scan hang thing, I'm out of energy atm :(
I'm willing to dig into this and will start with instrumenting
net80211/ieee80211_scan.c with more debug messages; from there the power
save is activated:
scan_task(void *arg, int pending)
...
if (vap-iv_opmode == IEEE80211_M_STA
vap-iv_state == IEEE80211_S_RUN) {
if ((vap-iv_bss-ni_flags IEEE80211_NODE_PWR_MGT) == 0) {
/* Enable station power save mode */
vap-iv_sta_ps(vap, 1);
Or any other idea? Can you guide me through this?
Thx
matthias
--
Matthias Apitz | /\ ASCII Ribbon Campaign:
E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X- No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
El día Sunday, October 26, 2014 a las 08:36:05AM +0100, Matthias Apitz escribió: # ifconfig wlan0 list sta ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 00:13:f7:0d:08:4827 54M 35.50 1219 64016 EPS AE RSN the kernel is 11-CURRENT (r269739) and I have IEEE80211_DEBUG enabled: # fgrep IEEE80211_DEBUG sys/i386/conf/GENERIC options IEEE80211_DEBUG # enable debug msgs # wlandebug -i wlan0 +state +power net.wlan.0.debug: 0x0 = 0xcstate,power I have had another look up with these messages in /var/log/messages: Nov 1 08:44:39 unixarea kernel: wlan0: Ethernet address: 80:1f:02:ee:16:37 Nov 1 08:44:44 unixarea kernel: wlan0: link state changed to UP Nov 1 08:49:44 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Nov 1 08:49:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off Nov 1 08:54:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Nov 1 08:54:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 40, 1 now queued Nov 1 08:54:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off Nov 1 08:54:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] flush ps queue, 1 packets queued Nov 1 08:54:47 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Nov 1 08:54:48 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off Nov 1 08:59:48 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Nov 1 08:59:48 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 40, 1 now queued Nov 1 08:59:50 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off Nov 1 08:59:50 unixarea kernel: wlan0: [00:13:f7:0d:08:48] flush ps queue, 1 packets queued Nov 1 09:03:40 unixarea kernel: wlan0: beacon miss, mode STA state RUN Nov 1 09:03:41 unixarea kernel: wlan0: beacon miss, mode STA state RUN Nov 1 09:03:41 unixarea kernel: wlan0: ieee80211_new_state_locked: RUN - SCAN (nrunning 0 nscanning 0) Nov 1 09:03:41 unixarea kernel: wlan0: ieee80211_newstate_cb: RUN - SCAN arg 0 Nov 1 09:03:41 unixarea kernel: wlan0: sta_newstate: RUN - SCAN (0) Nov 1 09:03:41 unixarea kernel: wlan0: link state changed to DOWN Nov 1 09:03:44 unixarea kernel: wlan0: [00:13:f7:0d:08:48] station assoc via MLME Nov 1 09:03:44 unixarea kernel: wlan0: ieee80211_new_state_locked: SCAN - AUTH (nrunning 0 nscanning 0) Nov 1 09:03:44 unixarea kernel: wlan0: ieee80211_newstate_cb: SCAN - AUTH arg 192 Nov 1 09:03:44 unixarea kernel: wlan0: sta_newstate: SCAN - AUTH (192) Nov 1 09:03:46 unixarea kernel: wlan0: ieee80211_new_state_locked: AUTH - SCAN (nrunning 0 nscanning 0) Nov 1 09:03:46 unixarea kernel: wlan0: ieee80211_newstate_cb: AUTH - SCAN arg 1 Nov 1 09:03:46 unixarea kernel: wlan0: sta_newstate: AUTH - SCAN (1) Nov 1 09:03:54 unixarea kernel: wlan0: [00:13:f7:0d:08:48] station deauth via MLME (reason 3) Nov 1 09:03:54 unixarea kernel: wlan0: ieee80211_new_state_locked: SCAN - INIT (nrunning 0 nscanning 0) Nov 1 09:03:54 unixarea kernel: wlan0: ieee80211_newstate_cb: SCAN - INIT arg 3 Nov 1 09:03:54 unixarea kernel: wlan0: sta_newstate: SCAN - INIT (3) Nov 1 09:03:55 unixarea kernel: wlan0: ieee80211_new_state_locked: INIT - SCAN (nrunning 0 nscanning 0) Nov 1 09:03:55 unixarea kernel: wlan0: ieee80211_newstate_cb: INIT - SCAN arg 0 Nov 1 09:03:55 unixarea kernel: wlan0: sta_newstate: INIT - SCAN (0) -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
El día Monday, September 08, 2014 a las 03:17:08PM -0700, Adrian Chadd escribió: Please compile your kernel with IEEE80211_DEBUG, then enable debugging - wlandebug +state +power You can disable powersave with 'ifconfig wlan0 -powersave', but it shouldn't be enabled by default. Hi, I was to fast when saying in September that I do not have any issue with this NIC: under havy SCP traffic (let's say some GByte) the connection locks and I have to run 'netif restart' to wake it up; it seems that powersave is off: # ifconfig wlan0 list sta ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 00:13:f7:0d:08:4827 54M 35.50 1219 64016 EPS AE RSN the kernel is 11-CURRENT (r269739) and I have IEEE80211_DEBUG enabled: # fgrep IEEE80211_DEBUG sys/i386/conf/GENERIC options IEEE80211_DEBUG # enable debug msgs # wlandebug -i wlan0 +state +power net.wlan.0.debug: 0x0 = 0xcstate,power In /var/log/messages I see now lines like this: # fgrep kernel /var/log/messages Oct 26 08:22:44 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Oct 26 08:22:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off Oct 26 08:27:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Oct 26 08:27:48 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off Oct 26 08:32:48 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Oct 26 08:32:50 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off every 5 minutes... Who is switching this on/off? thx matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
This is what the debug output looks like when things go wrong: wlan0: [54:78:1a:a0:91:22] sta power save mode on wlan0: wlan0: [54:78:1a:a0:91:22] save frame with age 41, 1 now queued [54:78:1a:a0:91:22] sta power save mode off wlan0: [54:78:1a:a0:91:22] flush ps queue, 1 packets queued wlan0: [54:78:1a:a0:91:22] sta power save mode on wlan0: [54:78:1a:a0:91:22] save frame with age 41, 1 now queued wlan0: [54:78:1a:a0:91:22] save frame with age 0, 2 now queued wlan0: [54:78:1a:a0:91:22] save frame with age 0, 3 now queued wlan0: [54:78:1a:a0:91:22] save frame with age 0, 4 now queued wlan0: ieee80211_sta_tim_notify: TIM=1 wlan0: ieee80211_sta_tim_notify: TIM=1 wlan0: ieee80211_sta_tim_notify: TIM=1 wlan0: ieee80211_sta_tim_notify: TIM=1 wlan0: ieee80211_sta_tim_notify: TIM=1 wlan0: [54:78:1a:a0:91:22] save frame with age 0, 5 now queued wlan0: [54:78:1a:a0:91:22] save frame with age 0, 6 now queued Let me know if I can test anything else. -Nathan On 09/08/14 15:17, Adrian Chadd wrote: Please compile your kernel with IEEE80211_DEBUG, then enable debugging - wlandebug +state +power You can disable powersave with 'ifconfig wlan0 -powersave', but it shouldn't be enabled by default. -a On 8 September 2014 15:14, Nathan Whitehorn nwhiteh...@freebsd.org wrote: So it's definitely to do with powersave. Here's a bunch of iterations of ifconfig list sta on my laptop: ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.00 4385 37104 EPS A HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4412 39360 EPS A HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP RSN WME You can see the connection die on the third line, when the txseq and rxseq counters stop incrementing and 'P' gets added to the FLAG field. Does this mean the AP has turned on powersave on its end? -Nathan On 09/07/14 14:07, Adrian Chadd wrote: Hi, The way it's supposed to work in the legacy 802.11 powersave world is that you send a/any data frame with the powermgt bit in the 802.11 header set to 0 and the AP goes oh they're awake! and sends you your buffered frames. By default powersave isn't enabled, so we should never be _telling_ the AP that we're going to sleep and the stack always sends data frames with pwrmgt=0. You can ensure it's disabled by ifconfig wlan0 -powersave The code in -HEAD that manages that is in ieee80211_power.c. I added an explicit powersave support mode for NICs that need it done for them - and the only one it's enabled for right now is ath(4). The only reason net80211 sends pwrmgt changes outside of having net80211 power save enabled is the background scan code. I'd compile in IEEE80211_DEBUG in your kernel, then I'd use wlandebug +scan to see if somehow there's some scanning going on; and wlandebug +power to see if any power save transitions occur. Are you absolutely sure it's a receive side buffering problem, rather than a send side problem? It's also possible that the NIC stops receiving and the AP treats that as oh ok, they've gone to sleep for a while. ath(4) now does this in hostap mode. -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
What the hell is calling sta power save? Can you go put in a stack trace (maybe use dtrace :) whenever the sta powersave routines get called? That's odd. So you see TIM=1 from the AP, but since powersave isn't enabled, it doesn't transition the NIC back to normal. So ieee80211_sta_pwrsave() is set in vap-iv_sta_ps. That's only called in: * the scan task for bgscan; * transitioning in/out of IEEE80211_S_SLEEP state. So, I don't know why you're seeing the above. In fact, if you hacked up urtwn to at least do powersave, the tim_notify will transition the VAP from SLEEP to RUN. In fact, hm. Can you file a bug for the above? There's the bug you're seeing, then there's the we see a TIM flag for us, maybe we need to force transition out of sleep even if we think we're not in powersave. Thanks, -a On 12 September 2014 10:57, Nathan Whitehorn nwhiteh...@freebsd.org wrote: This is what the debug output looks like when things go wrong: wlan0: [54:78:1a:a0:91:22] sta power save mode on wlan0: wlan0: [54:78:1a:a0:91:22] save frame with age 41, 1 now queued [54:78:1a:a0:91:22] sta power save mode off wlan0: [54:78:1a:a0:91:22] flush ps queue, 1 packets queued wlan0: [54:78:1a:a0:91:22] sta power save mode on wlan0: [54:78:1a:a0:91:22] save frame with age 41, 1 now queued wlan0: [54:78:1a:a0:91:22] save frame with age 0, 2 now queued wlan0: [54:78:1a:a0:91:22] save frame with age 0, 3 now queued wlan0: [54:78:1a:a0:91:22] save frame with age 0, 4 now queued wlan0: ieee80211_sta_tim_notify: TIM=1 wlan0: ieee80211_sta_tim_notify: TIM=1 wlan0: ieee80211_sta_tim_notify: TIM=1 wlan0: ieee80211_sta_tim_notify: TIM=1 wlan0: ieee80211_sta_tim_notify: TIM=1 wlan0: [54:78:1a:a0:91:22] save frame with age 0, 5 now queued wlan0: [54:78:1a:a0:91:22] save frame with age 0, 6 now queued Let me know if I can test anything else. -Nathan On 09/08/14 15:17, Adrian Chadd wrote: Please compile your kernel with IEEE80211_DEBUG, then enable debugging - wlandebug +state +power You can disable powersave with 'ifconfig wlan0 -powersave', but it shouldn't be enabled by default. -a On 8 September 2014 15:14, Nathan Whitehorn nwhiteh...@freebsd.org wrote: So it's definitely to do with powersave. Here's a bunch of iterations of ifconfig list sta on my laptop: ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.00 4385 37104 EPS A HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4412 39360 EPS A HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP RSN WME You can see the connection die on the third line, when the txseq and rxseq counters stop incrementing and 'P' gets added to the FLAG field. Does this mean the AP has turned on powersave on its end? -Nathan On 09/07/14 14:07, Adrian Chadd wrote: Hi, The way it's supposed to work in the legacy 802.11 powersave world is that you send a/any data frame with the powermgt bit in the 802.11 header set to 0 and the AP goes oh they're awake! and sends you your buffered frames. By default powersave isn't enabled, so we should never be _telling_ the AP that we're going to sleep and the stack always sends data frames with pwrmgt=0. You can ensure it's disabled by ifconfig wlan0 -powersave The code in -HEAD that manages that is in ieee80211_power.c. I added an explicit powersave support mode for NICs that need it done for them - and the only one it's enabled for right now is ath(4). The only reason net80211 sends pwrmgt changes outside of having net80211 power save enabled is the background scan code. I'd compile in IEEE80211_DEBUG in your kernel, then I'd use wlandebug +scan to see if somehow there's some scanning going on; and wlandebug +power to see if any power save transitions occur. Are you absolutely sure it's a receive side buffering problem, rather than a send side problem? It's also possible that the NIC stops receiving and the AP treats that as oh ok, they've gone to sleep for a while. ath(4) now does this in hostap mode. -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
Hi Matthias,
On Mon, 8 Sep 2014 07:47:34 +0200
Matthias Apitz g...@unixarea.de wrote:
[...]
I only encountered one problem while traveling through Italy in a
hotel: They gave me a piece of paper saying Password:
N@tur%Wieser and I could not construct a
good /etc/wpa_supplicant.conf to connect correctly. I could figure
out the SSID of the AP (Naturhotel Wieserhof) and tried a lot of
network={ ... } settings, nothing worked. Sometimes I could associate
and got an IP addr from the AP, but only in places where the hotel
said it should not work (im my room). In places where it should work
(in the lobby) I could not even associate. I have a lot of
wpa_supplicant debug if someone is willing to check for details. At
the end I was frustated and gave up, more frustated due to the fact
that all the other clients with their stupid smartphones did not have
had any problem at all :-(
matthias
maybe the wpa_passphrase utility could help you to create the config.
In this particular case:
$ wpa_passphrase Naturhotel Wieserhof N@tur%Wieser
network={
ssid=Naturhotel Wieserhof
#psk=N@tur%Wieser
psk=b853709a9edcd50edf0835f68bf099255cb32fc462e492117fe3c42ab2a387cb
}
,or you might want to try wpa_gui.
Cheers,
-vlado
signature.asc
Description: PGP signature
Re: Issues with urtwn
El día Monday, September 08, 2014 a las 08:19:45AM +0200, Vladimir Botka
escribió:
Hi Vladimir,
maybe the wpa_passphrase utility could help you to create the config.
In this particular case:
$ wpa_passphrase Naturhotel Wieserhof N@tur%Wieser
network={
ssid=Naturhotel Wieserhof
#psk=N@tur%Wieser
psk=b853709a9edcd50edf0835f68bf099255cb32fc462e492117fe3c42ab2a387cb
}
What is the benefit of coding the PSK? I have never used it; the
wpa_supplicant.conf file tested was:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
eapol_version=1
ap_scan=1
fast_reauth=1
# Hotel Wieserhof
#
network={
ssid=Naturhotel Wieserhof
scan_ssid=1
# key_mgmt=WPA-PSK WPA-EAP IEEE8021X
key_mgmt=WPA-PSK
# key_mgmt=WPA-PSK WPA-EAP
psk=N@tur%Wieser
# key_mgmt=NONE
# wep_tx_keyidx=0
# wep_key0=N@tur%Wieser
}
as you see in the comments, I tested a lot of different key_mgmt=
values; the one shown active, gave the best results (but only in my
hotel room, not in the lobby);
,or you might want to try wpa_gui.
I have never used it, but will install the port and give it a try next
time.
Thx
matthias
PD: To Adrian, I'm willing to file a PR, but the problem is, I will not
return to this hotel and can not provide more information or tests.
--
Matthias Apitz | /\ ASCII Ribbon Campaign:
E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X- No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
wpa_gui as a next step. In the upstream, wpa_gui is maintained together with wpa_supplicant by the same maintainer. Therefor wpa_gui has always been working fine with wpa_supplicant and might help you to create a consistent configuration. I too have found wpa_gui useful to detect syntax errs from my wpa_supplicant.conf ( useful to know same maintainer). Matthias, a word of warning: copy wpa_supplicant.conf before you enable update_config=1 because wpa_gui will discard all lines with comments. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Interleave replies Below, like a play script. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
On Sun, Sep 7, 2014 at 11:36 PM, Adrian Chadd adr...@freebsd.org wrote: Hi, On 7 September 2014 19:16, Thiago Farina tfrans...@gmail.com wrote: On Sun, Sep 7, 2014 at 12:09 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: I've been having some issues with connection stability in urtwn for several months. The usual symptom is that after some period of time the connection will apparently stall. If I'm running ping continuously, for instance, it will at some point stop receiving replies. Then, sometime later, immediately if I use the reassociate command in wpa_cli, the connection will fix itself and all the packets I didn't get earlier get delivered at once: hundreds of ping replies, for instance, some with time stamps minutes in the past. No data is actually lost, though. I think the issue is that the driver does not actually support powersave mode (maybe it should?) but reports to the AP that it does: ifconfig wlan0 list sta (this is on the AP) ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 80:1f:02:cc:47:a91 11 11M 8.50 5526 55712 EPS AE RSN I don't know enough about wireless to fix this, but the AP waiting for a powersave poll and never getting one seems consistent with the problem. I think what you are relating here is what I observed recently too. Sorry, I'm new to FreeBSD. Just installed it recently, and I noticed that after I left it idle (I went to do something for some hours) for some time it lost the connection. Only rebooting makes it connect again to my network. Which NIC are you seeing this on? Mine is urtwn0: Realtek RTL8187L from my Gateway laptop. -- Thiago Farina ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
So it's definitely to do with powersave. Here's a bunch of iterations of ifconfig list sta on my laptop: ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.00 4385 37104 EPS A HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4412 39360 EPS A HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP RSN WME You can see the connection die on the third line, when the txseq and rxseq counters stop incrementing and 'P' gets added to the FLAG field. Does this mean the AP has turned on powersave on its end? -Nathan On 09/07/14 14:07, Adrian Chadd wrote: Hi, The way it's supposed to work in the legacy 802.11 powersave world is that you send a/any data frame with the powermgt bit in the 802.11 header set to 0 and the AP goes oh they're awake! and sends you your buffered frames. By default powersave isn't enabled, so we should never be _telling_ the AP that we're going to sleep and the stack always sends data frames with pwrmgt=0. You can ensure it's disabled by ifconfig wlan0 -powersave The code in -HEAD that manages that is in ieee80211_power.c. I added an explicit powersave support mode for NICs that need it done for them - and the only one it's enabled for right now is ath(4). The only reason net80211 sends pwrmgt changes outside of having net80211 power save enabled is the background scan code. I'd compile in IEEE80211_DEBUG in your kernel, then I'd use wlandebug +scan to see if somehow there's some scanning going on; and wlandebug +power to see if any power save transitions occur. Are you absolutely sure it's a receive side buffering problem, rather than a send side problem? It's also possible that the NIC stops receiving and the AP treats that as oh ok, they've gone to sleep for a while. ath(4) now does this in hostap mode. -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
On Mon, Sep 08, 2014 at 12:16:53PM -0300, Thiago Farina wrote: On Sun, Sep 7, 2014 at 11:36 PM, Adrian Chadd adr...@freebsd.org wrote: Hi, On 7 September 2014 19:16, Thiago Farina tfrans...@gmail.com wrote: On Sun, Sep 7, 2014 at 12:09 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: I've been having some issues with connection stability in urtwn for several months. The usual symptom is that after some period of time the connection will apparently stall. If I'm running ping continuously, for instance, it will at some point stop receiving replies. Then, sometime later, immediately if I use the reassociate command in wpa_cli, the connection will fix itself and all the packets I didn't get earlier get delivered at once: hundreds of ping replies, for instance, some with time stamps minutes in the past. No data is actually lost, though. I think the issue is that the driver does not actually support powersave mode (maybe it should?) but reports to the AP that it does: ifconfig wlan0 list sta (this is on the AP) ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 80:1f:02:cc:47:a91 11 11M 8.50 5526 55712 EPS AE RSN I don't know enough about wireless to fix this, but the AP waiting for a powersave poll and never getting one seems consistent with the problem. I think what you are relating here is what I observed recently too. Sorry, I'm new to FreeBSD. Just installed it recently, and I noticed that after I left it idle (I went to do something for some hours) for some time it lost the connection. Only rebooting makes it connect again to my network. Which NIC are you seeing this on? Mine is urtwn0: Realtek RTL8187L from my Gateway laptop. Typo? urtw(4) supports Realtek RTL8187L, not urtwn(4). -- Thiago Farina Kevin ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
On 7 September 2014 08:09, Nathan Whitehorn nwhiteh...@freebsd.org wrote: I've been having some issues with connection stability in urtwn for several months. The usual symptom is that after some period of time the connection will apparently stall. If I'm running ping continuously, for instance, it will at some point stop receiving replies. Then, sometime later, immediately if I use the reassociate command in wpa_cli, the connection will fix itself and all the packets I didn't get earlier get delivered at once: hundreds of ping replies, for instance, some with time stamps minutes in the past. No data is actually lost, though. I think the issue is that the driver does not actually support powersave mode (maybe it should?) but reports to the AP that it does: ifconfig wlan0 list sta (this is on the AP) ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 80:1f:02:cc:47:a91 11 11M 8.50 5526 55712 EPS AE RSN I don't know enough about wireless to fix this, but the AP waiting for a powersave poll and never getting one seems consistent with the problem. Is there a simple way just to disable advertising this? When it next stalls, check ifconfig wlan0 and ifconfig urtwn0 - see if OACTIVE is set. I know iwn and ath had problems in the past where OACTIVE handling was plain broken (wasn't behind locks) and in an SMP, preemptive world things got gunked up. -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
On 09/07/14 08:28, Adrian Chadd wrote: On 7 September 2014 08:09, Nathan Whitehorn nwhiteh...@freebsd.org wrote: I've been having some issues with connection stability in urtwn for several months. The usual symptom is that after some period of time the connection will apparently stall. If I'm running ping continuously, for instance, it will at some point stop receiving replies. Then, sometime later, immediately if I use the reassociate command in wpa_cli, the connection will fix itself and all the packets I didn't get earlier get delivered at once: hundreds of ping replies, for instance, some with time stamps minutes in the past. No data is actually lost, though. I think the issue is that the driver does not actually support powersave mode (maybe it should?) but reports to the AP that it does: ifconfig wlan0 list sta (this is on the AP) ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 80:1f:02:cc:47:a91 11 11M 8.50 5526 55712 EPS AE RSN I don't know enough about wireless to fix this, but the AP waiting for a powersave poll and never getting one seems consistent with the problem. Is there a simple way just to disable advertising this? When it next stalls, check ifconfig wlan0 and ifconfig urtwn0 - see if OACTIVE is set. I know iwn and ath had problems in the past where OACTIVE handling was plain broken (wasn't behind locks) and in an SMP, preemptive world things got gunked up. OACTIVE is not set when it stalls. It also appears that only the RX path is stalled: transmitted packets make it, at least some of the time, to their destination when this happens. -Nathan ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
Ok. Try disabling bgscan. ifconfig wlan0 -bgscan -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
Also does not help. I also tried various other things like forcing 11b or 11g mode, all of which made no difference. -Nathan On 09/07/14 11:51, Adrian Chadd wrote: Ok. Try disabling bgscan. ifconfig wlan0 -bgscan -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
Hi, On 7 September 2014 19:16, Thiago Farina tfrans...@gmail.com wrote: On Sun, Sep 7, 2014 at 12:09 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: I've been having some issues with connection stability in urtwn for several months. The usual symptom is that after some period of time the connection will apparently stall. If I'm running ping continuously, for instance, it will at some point stop receiving replies. Then, sometime later, immediately if I use the reassociate command in wpa_cli, the connection will fix itself and all the packets I didn't get earlier get delivered at once: hundreds of ping replies, for instance, some with time stamps minutes in the past. No data is actually lost, though. I think the issue is that the driver does not actually support powersave mode (maybe it should?) but reports to the AP that it does: ifconfig wlan0 list sta (this is on the AP) ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 80:1f:02:cc:47:a91 11 11M 8.50 5526 55712 EPS AE RSN I don't know enough about wireless to fix this, but the AP waiting for a powersave poll and never getting one seems consistent with the problem. I think what you are relating here is what I observed recently too. Sorry, I'm new to FreeBSD. Just installed it recently, and I noticed that after I left it idle (I went to do something for some hours) for some time it lost the connection. Only rebooting makes it connect again to my network. Which NIC are you seeing this on? I don't have this problem with Intel/Atheros chips on freebsd-head. -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
