On Mon, Dec 15, 2008 at 12:16 PM, Bob Copeland <me@xxxxxxxxxxxxxxx> wrote: > On Mon, Dec 15, 2008 at 11:12 AM, Stefanik Gábor > <netrolller.3d@xxxxxxxxx> wrote: >> That is not the problem - aireplay-ng operates on a monitor interface >> that is already up. Likely this patch somehow misses monitor >> interfaces. > > Agreed, that is probably the case. Reverting that hunk makes it come up > with the eeprom mac without adding any interface. Looking at the > add_interface() code, it 'should' program the mac for monitor interfaces > too, so offhand I'm not sure, will take a look tonight. Okay, so that I understand the problem a bit better: what used to happen and what does not happen now? Is the ath5k device not sending ACKs, or not passing any frames back to the host? The code, for mac address setting at least, looks to be working as designed: the mac address is only set up at add_interface time to avoid automatically acking packets before an interface is brought up (see the kerneldoc comments in mac80211 on add/remove_interface). The ath5k rx filter for unicast frames requires mac addresses to match in order to accept or ack frames. However, in monitor mode, mac80211 will never call add_interface(). Instead, it should configure the filter to put the card in promiscuous mode which then should enable all packets to be passed back to the host. Does the fragmentation attack also work with e.g. b43 (which also only sets up the mac at add_interface time)? -- Bob Copeland %% www.bobcopeland.com -- 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
