On Wed, Mar 3, 2010 at 9:18 AM, Jouni Malinen <j...@w1.fi> wrote: > On Wed, Mar 03, 2010 at 10:10:49AM +0900, Bruno Randolf wrote: >> On Tuesday 02 March 2010 18:42:38 Jouni Malinen wrote: >> > If we want to have an option to prevent hardware from touching the frame >> > payload, that really should be an option (a radiotap and TX control >> > flags, etc.), not default functionality for monitor interface. > >> yes, we use it for testing IBSS mode (merging, TSF updates) by injecting >> custom beacons. i guess other packet injectors would also assume that their >> packets go out untouched. > > Like I said, not all packet injectors do and hostapd certainly depends > on the injected packet being updated (both for contents and for > selecting a suitable TX rate and also to encrypt the frame when a key is > set for this). > >> so what would be a way to support that properly? >> what about a monitor mode flag? > > My preference is shown in the quoted text above, i.e., a new radiotap > (per packet, not per monitor interface) flag and then internally in > mac80211--driver a new TX control flag to indicate that the frame is not > to be updated. > > -- > Jouni Malinen PGP id EFC895FA >
Shouldn't making this depend on COOK_FRAMES not being set be enough? A while ago, the consensus was that injectors that don't set COOK_FRAMES (should) expect packets to be transmitted unmodified. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
