Here's the answer from damien@ I think it's still too early to commit this port.
bye, david ---------- Forwarded message ---------- From: <[email protected]> Date: Wed, May 6, 2009 at 9:17 AM Subject: Re: [Testing aircrack-ng (Was Re: NEW: security/aircrack-ng)] To: David Coppa <[email protected]> Cc: "Federico G. Schwindt" <[email protected]> The problem is that aircrack-ng is now injecting raw control frames through bpf. Most of our drivers aren't prepared to send control frames. Many aren't even capable of sending control frames (because hardware and/or firmware does not permit it.) The correct fix would be to deal with control frames properly in the Tx path if the hardware is capable of sending such frames or to drop them. The proposed patch that consists in removing the check in ieee80211_get_hdrlen() is not a good solution (even though it may work for ral(4)). I'm still trying to figure out how to handle this properly. This is not easy because we have many drivers for very different hardware. Damien On Wed, May 6, 2009 at 1:40 AM, Benoit Lecocq <[email protected]> wrote: > Matthias Kilian a écrit : >> On Tue, May 05, 2009 at 07:55:23PM +0100, Federico G. Schwindt wrote: >>>> aireplay-ng --test <interface> causes a kernel panic. >>>> I'm waiting for an answer by Damien Bergamini... >>>> >>>> The critical function is do_attack_test() that starts at line 4868 of >>>> aireplay-ng.c >>> sorry if i'm jumping in late, i've been on holidays. >>> >>> i think this should go in now (as i've already mentioned in the >>> past), so we can make it work properly and fix any possible >>> issues with the drivers. >>> >>> has this been commited already? are the issues fixed? apologies >>> if this has been mentioned already, still catching with my >>> emails, but i don't see any followup in this thread. >> >> I'll do some ports-wise checks and some loose tests and commit it >> tomorrow. >> >> > > Thanks ! That will be cool if you can commit rc3 tomorrow ! > > Cheers, > benoit >
