From owner-freebsd-net@FreeBSD.ORG Tue Feb 8 08:24:34 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D61F106564A; Tue, 8 Feb 2011 08:24:34 +0000 (UTC) (envelope-from alex@zagrebin.ru) Received: from mail.zagrebin.ru (gw.zagrebin.ru [91.215.205.128]) by mx1.freebsd.org (Postfix) with ESMTP id B93418FC12; Tue, 8 Feb 2011 08:24:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=pVqfatzhvy2ovgqAQ+cFEPgk06wjg2H1SabJHn1M5Mw=; b=s1EZieDeAnTlNYW3fID8N8Cr5vSRR/BtY41bq0N6sK440a+Da4UVlDCJX8z4Y0q+gpoxvq4Nle3FUj/cj5bZfb1k6EwmRCG98/Sa5zuY4zslzvycsR9wlpHQ+NhwXjY54ZDYvauvOvzGL21FZzBFkDzujGk3dk2nKFlorIE4qO4=; Received: from alex by mail.zagrebin.ru with local (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pmis9-000Lsg-JF; Tue, 08 Feb 2011 11:24:29 +0300 Date: Tue, 8 Feb 2011 11:24:29 +0300 From: Alexander Zagrebin To: Bernhard Schmidt Message-ID: <20110208082428.GA83490@gw.zagrebin.ru> References: <20110204060808.GA97298@gw.zagrebin.ru> <201102061132.41032.bschmidt@freebsd.org> <20110207061001.GB59910@gw.zagrebin.ru> <201102070911.02791.bschmidt@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <201102070911.02791.bschmidt@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org, PseudoCylon Subject: Re: if_run in hostap mode: issue with stations in the power save mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 08:24:34 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! On 07.02.2011 09:11:02 +0100, Bernhard Schmidt wrote: > For example, if you call 'ifconfig wlan0 ssid ' the new ssid is > passed over using a IOCTL. It would be interesting to know what function > in net80211 are called regarding beacon updates and which of those call > into the run driver. Ultimately it's about figuring out if special > handling for such cases are required and if so, how to do it. I've added a debug output on allocation, changing and deallocation of a beacon into if_run.c and tried to change SSID while the net.wlan.0.debug is -1. Here is the log contents: kernel: wlan0: ieee80211_init kernel: wlan0: start running, 1 vaps running kernel: wlan0: ieee80211_new_state_locked: RUN -> SCAN (nrunning 0 nscanning 0) kernel: wlan0: ieee80211_newstate_cb: RUN -> INIT arg 0 kernel: wlan0: hostap_newstate: RUN -> INIT (0) kernel: wlan0: node_reclaim: remove 0xffffff8003bd7000<00:14:d1:a8:66:1d> from station table, refcnt 1 kernel: wlan0: ieee80211_alloc_node 0xffffff8004eae000<00:14:d1:a8:66:1d> in station table kernel: wlan0: [00:14:d1:a8:66:1d] ieee80211_alloc_node: inact_reload 2 kernel: wlan0: ieee80211_newstate_cb: INIT -> SCAN arg 0 kernel: wlan0: hostap_newstate: INIT -> SCAN (0) kernel: wlan0: ieee80211_create_ibss: creating HOSTAP on channel 6 kernel: wlan0: ieee80211_alloc_node 0xffffff8003bd7000<00:14:d1:a8:66:1d> in station table kernel: kernel: wlan0: [00:14:d1:a8:66:1d] ieee80211_alloc_node: inact_reload 2 kernel: wlan0: set WME_AC_BE (chan) [acm 0 aifsn 3 logcwmin 4 logcwmax 6 txop 0] kernel: wlan0: set WME_AC_BE (bss ) [acm 0 aifsn 3 logcwmin 4 logcwmax 10 txop 0] kernel: wlan0: set WME_AC_BK (chan) [acm 0 aifsn 7 logcwmin 4 logcwmax 10 txop 0] kernel: wlan0: set WME_AC_BK (bss ) [acm 0 aifsn 7 logcwmin 4 logcwmax 10 txop 0] kernel: wlan0: set WME_AC_VI (chan) [acm 0 aifsn 1 logcwmin 3 logcwmax 4 txop 94] kernel: wlan0: set WME_AC_VI (bss ) [acm 0 aifsn 2 logcwmin 3 logcwmax 4 txop 94] kernel: wlan0: set WME_AC_VO (chan) [acm 0 aifsn 1 logcwmin 2 logcwmax 3 txop 47] kernel: wlan0: set WME_AC_VO (bss ) [acm 0 aifsn 2 logcwmin 2 logcwmax 3 txop 47] kernel: wlan0: ieee80211_wme_updateparams_locked: WME params updated, cap_info 0x6 kernel: wlan0: ieee80211_new_state_locked: SCAN -> RUN (nrunning 0 nscanning 0) kernel: wlan0: ieee80211_newstate_cb: SCAN -> RUN arg -1 kernel: run0: run_update_beacon_cb: updating beacon kernel: wlan0: ieee80211_beacon_update: traffic 0, enable aggressive mode kernel: wlan0: update WME_AC_BE (chan+bss) [acm 0 aifsn 2 logcwmin 4 logcwmax 10 txop 0] kernel: wlan0: update WME_AC_BE (chan+bss) logcwmin 3 kernel: wlan0: ieee80211_wme_updateparams_locked: WME params updated, cap_info 0x7 kernel: wlan0: hostap_newstate: SCAN -> RUN (-1) kernel: wlan0: synchronized with 00:14:d1:a8:66:1d ssid "test" channel 6 start 0Mb kernel: wlan0: [00:14:d1:a8:66:1d] ieee80211_node_authorize: inact_reload 20 As you can see, run_update_beacon_cb() is invoked, but at this time the beacon is already allocated. As the beacon is allocated, run_update_beacon_cb() invokes ieee80211_beacon_update(). As we know, the ieee80211_beacon_update() doesn't update the SSID, so the SSID remains untouched. Nevertheless the changing or hiding/unhiding a SSID seems to be working. It is possible to explain: the station uses an active scan. The ieee80211_send_proberesp()/ieee80211_alloc_proberesp() returns the frame, containing an updated SSID, but AP continues to broadcast beacon with the outdated data. The possible solution is to deallocate a beacon on a state change. I've decided to deallocate a beacon on 'to RUN' state transition. The additional patch is attached. I'll do an additional tests later today... -- Alexander Zagrebin --oyUTqETQ0mS9luUI Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="patch-if_run.c" --- /sys/dev/usb/wlan/if_run.c.orig 2011-02-08 09:52:18.994743647 +0300 +++ /sys/dev/usb/wlan/if_run.c 2011-02-08 11:04:17.114484851 +0300 @@ -1793,6 +1793,12 @@ run_newstate(struct ieee80211vap *vap, e sc->runbmap |= bid; } + if (rvp->beacon_mbuf) { + m_freem(rvp->beacon_mbuf); + rvp->beacon_mbuf = NULL; + } + switch (vap->iv_opmode) { case IEEE80211_M_HOSTAP: case IEEE80211_M_MBSS: --oyUTqETQ0mS9luUI--