Date: Sun, 6 Feb 2011 11:32:40 +0100 From: Bernhard Schmidt <bschmidt@freebsd.org> To: Alexander Zagrebin <alex@zagrebin.ru> Cc: freebsd-net@freebsd.org Subject: Re: if_run in hostap mode: issue with stations in the power save mode Message-ID: <201102061132.41032.bschmidt@freebsd.org> In-Reply-To: <20110204223339.GA12555@gw.zagrebin.ru> References: <20110204060808.GA97298@gw.zagrebin.ru> <201102040951.34201.bschmidt@freebsd.org> <20110204223339.GA12555@gw.zagrebin.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 04 February 2011 23:33:40 Alexander Zagrebin wrote: > Hi! > > On 04.02.2011 09:51:34 +0100, Bernhard Schmidt wrote: > > On Friday 04 February 2011 07:08:08 Alexander Zagrebin wrote: > > > I'm using an Ralink RT2870 based adapter (run(4) driver) in the > > > hostap mode. and I've noticed that if_run doesn't support > > > stations working in the power save mode (PSM). The reason is in > > > lack of the TIM in beacons. The attached patch adds this > > > functionality and completely fixes this issue. Despite the fact > > > that patch is working, it seems that it needs an additional > > > work. For example, now the result of ieee80211_beacon_update is > > > ignored with a corresponding message, but may be necessary to > > > process it... > > > > > > Can somebody review it? > > > > That looks about right, good catch! > > > > Handling ieee80211_beacon_update()'s return value doesn't seem to > > be necessary, the mbuf's length is handled in the next few lines > > of code anyways, doesn't matter if it changed or not. > > > > Though, I have a some doubts about just restoring bo_flags is > > enough (Can't prove that with some obvious code, still..). It > > feels saner to me if we just reuse the whole mbuf, similar to what > > ath(4) does. Can you look at attached patch? Completely untested, > > so I'm not sure what does happen on e.g. changing the SSID. > > I've tried the slightly modified version of your patch (see attached > files), and found that it is working too. Moreover, it looks more > safe. For example, suppose we need update the beacon due to a new > TIM. Immediately after updating, but before the beacon with a TIM > will be transmitted, we need update the beacon again for any other > reason. With the first version of the patch the beacon will > completely recreated, so a TIM will be lost. But if we are using the > second version of the patch, then TIM will be preserved. Yeah, correct, that was my intention. I see you also fixed the remaining RUN_VAP() calls I've missed, thanks for that. :) > I had the doubts about ability to change or hide/unhide the SSID, but > it works too. It seems that after `ifconfig wlan0 ssid ...` or > `ifconfig wlan0 (hidessid|-hidessid)` the following occurs: > 1. run_newstate() is called > 2. run_newstate() invokes run_update_beacon_cb() > 3. run_update_beacon_cb() invokes ieee80211_beacon_update() > But I couldn't understand where ieee80211_beacon_update() can change > a SSID... As I see it, it can't. Only a call to ieee80211_beacon_construct() would do that. Can I talk you into figuring out what's going on here? Getting a definitive statement about SSID changes are correctly handled (by means of a trace) would help alot. Thanks. -- Bernhard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102061132.41032.bschmidt>