On Mon, Jan 12, 2009 at 03:48:22PM +0100, Johannes Berg wrote: > On Mon, 2009-01-12 at 16:26 +0200, Jouni Malinen wrote: > > + /* Extra IE data for management frames */ > > + u8 *ie_probereq; > > + size_t ie_probereq_len; > > + u8 *ie_proberesp; > > + size_t ie_proberesp_len; > It'd be more memory efficient on 64-bit to not alternate between 64 and > 32 bit values, but I don't really care too much in this struct. Yeah.. I could reorder or even change the _len to be u16, but it is probably cleaner to just leave it as-is taken into account there is only one of these structs per virtual interface. > Should we sanity-check the input? E.g. in nl80211, ensure that it's > (<type><len><data...>)* with <len> being correct and no final padding? > And maybe that there isn't anything in those IEs that we've already > added, like an SSID? I would actually like to be able to include invalid data for testing purposes and some frames might even not require an IE in the end. Action frames would be an example of this, but those would require category and code fields to allow more detailed selection of which frames to extend. That can be added in the future, if a reasonable use is found. Anyway, I would not bother adding validating the provided input. As far as figuring out whether there are any IEs that we (as in mac80211) have added gets bit complex taken into account that we do not know that at the time this command is run. It is even more complex for firmware-generated frames. Furthermore, it is unclear what exactly we should do if a duplicate IE is found. With some IEs, it is actually find to have multiple occurrences in the same frame. If we would like to provide more intelligent processing of such things, it would probably have to be done on case by case basis and with different rules for each IE depending on the subtype. For example, some IEs might be used to replace the generated IE while others would be added and some might trigger some kind of error notification to userspace when the frame is being transmitted, etc. This gets very complex and I would rather not go there before someone comes with a very good justification and use case explaining why it is needed.. -- Jouni Malinen PGP id EFC895FA -- 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
