Page 5 of 8

PostPosted: Wed Jul 27, 2005 10:15 am
by syrou
Hi,

Does anyone get a segmentation fault when trying to change mac with patched 20050525 madwifi drivers?

PostPosted: Wed Jul 27, 2005 10:26 am
by Dutch
syrou wrote:Hi,

Does anyone get a segmentation fault when trying to change mac with patched 20050525 madwifi drivers?

Works fine here..

Dutch

PostPosted: Wed Jul 27, 2005 11:42 am
by syrou
Thanks Dutch, forgot to tell that I have an Ubuntu Hoary 2.6.10 stock kernel. Strange...

PostPosted: Wed Jul 27, 2005 1:27 pm
by devine
syrou wrote:Thanks Dutch, forgot to tell that I have an Ubuntu Hoary 2.6.10 stock kernel. Strange...


I also get that segmentation fault when changing the mac address (kernel 2.6.11.7). I'll look into it.

PostPosted: Wed Jul 27, 2005 1:54 pm
by Dutch
devine wrote:I also get that segmentation fault when changing the mac address (kernel 2.6.11.7). I'll look into it.

Works fine here, 2.6.11-4 kernel. Just for kicks, you do remember to have the if down, when changing the MAC address ?
I.E. :
ifconfig ath0 down
ifconfig ath0 hw ether 00:00:DE:AD:BE:EF
ifconfig ath0 up

On an another note, beta 11 can't reinject and capture as fast as beta 3.
With beta3 I could reinject with -x 800 and still capture with airodump. (Used the old madwifi patch)
With beta11 I only can reinject succesfully with -x 500 or less. (used the new madwifi patch from beta11). Any higher, and airodump doesn't pick up any packets, including beacons.

Additionally I get a shitload of dmesg entries in the form of :

Protocol 0300 is buggy, dev ath0
printk: 575 messages suppressed
ath_hardstart: discard, no xmit buf
NETDEV WATCHDOG: ath0: transmit timed out

Is this due to additional logic in the re-injection patch, or due to changes in airodump ?

Dutch

PostPosted: Wed Jul 27, 2005 3:01 pm
by crymsan
Not sure if this is a problem with airodump, but often after a period of time on a single channel (usually 10 - 60 seconds) airodump stops picking up new packets. I've checked many times and power management is turned on for the card.

Other cards I have seem to work fine.

This problem does not occur if I set airodump to hop. The card is a smc eliteconnect (SMC2532W-B) prism2 I believe. I have tried two different versions (patched and unpatched) of hostap drivers, as well as two different firmwares.

Also, I notice that aircrack is starting to hang on me alot when loading the dump file. It stalls at "Reading Packet, wait". I have to use a kill -9 to stop it as a regular interrupt does nothing.

I'm currently using the 11 beta but have had similiar issues with all betas I've tried all past 5.

Anyone have any ideas?

PostPosted: Wed Jul 27, 2005 11:27 pm
by syrou
devine wrote:I also get that segmentation fault when changing the mac address (kernel 2.6.11.7). I'll look into it.


Have also tried with a 2.6.12.3 kernel and it does the same. Maybe the madwifi cvs shapshot (20050525) had some problems, will try to recompile it without patching.

Please keep us informed if you find out the reason (so do I if find it).

Ductch wrote:Works fine here, 2.6.11-4 kernel. Just for kicks, you do remember to have the if down, when changing the MAC address ?
I.E. :
ifconfig ath0 down
ifconfig ath0 hw ether 00:00:0E:AD:BE:EF
ifconfig ath0 up


Yes I'm doing that way.

PD: Have just compiled madwifi cvs 20050525 drivers without patch, and seems nothing to do with the patch, segmentation fault. Maybe trying a later cvs release? But you say they are quite faulty.

PostPosted: Thu Jul 28, 2005 6:50 am
by devine
crymsan wrote:This problem does not occur if I set airodump to hop. The card is a smc eliteconnect (SMC2532W-B) prism2 I believe. I have tried two different versions (patched and unpatched) of hostap drivers, as well as two different firmwares.


Could you run kismet and lock it on a specific channel - does the same behaviour occur ?

crymsan wrote:Also, I notice that aircrack is starting to hang on me alot when loading the dump file. It stalls at "Reading Packet, wait". I have to use a kill -9 to stop it as a regular interrupt does nothing.


That's really wierd. Please run strace -f -o out aircrack ... and send me the out file.

PostPosted: Thu Jul 28, 2005 8:07 am
by crymsan
devine wrote:Could you run kismet and lock it on a specific channel - does the same behaviour occur ?


At the moment the same behaviour occurs in kismet, however yesterday kismet worked fine even when airodump did not.

PostPosted: Thu Jul 28, 2005 8:12 am
by devine
crymsan wrote:At the moment the same behaviour occurs in kismet, however yesterday kismet worked fine even when airodump did not.


Hi. Try running kismet first (not airodump) after restarting the card - this could be a problem with airodump not setting up the card properly.

PostPosted: Thu Jul 28, 2005 9:59 am
by crymsan
Played around with the firmwares some more and found out that 1.5.6 works like a charm (other than wierd problem with kismet, when I lock the channel it locks on the current channel not the one I've selected, also iwconfig wlan0 channel X does not work).

In summary, 1.7.4 and 1.8.4 caused the "stalling" problem, 1.5.6 seems to work great.

Thanks alot Devine, great programs and great help.


crymsan

PostPosted: Thu Jul 28, 2005 12:41 pm
by tafkame
@devine:

upgraded from beta9 to beta11 tonight.
When trying to use the arp-replay attack with aireplay it gives me the message "Your driver (madwifi) isn't properly patched for injection in b/g mode.

I'm using the latest auditor release with an atheros card.
beta9 worked fine with patched madwifi drivers coming with auditor.
beta11 doesn't seem to work with the auditor provided driver.
Tried downloading the respective kernel sources for my auditor release to compile the madwifi drivers of 20050525 like stated in your docu for atheros (madwifi) driver patching.
The compilation gave me errors about missing declarations and stuff.,

So...am I doing anything wrong, do I really need to compile a new driver with auditor to use beta11?

Any help would be appreciated.

Thanks so far. :D

PostPosted: Thu Jul 28, 2005 2:18 pm
by grcore
In beta11, aircrack has a problem reading .cap files. It reads .ivs files fine.

When aircrack goes to read a .cap file, you get:

Opening capfile.cap
Reading packets, wait...

and it just sits there....

g

PostPosted: Fri Jul 29, 2005 1:54 am
by devine
crymsan wrote:In summary, 1.7.4 and 1.8.4 caused the "stalling" problem, 1.5.6 seems to work great.


Cool! I've mentionned this in the docs.

tafkame wrote:it gives me the message "Your driver (madwifi) isn't properly patched for injection in b/g mode.


You should apply the patch provided with beta11 to the madwifi sources and install them. Note that you only need the kernel headers from the kernel. Anyway aireplay should work fine with the old madwifi patch (albeit in B mode only), so you can just use version beta10.

grcore wrote:In beta11, aircrack has a problem reading .cap files. It reads .ivs files fine.


I can't seem to reproduce your problem. Which is your distribution / kernel version / glibc version ?

PostPosted: Fri Jul 29, 2005 2:07 am
by grcore
devine wrote:I can't seem to reproduce your problem. Which is your distribution / kernel version / glibc version ?


kernel 2.6.11-12mdk-1

Name: glibc-devel
Version: 2.3.4-8mdk

BTW: I am running aircrack/airodump simultaneously

g