So, strangely enough (!) FreeBSD's net80211 code has similar problems with TX and flushing. Luckily (again, !) FreeBSD has a "raw" transmit path for things like this, which is used for things such as probe requests and such. But it's all a bit hairy and unclear. There's a double problem - if you have frames in the raw transmit path that have a sequence number or a CCMP IV number, those need to stay in order, or things also go boom. Linux works around this by holding a lock across the whole TX path, so things are "naturally" serialised this way. I'm fixing this particular issue differently in FreeBSD. Anyway, the main problem is making sure frames go out "right". Right now, there's strange issues where probe requests that are queued get flushed when the scan code goes to set a new channel. So (after a few things like IBSS QoS, IBSS 11n and the last bits of power save / ps-poll handling that i'm fixing up) go into FreeBSD's wireless code, I'm likely going to revamp the scan and off-channel code. At the very least I'm going to make it so a VAP doesn't change a channel immediately - it marks the VAP as not accepting further frames, then it waits for the TX queue to flush before it changes code (with a _hard_ timeout..) and then a notice will go back to the scan code tos ay that the channel change has completed. Anyway, fun times.. adrian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
