Date: Wed, 17 Dec 2014 18:58:09 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Matthias Apitz <guru@unixarea.de> Cc: "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org>, Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: Re: Issues with urtwn Message-ID: <CAJ-VmomHguekQzfJ17gbK4_tTsuDPCfkDOjcTmviddDrmEEzoQ@mail.gmail.com> In-Reply-To: <20141123163811.GA5739@unixarea.DDR.dd> References: <20141026073605.GA1819@unixarea.DDR.dd> <20141101081736.GA2857@unixarea.DDR.dd> <20141102084605.GA60031@unixarea.DDR.dd> <54564C92.8040104@freebsd.org> <20141102152953.GA20263@unixarea.DDR.dd> <54564E4D.4020703@freebsd.org> <CAJ-Vmomhzsyn0k5Ym1=qm-LibJmW=8zb2LunYHNf4sSvWsP1=w@mail.gmail.com> <20141103054633.GA3258@unixarea.DDR.dd> <20141103095530.GA42402@unixarea.DDR.dd> <CAJ-Vmokn_Kqos%2B7HhN0EmB6JohD3g%2BVaXaqkhG-6%2BYZkgDoZFA@mail.gmail.com> <20141123163811.GA5739@unixarea.DDR.dd>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3D0, 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=3D0, 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 <guru@unixarea.de> wrote: > El d=C3=ADa Monday, November 03, 2014 a las 09:43:14AM -0800, Adrian Chad= d escribi=C3=B3: > >> 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, t= icks 36537257 duration 150 > Nov 23 17:18:33 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power sav= e mode on > Nov 23 17:18:33 unixarea kernel: wlan0: scan_task: chan 7g -> 1g [act= ive, dwell min 20ms max 150ms] > Nov 23 17:18:33 unixarea kernel: wlan0: scan_task: stopped, [ticks 365374= 15, 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=3D1 > 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 wi= th age 40, 1 now queued > Nov 23 17:18:34 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame wi= th age 0, 2 now queued > Nov 23 17:18:34 unixarea kernel: wlan0: ieee80211_sta_tim_notify: TIM=3D1 > 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 wi= th age 0, 3 now queued > Nov 23 17:18:35 unixarea kernel: wlan0: ieee80211_sta_tim_notify: TIM=3D1 > ... > > 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, guru@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 zie= hen.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomHguekQzfJ17gbK4_tTsuDPCfkDOjcTmviddDrmEEzoQ>