On Wed, Mar 24, 2010 at 8:43 PM, Pavel Roskin <proski@xxxxxxx> wrote: > 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 > I don't think that is needed, as we already support multiple monitor interfaces (including a situation where some are cooked, others are raw). -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- 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
