From owner-freebsd-wireless@FreeBSD.ORG Thu Dec 18 02:58:11 2014 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF1D0B3A; Thu, 18 Dec 2014 02:58:11 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BD29BE2; Thu, 18 Dec 2014 02:58:11 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id h11so313701wiw.1; Wed, 17 Dec 2014 18:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+M28PevSJEwkP2wy6Xzp0855Q9hQn8QRZ6DCQWjTl8w=; b=IqDFMyK/hC9u9j+zRUmEDoEDc9UHsFMYCoOQ6LhvzPQQKtoJwJ4Ve5xdllCr52/oyz zJWiYAquFWfvwWwvEzSq5NcUsICkK0k+1Np/52ArnOlTlwEgt9/4tGpxKDpGR8LBLJVO WmNjjXdnmZV8z4Gxps5TkbkBkO3k2J0xmu9SIB0d+oM7ixbeBUEVJarvvh7dEC0rZE4C yPPyrV3z/YxPcnqBMCS+ySQWrL7DWAyFbcRpo2FjJ/xR/svJsSO9sxN771hYUmnNJGex i8HXypG+sZIZlHJHGx6UNIMiK8Hx7KC2UfBz9frbHXyzlzifGKyfL/0ioGz04t7HIQJX GmGA== MIME-Version: 1.0 X-Received: by 10.194.108.9 with SMTP id hg9mr39511139wjb.68.1418871489923; Wed, 17 Dec 2014 18:58:09 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Wed, 17 Dec 2014 18:58:09 -0800 (PST) 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> <20141103054633.GA3258@unixarea.DDR.dd> <20141103095530.GA42402@unixarea.DDR.dd> <20141123163811.GA5739@unixarea.DDR.dd> Date: Wed, 17 Dec 2014 18:58:09 -0800 X-Google-Sender-Auth: ha45a5OByCQko0IyF5Ye4rqfo1E Message-ID: Subject: Re: Issues with urtwn From: Adrian Chadd To: Matthias Apitz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-wireless@freebsd.org" , Nathan Whitehorn X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 02:58:12 -0000 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 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.