From owner-freebsd-wireless@freebsd.org Tue Feb 23 06:26:38 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4114CAB068F for ; Tue, 23 Feb 2016 06:26:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10C21E10; Tue, 23 Feb 2016 06:26:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x236.google.com with SMTP id z135so203318261iof.0; Mon, 22 Feb 2016 22:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=C6RiK8KBdQjKI7EhhT/w4IPAYSO1ULzgVIiK7SkBqQg=; b=p5JDF+JlnfH1BICLmDAMNOTean6PwREh5Mx3s+yFN8SOdUd3khpFaUOuSFUnEnUNb0 yecWsoAj8I3RqY8GJ8sBvpWTltM53XR+ZSJe6bQJnidvSoT+DklI1U9wJGlblfZ8jxRk QxUHoF4ubXv8u00N08dCoj0E0pkU4O/rs0HtxUGNLHPNV1JDdn2Tvlf38XJFcgDWwbvl 1Zos2VVIyasLfWpsZWpcEgdAW3Osu/l+zMnh/Gy0H9n9741qTqubBnyU9Kvf3PC4cXYS /tZeoZlvvEIzrZVbfSb3sL9NSMnLmAarhSqTl84NW+cvdfpMrujgbTrIfE3pZL4j8jh+ 7GIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=C6RiK8KBdQjKI7EhhT/w4IPAYSO1ULzgVIiK7SkBqQg=; b=BZ1rbiebuxMw1XKT4OEK3Qt1noaDKAoiTqvvUJ+pBTH+PZVssSw2H8rkz8oINlf3rm QcFwh1fCAFF5IoCZtPewtwbxVp8EeZDVZ8nBI6XGz70qMyuezvhpHFzk9646eefXIMDr yEtjSHA/jOJxtwwqzquUgzN5mlSXLqfq7POulBqwJ0j2lpBa0yyxAjaazyWWgWuS4IMN JrLrMfmqMeIeaZ2rsnAB9bev2krRQjoGtbsHhzaWuR74De07u/VItf+Ojizhyx2TAJm5 IQbN4glsA8ZH63eBg+ym1KHlbCXncKFcJ+lV4Jq2qfAwTpBzbV0o8eKEBj3U1FilwiWg h8Nw== X-Gm-Message-State: AG10YOT30qoPeR32kZDIcuJYdf2p6Yf3QqpbwX4wOqfd4zp7P/8LTbwW12c2mCxIDjlDBzVrJ/4sHGqRRJy5Fg== MIME-Version: 1.0 X-Received: by 10.107.162.144 with SMTP id l138mr30218362ioe.123.1456208797482; Mon, 22 Feb 2016 22:26:37 -0800 (PST) Received: by 10.36.14.19 with HTTP; Mon, 22 Feb 2016 22:26:37 -0800 (PST) In-Reply-To: References: Date: Mon, 22 Feb 2016 22:26:37 -0800 Message-ID: Subject: Re: net80211 inactivity processing From: Adrian Chadd To: Andriy Voskoboinyk Cc: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 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: Tue, 23 Feb 2016 06:26:38 -0000 On 22 February 2016 at 09:39, Andriy Voskoboinyk wrote: > Mon, 22 Feb 2016 03:43:51 +0200 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Adrian Chadd > : > > Because control frames are disabled by default? (the timer is refreshed > every time when a frame goes into input path (ni->ni_inact =3D > ni->ni_inact_reload)). > This may be added to TX callback (already implemented in > https://reviews.freebsd.org/D5147); however, I have no idea what to do wi= th Right. I need to go digging a little more about it. It's a good catch; I just need to see whether to kill the code or whether to go back to the older way of handling node expiry. -a > > >> drivers that lie about frame completion/failure > > >> Hi, >> >> I think it is a hold-over from how node reclaimation used to work. >> Sending null data frames to probe if a station is still there is a >> common thing to do. So yeah, maybe we should go figure out why the >> inactivity timer isn't kicked if the NULL data frame succeeds (ie, the >> driver explicitly gives us ACK feedback, rather than drivers that lie >> about frame completion/failure.) >> >> >> >> -adrian >> >> >> On 21 February 2016 at 16:34, Andriy Voskoboinyk wrot= e: >>> >>> Hi, >>> >>> What is the purpose of the following code? (especially in HOSTAP mode) >>> (ieee80211_node.c): >>> >>> static void >>> ieee80211_timeout_stations(struct ieee80211com *ic) >>> { >>> struct ieee80211_node_table *nt =3D &ic->ic_sta; >>> struct ieee80211vap *vap; >>> struct ieee80211_node *ni; >>> int gen =3D 0; >>> >>> IEEE80211_NODE_ITERATE_LOCK(nt); >>> gen =3D ++nt->nt_scangen; >>> restart: >>> IEEE80211_NODE_LOCK(nt); >>> TAILQ_FOREACH(ni, &nt->nt_node, ni_list) { >>> ... >>> if ((vap->iv_flags_ext & IEEE80211_FEXT_INACT) = && >>> (0 < ni->ni_inact && >>> ni->ni_inact <=3D vap->iv_inact_probe) && >>> ni->ni_rates.rs_nrates !=3D 0) { >>> IEEE80211_NOTE(vap, >>> IEEE80211_MSG_INACT | >>> IEEE80211_MSG_NODE, >>> ni, "%s", >>> "probe station due to inactivity"); >>> /* >>> * Grab a reference before unlocking th= e >>> table >>> * so the node cannot be reclaimed befo= re >>> we >>> * send the frame. >>> ieee80211_send_nulldata >>> * understands we've done this and >>> reclaims >>> the >>> * ref for us as needed. >>> */ >>> ieee80211_ref_node(ni); >>> IEEE80211_NODE_UNLOCK(nt); >>> ieee80211_send_nulldata(ni); >>> <<< >>> here >>> /* XXX stat? */ >>> goto restart; >>> } >>> ... >>> } >>> IEEE80211_NODE_UNLOCK(nt); >>> >>> IEEE80211_NODE_ITERATE_UNLOCK(nt); >>> } >>> >>> As for me, ieee80211_send_nulldata() will not refresh ni->ni_inact, >>> nor will trigger any data transmission from the STA (so, it does >>> nothing?). >>> _______________________________________________ >>> freebsd-wireless@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>> To unsubscribe, send any mail to >>> "freebsd-wireless-unsubscribe@freebsd.org"