Re: Issues with urtwn
El día Sunday, December 21, 2014 a las 08:46:35AM -0800, Adrian Chadd escribió: > Ok. You should also update iee80211_sta.c and ieee80211_power.c. I > fixed some issues there too relating to this. If I do so it gives: /usr/src/sys/net80211/ieee80211_sta.c:941:2: error: implicit declaration of function 'if_inc_counter' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if_inc_counter(ifp, IFCOUNTER_IERRORS, 1); ^ /usr/src/sys/net80211/ieee80211_sta.c:941:22: error: use of undeclared identifier 'IFCOUNTER_IERRORS' Perhaps some header file must be updated too. We can let it as it is for now because I will completely update to head in the next days. 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
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 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
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
Sweet, which version of -HEAD did you end up updating to? -adrian On 21 December 2014 at 02:17, Matthias Apitz 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
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: at usbus4 Dec 21 10:15:41 unixarea kernel: urtwn0: 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 scanend 352311] Dec 21 10:20:46 unixarea ipmon[
Re: Issues with urtwn
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! -adrian ___ 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 Friday, December 19, 2014 a las 08:13:25AM -0800, Adrian Chadd escribió: > Right, it's going into "stopped" mode, rather than "completed". It's > expecting there to be something that'll take the VAP out of power save > state, but nothing ever happens to do so. > > ok. I think I have enough information to track down a fix. Thanks! OK, let me know if I should do more tests or test some patches. Btw: I have another USB Wifi dongle which attaches to the rsu(4) driver as: Dec 20 10:42:48 unixarea kernel: ugen4.3: at usbus4 Dec 20 10:42:48 unixarea kernel: rsu0: on usbus4 Dec 20 10:42:48 unixarea kernel: rsu0: MAC/BB RTL8712 cut 3 Dec 20 10:42:49 unixarea kernel: wlan0: Ethernet address: 00:0d:09:a1:2e:16 Dec 20 10:42:49 unixarea wpa_supplicant[2091]: Successfully initialized wpa_supplicant Dec 20 10:42:53 unixarea wpa_supplicant[2092]: wlan0: Trying to associate with 00:13:f7:0d:08:48 (SSID='tarara' freq=2442 MHz) Dec 20 10:42:54 unixarea wpa_supplicant[2092]: wlan0: Associated with 00:13:f7:0d:08:48 Dec 20 10:42:54 unixarea kernel: wlan0: link state changed to UP and this does work smoothly at home, it does not run any bgscan. I was expecting the same problem. Why is this running fine w/o bgscan? 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
Right, it's going into "stopped" mode, rather than "completed". It's expecting there to be something that'll take the VAP out of power save state, but nothing ever happens to do so. ok. I think I have enough information to track down a fix. Thanks! -adrian On 18 December 2014 at 23:53, Matthias Apitz wrote: > El día Wednesday, December 17, 2014 a las 06:58:09PM -0800, Adrian Chadd > escribió: > >> ... >> 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.) >> ... >> > > Hi, > > Here comes the messages from such 'wlandebug +scan'; please let me know > if you need more tests/logs: > > ... > Dec 19 07:41:24 unixarea kernel: wlan0: [00:26:0b:4b:b8:44] > ieee80211_scan_assoc_success > Dec 19 07:41:24 unixarea kernel: wlan0: link state changed to UP > Dec 19 07:41:24 unixarea dhclient[1828]: send_packet: No buffer space > available > Dec 19 07:41:24 unixarea wpa_supplicant[1731]: wlan0: Associated with > 00:26:0b:4b:b8:44 > Dec 19 07:41:24 unixarea wpa_supplicant[1731]: wlan0: WPA: Key negotiation > completed with 00:26:0b:4b:b8:44 [PTK=CCMP GTK=CCMP] > Dec 19 07:41:24 unixarea wpa_supplicant[1731]: wlan0: CTRL-EVENT-CONNECTED - > Connection to 00:26:0b:4b:b8:44 completed [id=2 id_str=] > Dec 19 07:41:31 unixarea dhclient: New IP Address (wlan0): 10.49.30.104 > Dec 19 07:41:31 unixarea dhclient: New Subnet Mask (wlan0): 255.255.255.0 > Dec 19 07:41:31 unixarea dhclient: New Broadcast Address (wlan0): 10.49.30.255 > Dec 19 07:41:31 unixarea dhclient: New Routers (wlan0): 10.49.30.1 > > I run in another terminal a cycle of a proc fetching a file with WGET from > some sever; the lines are from ipmon for every WGET: > > Dec 19 07:41:47 unixarea ipmon[508]: 07:41:47.581028 wlan0 @0:14 p > 10.49.30.104,37367 -> 132.174.1.212,80 PR tcp len 20 60 -S K-S OUT > Dec 19 07:41:50 unixarea ipmon[508]: 07:41:50.803714 wlan0 @0:14 p > 10.49.30.104,52814 -> 132.174.1.212,80 PR tcp len 20 60 -S K-S OUT > Dec 19 07:41:53 unixarea ipmon[508]: 07:41:53.206811 wlan0 @0:14 p > 10.49.30.104,53615 -> 132.174.1.212,80 PR tcp len 20 60 -S K-S OUT > Dec 19 07:41:55 unixarea ipmon[508]: 07:41:55.872432 wlan0 @0:14 p > 10.49.30.104,55755 -> 132.174.1.212,80 PR tcp len 20 60 -S K-S OUT > ... > Dec 19 07:46:23 unixarea ipmon[508]: 07:46:23.463618 wlan0 @0:14 p > 10.49.30.104,46622 -> 132.174.1.212,80 PR tcp len 20 60 -S K-S OUT > > now the 300 sec bgscan intervall is over and the bgscan occurs: > > Dec 19 07:46:24 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks > 2141470 duration 150 > Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: GuruDebug: Enable station > power save mode > Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: chan 1g -> 1g [active, > dwell min 20ms max 150ms] > Dec 19 07:46:24 unixarea kernel: [00:26:0b:4b:b8:44] new probe_resp on chan 1 > (bss chan 1) "OCLCPublic" rssi 64 > Dec 19 07:46:24 unixarea kernel: [00:26:0b:4b:b8:44] caps 0x431 bintval 100 > erp 0x100 country [NL 1-13,23] > Dec 19 07:46:24 unixarea kernel: [00:26:0b:4b:b8:44] new probe_resp on chan 1 > (bss chan 1) "OCLCPublic" rssi 64 > Dec 19 07:46:24 unixarea kernel: [00:26:0b:4b:b8:44] caps 0x431 bintval 100 > erp 0x100 country [NL 1-13,23] > Dec 19 07:46:24 unixarea kernel: [00:26:0b:4b:b8:44] new beacon on chan 1 > (bss chan 1) "OCLCPublic" rssi 64 > Dec 19 07:46:24 unixarea kernel: [00:26:0b:4b:b8:44] caps 0x431 bintval 100 > erp 0x100 country [NL 1-13,23] > Dec 19 07:46:24 unixarea kernel: wlan0: ieee80211_add_scan: chan 1g min > dwell met (2141573 > 2141495) > Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: chan 1g -> 6g [active, > dwell min 20ms max 49ms] > Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: stopped, [ticks 2141628, > dwell min 20 scanend 2141622] > Dec 19 07:46:24 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks > 2141675 duration 150 > Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: chan 1g -> 11g [active, > dwell min 20ms max 150ms] > Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: stopped, [ticks 2141840, > dwell min 20 scanend 2141825] > Dec 19 07:46:24 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks > 2141880 duration 150 > Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: chan 1g -> 7g [active, > dwell min 20ms max 150ms] > Dec 19 07:46:25 unixarea kernel: wlan0: scan_task: stopped, [ticks 2142046, > dwell min 20 scanend 2142030] > > > after this no more traffic can pass the wlan0 interface; its state is: > > > wlan0: flags=8843 metric 0 mtu 1500 > ether 80:1f:02:ee:16:37 > inet 10.49.30.104 netmask 0xff00 broadcast 10.49.30.255 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g > status: associated > ssid OCLCPublic channel 1 (2412 MHz 1
Re: Issues with urtwn
El día Wednesday, December 17, 2014 a las 06:58:09PM -0800, Adrian Chadd escribió: > ... > 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.) > ... > Hi, Here comes the messages from such 'wlandebug +scan'; please let me know if you need more tests/logs: ... Dec 19 07:41:24 unixarea kernel: wlan0: [00:26:0b:4b:b8:44] ieee80211_scan_assoc_success Dec 19 07:41:24 unixarea kernel: wlan0: link state changed to UP Dec 19 07:41:24 unixarea dhclient[1828]: send_packet: No buffer space available Dec 19 07:41:24 unixarea wpa_supplicant[1731]: wlan0: Associated with 00:26:0b:4b:b8:44 Dec 19 07:41:24 unixarea wpa_supplicant[1731]: wlan0: WPA: Key negotiation completed with 00:26:0b:4b:b8:44 [PTK=CCMP GTK=CCMP] Dec 19 07:41:24 unixarea wpa_supplicant[1731]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:26:0b:4b:b8:44 completed [id=2 id_str=] Dec 19 07:41:31 unixarea dhclient: New IP Address (wlan0): 10.49.30.104 Dec 19 07:41:31 unixarea dhclient: New Subnet Mask (wlan0): 255.255.255.0 Dec 19 07:41:31 unixarea dhclient: New Broadcast Address (wlan0): 10.49.30.255 Dec 19 07:41:31 unixarea dhclient: New Routers (wlan0): 10.49.30.1 I run in another terminal a cycle of a proc fetching a file with WGET from some sever; the lines are from ipmon for every WGET: Dec 19 07:41:47 unixarea ipmon[508]: 07:41:47.581028 wlan0 @0:14 p 10.49.30.104,37367 -> 132.174.1.212,80 PR tcp len 20 60 -S K-S OUT Dec 19 07:41:50 unixarea ipmon[508]: 07:41:50.803714 wlan0 @0:14 p 10.49.30.104,52814 -> 132.174.1.212,80 PR tcp len 20 60 -S K-S OUT Dec 19 07:41:53 unixarea ipmon[508]: 07:41:53.206811 wlan0 @0:14 p 10.49.30.104,53615 -> 132.174.1.212,80 PR tcp len 20 60 -S K-S OUT Dec 19 07:41:55 unixarea ipmon[508]: 07:41:55.872432 wlan0 @0:14 p 10.49.30.104,55755 -> 132.174.1.212,80 PR tcp len 20 60 -S K-S OUT ... Dec 19 07:46:23 unixarea ipmon[508]: 07:46:23.463618 wlan0 @0:14 p 10.49.30.104,46622 -> 132.174.1.212,80 PR tcp len 20 60 -S K-S OUT now the 300 sec bgscan intervall is over and the bgscan occurs: Dec 19 07:46:24 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 2141470 duration 150 Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: GuruDebug: Enable station power save mode Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: chan 1g -> 1g [active, dwell min 20ms max 150ms] Dec 19 07:46:24 unixarea kernel: [00:26:0b:4b:b8:44] new probe_resp on chan 1 (bss chan 1) "OCLCPublic" rssi 64 Dec 19 07:46:24 unixarea kernel: [00:26:0b:4b:b8:44] caps 0x431 bintval 100 erp 0x100 country [NL 1-13,23] Dec 19 07:46:24 unixarea kernel: [00:26:0b:4b:b8:44] new probe_resp on chan 1 (bss chan 1) "OCLCPublic" rssi 64 Dec 19 07:46:24 unixarea kernel: [00:26:0b:4b:b8:44] caps 0x431 bintval 100 erp 0x100 country [NL 1-13,23] Dec 19 07:46:24 unixarea kernel: [00:26:0b:4b:b8:44] new beacon on chan 1 (bss chan 1) "OCLCPublic" rssi 64 Dec 19 07:46:24 unixarea kernel: [00:26:0b:4b:b8:44] caps 0x431 bintval 100 erp 0x100 country [NL 1-13,23] Dec 19 07:46:24 unixarea kernel: wlan0: ieee80211_add_scan: chan 1g min dwell met (2141573 > 2141495) Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: chan 1g -> 6g [active, dwell min 20ms max 49ms] Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: stopped, [ticks 2141628, dwell min 20 scanend 2141622] Dec 19 07:46:24 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 2141675 duration 150 Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: chan 1g -> 11g [active, dwell min 20ms max 150ms] Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: stopped, [ticks 2141840, dwell min 20 scanend 2141825] Dec 19 07:46:24 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 2141880 duration 150 Dec 19 07:46:24 unixarea kernel: wlan0: scan_task: chan 1g -> 7g [active, dwell min 20ms max 150ms] Dec 19 07:46:25 unixarea kernel: wlan0: scan_task: stopped, [ticks 2142046, dwell min 20 scanend 2142030] after this no more traffic can pass the wlan0 interface; its state is: wlan0: flags=8843 metric 0 mtu 1500 ether 80:1f:02:ee:16:37 inet 10.49.30.104 netmask 0xff00 broadcast 10.49.30.255 nd6 options=29 media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g status: associated ssid OCLCPublic channel 1 (2412 MHz 11g) bssid 00:26:0b:4b:b8:44 country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 0 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS roaming MANUAL after some more time some pwr save queue flows over: Dec 19 07:50:59 unixarea kernel: wlan0: [00:26:0b:4b:b8:44] pwr save q overflow, drops 1 (size 50) Dec 19 07:51:01 unixarea kernel: wlan0: [00:26:0b:4b:b8:44] pwr save q overflo
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 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
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 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
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
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
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 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
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 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
Are you running wpa_supplicant? If you can connect to a plain network
with ifconfig, these will stop.
-Nathan
On 11/02/14 01:46, Matthias Apitz wrote:
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
___
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, 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 => 0xc > 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 => 0xc 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
On Tue, Sep 9, 2014 at 1:33 AM, Kevin Lo wrote: > On Mon, Sep 08, 2014 at 12:16:53PM -0300, Thiago Farina wrote: >> >> On Sun, Sep 7, 2014 at 11:36 PM, Adrian Chadd wrote: >> > 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). > Yep. Sorry. $ dmesg | grep urtw urtw0: on usbus4 urtw0: unknown RTL8187L type: 0x800 urtw0:rt181871 rf rtl8225u hwrev none -- 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
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 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 >> 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-un
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 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
On Mon, Sep 08, 2014 at 12:16:53PM -0300, Thiago Farina wrote: > > On Sun, Sep 7, 2014 at 11:36 PM, Adrian Chadd wrote: > > Hi, > > > > On 7 September 2014 19:16, Thiago Farina wrote: > >> On Sun, Sep 7, 2014 at 12:09 PM, Nathan Whitehorn > >> 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
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 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
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 Sun, Sep 7, 2014 at 11:36 PM, Adrian Chadd wrote: > Hi, > > On 7 September 2014 19:16, Thiago Farina wrote: >> On Sun, Sep 7, 2014 at 12:09 PM, Nathan Whitehorn >> 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
> 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
Hi Matthias,
On Mon, 8 Sep 2014 09:32:29 +0200
Matthias Apitz wrote:
> 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.
psk="N@tur%Wieser"
and
psk=b853709a9edcd50edf0835f68bf099255cb32fc462e492117fe3c42ab2a387cb
are equivalent.
If you have troubles to configure it manually, I recommend to try
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.
If this doesn't work, there might be a problem in the (1) lower layer
(driver), (2) AP, or (3) HW in general. If so, to debug it might be a
complex issue suitable for a bug entry.
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
Hi Matthias,
On Mon, 8 Sep 2014 07:47:34 +0200
Matthias Apitz 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
Please file PR entries for each of the problems you're seeing.
I don't use the USB devices and I have my hands full with the atheros and
Intel stuff as it is.
Thanks!
Adriabln
On Sep 7, 2014 10:47 PM, "Matthias Apitz" wrote:
> El día Sunday, September 07, 2014 a las 07:36:27PM -0700, Adrian Chadd
> escribió:
>
> > > 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?
>
> Hi,
>
> I do not know if this helps. I adquired some weeks ago a small USB
> adapter which presents itself in HEAD as:
>
> ugen4.4: at usbus4
> urtwn0:
> on usbus4
> urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
> wlan0: Ethernet address: 80:1f:02:ee:16:37
>
> I have no problems at all at my home AP (doing WPA PSK). The 'dongle' is
> very small, only 5-6mm are looking out of the laptop after you plug it
> in. The 6 euro investment ended all my searches to get the laptop's
> Broadcom BCM4312 working.
>
> 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
> --
> 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, September 07, 2014 a las 07:36:27PM -0700, Adrian Chadd escribió:
> > 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?
Hi,
I do not know if this helps. I adquired some weeks ago a small USB
adapter which presents itself in HEAD as:
ugen4.4: at usbus4
urtwn0: on
usbus4
urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
wlan0: Ethernet address: 80:1f:02:ee:16:37
I have no problems at all at my home AP (doing WPA PSK). The 'dongle' is
very small, only 5-6mm are looking out of the laptop after you plug it
in. The 6 euro investment ended all my searches to get the laptop's
Broadcom BCM4312 working.
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
--
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, On 7 September 2014 19:16, Thiago Farina wrote: > On Sun, Sep 7, 2014 at 12:09 PM, Nathan Whitehorn > 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"
Re: Issues with urtwn
On Sun, Sep 7, 2014 at 12:09 PM, Nathan Whitehorn 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. -- 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
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
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
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
On 09/07/14 08:28, Adrian Chadd wrote: On 7 September 2014 08:09, Nathan Whitehorn 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
On 7 September 2014 08:09, Nathan Whitehorn 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"
