Date: Fri, 4 Feb 2011 13:14:17 +0100 From: Bernhard Schmidt <bschmidt@freebsd.org> To: Alexander Zagrebin <alex@zagrebin.ru> Cc: freebsd-net@freebsd.org, PseudoCylon <moonlightakkiy@yahoo.ca> Subject: Re: if_run in hostap mode: issue with stations in the power save mode Message-ID: <201102041314.17939.bschmidt@freebsd.org> In-Reply-To: <20110204114021.GA237@gw.zagrebin.ru> References: <20110204060808.GA97298@gw.zagrebin.ru> <201102040951.34201.bschmidt@freebsd.org> <20110204114021.GA237@gw.zagrebin.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 04 February 2011 12:40:21 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 thought about such solution, and it looks more right, but I've > decided just to add ieee80211_beacon_update() to make the patch > clear. I'll try your patch a bit later, but I already have a > question: on the first invocation of the run_update_beacon_cb() only > ieee80211_beacon_alloc() will be called. So dynamic beacon contents > will not updated. Is it a problem? I don't think it is. The work beacon_update does is handling changes to bo_flags, which are only changed through calls to iv_update_beacon(), so this is safe, because the driver itself does change bo_flags which is immediately followed by the beacon update process. There is one expection I'm not sure about how to handle though, slottime. This value might change based on nodes associating and leaving, resulting in a call to ic_updateslot() which is currently commentted out. Basically there needs to be another call to run_update_beacon_cb() in that function, of course based on the current opmode. > Also I have to note, that it seems that other wlan drivers can has > this problem too: only ral's and ath's code uses > ieee80211_beacon_update(). Yeah, true. > Also, I've found a kern/124753. One of > replies contains a log's fragment with many records, like following: > kernel: ath0: [00:18:41:c0:06:54] power save mode on, 1 sta's in ps > mode kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 now > queued kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 2 > now queued kernel: ath0: [00:18:41:c0:06:54] power save mode off, 0 > sta's in ps mode kernel: ath0: [00:18:41:c0:06:54] flush ps queue, 2 > packets queue But there are no records, which have to be for a PSM > enabled stations: When a beacon is properly updated, then we have to > see records about 1. TIM updating, like > ieee80211_beacon_update: TIM updated, pending 1, off 0, len 1 > 2. poll messages from a stations, like > wlan0: [18:86:ac:10:4b:88] recv ps-poll, send packet, queue > empty > > Thanks for your cooperation! You mean there are missing debug messages in net80211/run? -- Bernhard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102041314.17939.bschmidt>