On Wed, 2008-07-09 at 16:00 +0200, Michael Buesch wrote: > On Wednesday 09 July 2008 16:04:50 Ivo van Doorn wrote: > > On Wednesday 09 July 2008, Michael Buesch wrote: > > > On Wednesday 09 July 2008 15:11:45 Ivo van Doorn wrote: > > > > Currently only beacons generated in AP mode have the software > > > > sequence number inserted. This means IBSS and Mesh mode are broken > > > > for all hardware that require software sequence numbers. > > > > > > Does software seq numbering even work at all? > > > What about packets that get sent between the driver requested the > > > beacon and the driver does actually queue it? > > > > For rt2x00 the beacon is requested and queued within interrupt context > > Well, another CPU could be in progress of walking down the mac80211 TX code > and aquire a sequence number in the meantime before you requested the beacon. > However that frame will be blocked by your driver locks, so the two seq > numbers of the beacon and the other frame will be swapped, as the driver > will queue the beacon first. Indeed, I was wrong. I wonder if we should remove the hwseq support completely. It's much easier for the driver to do this, especially since we pass a vif pointer with driver-private data to all relevant functions and the driver could keep the current sequence number in there. Or, just like hwseq would, keep a global sequence number? How does that affect multi-bss support btw? Do we have to use sw seqno for that? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
