On Wed, 2010-03-24 at 20:15 +0900, Bruno Randolf wrote: > On Wednesday 24 March 2010 00:50:31 Michael Stahn wrote: > > > similar to this we would also need to be able to specify that the beacon > > > TSF should not be overwritten. maybe a general flag like "do not change" > > > would do? > > > > Is TSF really overwritten at manual injection from userspace? > > Yes, it is, at least on ath5k. And as jouni has pointed out recently this > behaviour is expected by hostapd (maybe not for beacons but for probe > request/response frames, i dont know). > > Gabor Stefanik proposed a while ago that frames should only be modified by the > driver in cooked monitor mode (COOK_FRAMES), that way we could avoid defining > new radiotap flags. What's your view on that, Jouni? Maybe we could create a socket option that would put a _socket_ into a cooked monitor mode? A "monitor mode socket" would accept and transmit packets with radiotap and 802.11 headers and receive the packets that the interface already receives, also with radiotap and 802.11 headers. That interface could be optimized for use with hostapd and other similar programs. The driver could fill some data from the interface settings. The monitor mode, on the other hand, could be optimized for the "hardcore" stuff when the driver interferes as little as possible. Then no special flags would be needed to pass the frame as is. -- Regards, Pavel Roskin -- 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
