New tool to crack WEP keys under GNU/Linux - Page 5

Dreadnaught · 06-23-2004

I'm running a peer to peer network with one computer running windows, so I had to input the key twice, and am sure it's the one in my post. The windows computer is using centrino and the other is using a Senao 2511 with a Dell TrueMobile doing the capturing. My wireless cards are fairly new so I would think they are filtering weak packet; however, kismet did show 21 weak packets in the final totals. Also, it did work without any problem using a 64 bit key.

I'm redoing it now, using your method of capturing, so I'll see how small I can make the file. I'm afraid I don't have any way of uploading to the web.

06-24-2004

Dear topolb,

I think i need prismheaders, cause without it -a option
shows twice less valid packets, and debugkey is not confirmed.

Due to problems with wlan-ng drivers on my laptop ( sometimes
they works, sometimes not) i have captured now under Windows
with Airopeek and Realtek 8180 based card ( who is wondereng -
the most dammed under linux card can capture under windows).
Converted the capture with Etherreal and ported it to linux.
I'am somehow shure that Realtek does not have prismheades.

Debugkey was confirmed - key correcta + some in spanish.

Now i run bruteforce attack with weplab "niced" to -20
The speed is about 46000 c/s. The 500 Mhz machine is on xx:xx:xx:82:00 after 14 hours. That means - the whole process
will take a years.

Where I am wrong ?

topolb · 06-24-2004

bubaka: about the prismheader send me some small log file by email and I will check it to see if you need prismheader or not.
If you need prismheader and you are using weplab-0.0.5 or superior you should not get any seg fault or error. What weplab version are you using

About the time required for bruteforcing a 128-bit key, it is normal. If you read README file you will find a little calculus of the amount of year required.

Perhaps you should better try an FMS if you have captured more than 1.5M packets.

PD: weplab 0.0.6 is out

<edit>
PD2: I forgot to translate "Key correcta encontrada". In english it will be "Right key found"

I haven't realized until now
</edit>

r00t3hell · 06-24-2004

hi,
first of all @topolb:
thanks a lot for your work...
i though have a few questions:
i captured about 90(!!) MB traffic off my Wlan using ethereal - according to you, that should by far
enough to do a successful attack using FMS...
i tried the following:

Code:

./weplab --debug 1 --prismheader -r /root/capture/capture_1.pcap --debugkey 13:1f:02:34:8a: /root/capture/capture_1.pcap
...

Total valid packets read: 115306
Total packets read: 131438
Total unique IV read: 55693
 55693 Weak packets gathered:

...
Key parece que verifica paquete. Probando con el resto....
Key: 13:1f:02:34:8a
Key correcta!

so this seems to work...

one question:
do i really have 55693 weak packages here?
because the following fails to break my key:

Code:

./weplab --debug 1 --prismheader -r /root/capture/capture_1.pcap --debugkey 13:1f: /root/capture/capture_1.pcap
----
Opening packet file for loading all the IV

Total valid packets read: 115306
Total packets read: 131438
Total unique IV read: 55693
 55693 Weak packets gathered:
Compressing IV table...
Total number of Weak packets for byte 0 is 0 (byte 1) and 0 (byte 2)
00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0),  --> breath 10 (40% requested)

Total number of Weak packets for byte 1 is 0 (byte 1) and 0 (byte 2)
00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0),  --> breath 10 (40% requested)

Total number of Weak packets for byte 2 is 218 (byte 1) and 0 (byte 2)
09(76), 75(6), 02(2), 83(2), a2(2), ab(2), b6(2), b8(2), c4(2), 04(0),  --> breath 1 (40% requested)

Key NOT found

one question:
why fails weplab to find the key here?
of course, completely without --debugkey it fails also...

weplab says, it found 55693 Weak packets...
if a pcap - dumpfile gives me _weak_packages_ in weplab - is it possible to break the key with FMS in principle?
so do i simply have to capture more traffic here in my case?
(as i already said - this is a ~90MB capture file - you said, that 3MB should be fine to launch a FMS attack...)
finally one general question:
is the key-length of a wepped packet predictable?
i guess not, am i right?

thanks again for your work - this program is great...

regards
flo

kleptophobiac · 06-24-2004

Try punching up to 70% from 40%

topolb · 06-24-2004

Hi r00t3hell

First of all. When I said 1.5M packets to break the key, I mean 1.5 Million packets, not 1.5 Megabytes

So it does not matter how many megabytes have you captured. The important issue is HOW MANY WEP ENCRYPTED DATA packets have you captured.

You only have 55.000 packets. With this amount it is impossible to use FMS. You have to either capture more packets (at least 1M), or use bruteforce (2 month processing time for 64-bit key, or many years for 128-bit).

If weplab were able to crack the key quickly with 1.5 Megabytes of captured traffic I think that Matrix would already had me x)

r00t3hell · 06-26-2004

hi,
@topolb:
thanks a lot for your answer...

i just misunderstood...
thank you

regards

sylvain · 06-29-2004

Here is what I got :

Paquets captured with :
./weplab --debug 1 -c -i wifi0 ./test.log

Then I try to identify if the card is compliant with your tool so I did the following commands :
./weplab -r ./test.log -- debugkey MYKEY -- debug 1 --key 128 ./test.log
and
./weplab -r ./test.log -- debugkey MYKEY -- debug 1 --key 128 --fcs ./test.log

Both commands gives me a WEP key not cracked. However it identifies weak IV
Total valid packets read: 74
Total packets read: 1346
10 packets selected.
Packet 0
---------------------------------------------
Frame Ctl: 0x4108
Key: ab:02:b0
Len including headers: 86
Len EXcluding headers (24 802.11, 4 IV+ID): 58
---------------------------------------------

Packet 1
---------------------------------------------
Frame Ctl: 0x4108
Key: 09:01:05
Len including headers: 86
Len EXcluding headers (24 802.11, 4 IV+ID): 58
---------------------------------------------

Packet 2
---------------------------------------------
Frame Ctl: 0x4108
Key: 5b:03:51
Len including headers: 86
Len EXcluding headers (24 802.11, 4 IV+ID): 58
---------------------------------------------

Packet 3
---------------------------------------------
Frame Ctl: 0x4108
Key: a5:00:c6
Len including headers: 86
Len EXcluding headers (24 802.11, 4 IV+ID): 58
---------------------------------------------

Packet 4
---------------------------------------------
Frame Ctl: 0x4208
Key: 2b:15:00
Len including headers: 86
Len EXcluding headers (24 802.11, 4 IV+ID): 58
---------------------------------------------

Packet 5
---------------------------------------------
Frame Ctl: 0x4108
Key: 96:03:c9
Len including headers: 86
Len EXcluding headers (24 802.11, 4 IV+ID): 58
---------------------------------------------

Packet 6
---------------------------------------------
Frame Ctl: 0x4108
Key: 14:01:4e
Len including headers: 86
Len EXcluding headers (24 802.11, 4 IV+ID): 58
---------------------------------------------

Packet 7
---------------------------------------------
Frame Ctl: 0x4108
Key: b5:03:ed
Len including headers: 86
Len EXcluding headers (24 802.11, 4 IV+ID): 58
---------------------------------------------

Packet 8
---------------------------------------------
Frame Ctl: 0x4208
Key: 9a:14:00
Len including headers: 86
Len EXcluding headers (24 802.11, 4 IV+ID): 58
---------------------------------------------

Packet 9
---------------------------------------------
Frame Ctl: 0x4108
Key: ef:03:f1
Len including headers: 99
Len EXcluding headers (24 802.11, 4 IV+ID): 71
---------------------------------------------

Opening packet file for loading all the IV

Total valid packets read: 1346
Total packets read: 1346
Total unique IV read: 1346
1346 Weak packets gathered:
Compressing IV table...
Total number of Weak packets for byte 0 is 0 (byte 1) and 0 (byte 2)
00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 1 is 0 (byte 1) and 0 (byte 2)
00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 2 is 3 (byte 1) and 0 (byte 2)
26(0), 29(0), 4a(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 3 is 0 (byte 1) and 0 (byte 2)
00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 4 is 1 (byte 1) and 0 (byte 2)
1c(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 5 is 0 (byte 1) and 0 (byte 2)
00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 6 is 0 (byte 1) and 0 (byte 2)
00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 7 is 1 (byte 1) and 0 (byte 2)
9e(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 8 is 0 (byte 1) and 0 (byte 2)
00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 9 is 0 (byte 1) and 0 (byte 2)
00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 10 is 0 (byte 1) and 0 (byte 2)
00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 11 is 0 (byte 1) and 0 (byte 2)
00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 12 is 0 (byte 1) and 0 (byte 2)
00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 13 is 1 (byte 1) and 0 (byte 2)
8a(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested)

Key NOT found

so maybe the file I used is too small but I think it is sufficient as I use the --debugkey command...

topolb · 06-29-2004

I have just read (and answered) your private message before reading this.

I will wait for your logfile by email.
Results will be posted here for information.

Don't forget to send me also your real key.

muts · 06-30-2004

After trying to break my own 64bit wep key, i noticed that the key was found, however, not displayed.

Apparently this will be fixed in 0.0.7.

In the meantime, here's a quick fix:

In - bruteforce.c, around line 174 add the ViewKey Function (shown in red)

Code:

if (VerifyPacketWithKey(packets[0],key.key)){
                               printf("Key parece que verifica paquete. Proban$
                                if (Verify10PacketsWithKey(packets, key.key)>2){
                                        printf("Key correcta!\n");
                                       ViewKey (key.key,global_v.key_len);
                                }
                        }

Many thanks to Alon (loni) for providing this quick fix!

sylvain · 06-30-2004

I can confirm now that the tool works with Cisco Aironet Card and wifix drivers included in kernel 2.4.20+

chesh · 07-02-2004

Is the Kismet*.dump files in pcap format? I've tried loading these a couple of times with weplab for a bruteforce and I always get to the point where it says: Launching process ... (0) and it goes <defunct>. I press enter and I'm back at a command line. I dunno if I'm doing something wrong here, and I'd like to post the exact output, but I'm at work right now hoping that someone else has seen this problem. Also, when is the dictionary attack mode supposed to be completed? Thanx

07-02-2004

Yes, kismet files are in pcap format, you can load it in Ethereal, replay in Airsnort etc.
But somehow weplab start working on on kismet files and crashes if i want some stats also, even if "garbage" is filtered out (by replayig the files and filtering only one, needed BSSID. )
Whant to hear the opinion of topolb here.

sylvain · 07-02-2004

hum I don't have any problem with kismet files...maybe it is due to the fact you didn't use the fcs or prismheader option ...what is your wireless card ?

07-02-2004

Card is Atheros - MadWifi drivers. Problem is only with "giga" size files, weplab
loads it ( very quickly - 30 seconds for 2G file, Ethereal needs 3-4 mins), selects 10 packets, prints first analyse message , starts working and crashes
if i press enter to get statisticks. But it accepts captures made with Airopeek
under windows ( and converted with Ethereal) w/o any problems. As i understand kismet put in dump all needed and unneeded info, so in any
case i filter only "wanted" BSSID it before feeding weplab.
May be i need to strip LCC data out of the dump also? Weplab in "-a" mode
says that i should not use "PRISMHEADER" and - fcs is tryed also.

06-24-2004	#62 (permalink)
bubaka Posts: n/a	to topob Dear topolb, I think i need prismheaders, cause without it -a option shows twice less valid packets, and debugkey is not confirmed. Due to problems with wlan-ng drivers on my laptop ( sometimes they works, sometimes not) i have captured now under Windows with Airopeek and Realtek 8180 based card ( who is wondereng - the most dammed under linux card can capture under windows). Converted the capture with Etherreal and ported it to linux. I'am somehow shure that Realtek does not have prismheades. Debugkey was confirmed - key correcta + some in spanish. Now i run bruteforce attack with weplab "niced" to -20 The speed is about 46000 c/s. The 500 Mhz machine is on xx:xx:xx:82:00 after 14 hours. That means - the whole process will take a years. Where I am wrong ?

06-29-2004	#68 (permalink)
sylvain Wireless Auditor Join Date: Jun 2004 Location: Paris, France Posts: 175	With Cisco Aironet 350 Here is what I got : Paquets captured with : ./weplab --debug 1 -c -i wifi0 ./test.log Then I try to identify if the card is compliant with your tool so I did the following commands : ./weplab -r ./test.log -- debugkey MYKEY -- debug 1 --key 128 ./test.log and ./weplab -r ./test.log -- debugkey MYKEY -- debug 1 --key 128 --fcs ./test.log Both commands gives me a WEP key not cracked. However it identifies weak IV Total valid packets read: 74 Total packets read: 1346 10 packets selected. Packet 0 --------------------------------------------- Frame Ctl: 0x4108 Key: ab:02:b0 Len including headers: 86 Len EXcluding headers (24 802.11, 4 IV+ID): 58 --------------------------------------------- Packet 1 --------------------------------------------- Frame Ctl: 0x4108 Key: 09:01:05 Len including headers: 86 Len EXcluding headers (24 802.11, 4 IV+ID): 58 --------------------------------------------- Packet 2 --------------------------------------------- Frame Ctl: 0x4108 Key: 5b:03:51 Len including headers: 86 Len EXcluding headers (24 802.11, 4 IV+ID): 58 --------------------------------------------- Packet 3 --------------------------------------------- Frame Ctl: 0x4108 Key: a5:00:c6 Len including headers: 86 Len EXcluding headers (24 802.11, 4 IV+ID): 58 --------------------------------------------- Packet 4 --------------------------------------------- Frame Ctl: 0x4208 Key: 2b:15:00 Len including headers: 86 Len EXcluding headers (24 802.11, 4 IV+ID): 58 --------------------------------------------- Packet 5 --------------------------------------------- Frame Ctl: 0x4108 Key: 96:03:c9 Len including headers: 86 Len EXcluding headers (24 802.11, 4 IV+ID): 58 --------------------------------------------- Packet 6 --------------------------------------------- Frame Ctl: 0x4108 Key: 14:01:4e Len including headers: 86 Len EXcluding headers (24 802.11, 4 IV+ID): 58 --------------------------------------------- Packet 7 --------------------------------------------- Frame Ctl: 0x4108 Key: b5:03:ed Len including headers: 86 Len EXcluding headers (24 802.11, 4 IV+ID): 58 --------------------------------------------- Packet 8 --------------------------------------------- Frame Ctl: 0x4208 Key: 9a:14:00 Len including headers: 86 Len EXcluding headers (24 802.11, 4 IV+ID): 58 --------------------------------------------- Packet 9 --------------------------------------------- Frame Ctl: 0x4108 Key: ef:03:f1 Len including headers: 99 Len EXcluding headers (24 802.11, 4 IV+ID): 71 --------------------------------------------- Opening packet file for loading all the IV Total valid packets read: 1346 Total packets read: 1346 Total unique IV read: 1346 1346 Weak packets gathered: Compressing IV table... Total number of Weak packets for byte 0 is 0 (byte 1) and 0 (byte 2) 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 1 is 0 (byte 1) and 0 (byte 2) 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 2 is 3 (byte 1) and 0 (byte 2) 26(0), 29(0), 4a(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 3 is 0 (byte 1) and 0 (byte 2) 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 4 is 1 (byte 1) and 0 (byte 2) 1c(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 5 is 0 (byte 1) and 0 (byte 2) 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 6 is 0 (byte 1) and 0 (byte 2) 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 7 is 1 (byte 1) and 0 (byte 2) 9e(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 8 is 0 (byte 1) and 0 (byte 2) 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 9 is 0 (byte 1) and 0 (byte 2) 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 10 is 0 (byte 1) and 0 (byte 2) 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 11 is 0 (byte 1) and 0 (byte 2) 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 12 is 0 (byte 1) and 0 (byte 2) 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Total number of Weak packets for byte 13 is 1 (byte 1) and 0 (byte 2) 8a(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), 00(0), --> breath 10 (40% requested) Key NOT found so maybe the file I used is too small but I think it is sufficient as I use the --debugkey command...

06-30-2004	#70 (permalink)
muts Registered Member Join Date: Jun 2004 Posts: 3	Weplab Bruteforce - Key not shown when found After trying to break my own 64bit wep key, i noticed that the key was found, however, not displayed. Apparently this will be fixed in 0.0.7. In the meantime, here's a quick fix: In - bruteforce.c, around line 174 add the ViewKey Function (shown in red) Code: if (VerifyPacketWithKey(packets[0],key.key)){ printf("Key parece que verifica paquete. Proban$ if (Verify10PacketsWithKey(packets, key.key)>2){ printf("Key correcta!\n"); ViewKey (key.key,global_v.key_len); } } Many thanks to Alon (loni) for providing this quick fix!

07-02-2004	#72 (permalink)
chesh Registered Member Join Date: Feb 2004 Posts: 10	Pcap Logfiles Is the Kismet*.dump files in pcap format? I've tried loading these a couple of times with weplab for a bruteforce and I always get to the point where it says: Launching process ... (0) and it goes <defunct>. I press enter and I'm back at a command line. I dunno if I'm doing something wrong here, and I'd like to post the exact output, but I'm at work right now hoping that someone else has seen this problem. Also, when is the dictionary attack mode supposed to be completed? Thanx

07-02-2004	#73 (permalink)
bubaka Posts: n/a	Weplab & Kismet Yes, kismet files are in pcap format, you can load it in Ethereal, replay in Airsnort etc. But somehow weplab start working on on kismet files and crashes if i want some stats also, even if "garbage" is filtered out (by replayig the files and filtering only one, needed BSSID. ) Whant to hear the opinion of topolb here.

06-23-2004	#61 (permalink)
Dreadnaught Registered Member Join Date: Sep 2003 Posts: 23	I'm running a peer to peer network with one computer running windows, so I had to input the key twice, and am sure it's the one in my post. The windows computer is using centrino and the other is using a Senao 2511 with a Dell TrueMobile doing the capturing. My wireless cards are fairly new so I would think they are filtering weak packet; however, kismet did show 21 weak packets in the final totals. Also, it did work without any problem using a 64 bit key. I'm redoing it now, using your method of capturing, so I'll see how small I can make the file. I'm afraid I don't have any way of uploading to the web.

06-24-2004	#63 (permalink)
topolb Registered Member Join Date: Jun 2004 Posts: 67	bubaka: about the prismheader send me some small log file by email and I will check it to see if you need prismheader or not. If you need prismheader and you are using weplab-0.0.5 or superior you should not get any seg fault or error. What weplab version are you using About the time required for bruteforcing a 128-bit key, it is normal. If you read README file you will find a little calculus of the amount of year required. Perhaps you should better try an FMS if you have captured more than 1.5M packets. PD: weplab 0.0.6 is out <edit> PD2: I forgot to translate "Key correcta encontrada". In english it will be "Right key found" I haven't realized until now </edit>

06-24-2004	#65 (permalink)
kleptophobiac Registered Member Join Date: Sep 2002 Posts: 310	Try punching up to 70% from 40%

06-24-2004	#66 (permalink)
topolb Registered Member Join Date: Jun 2004 Posts: 67	Hi r00t3hell First of all. When I said 1.5M packets to break the key, I mean 1.5 Million packets, not 1.5 Megabytes So it does not matter how many megabytes have you captured. The important issue is HOW MANY WEP ENCRYPTED DATA packets have you captured. You only have 55.000 packets. With this amount it is impossible to use FMS. You have to either capture more packets (at least 1M), or use bruteforce (2 month processing time for 64-bit key, or many years for 128-bit). If weplab were able to crack the key quickly with 1.5 Megabytes of captured traffic I think that Matrix would already had me x)

06-26-2004	#67 (permalink)
r00t3hell Registered Member Join Date: Jun 2004 Posts: 2	hi, @topolb: thanks a lot for your answer... i just misunderstood... thank you regards

06-29-2004	#69 (permalink)
topolb Registered Member Join Date: Jun 2004 Posts: 67	I have just read (and answered) your private message before reading this. I will wait for your logfile by email. Results will be posted here for information. Don't forget to send me also your real key.

06-30-2004	#71 (permalink)
sylvain Wireless Auditor Join Date: Jun 2004 Location: Paris, France Posts: 175	I can confirm now that the tool works with Cisco Aironet Card and wifix drivers included in kernel 2.4.20+

07-02-2004	#74 (permalink)
sylvain Wireless Auditor Join Date: Jun 2004 Location: Paris, France Posts: 175	hum I don't have any problem with kismet files...maybe it is due to the fact you didn't use the fcs or prismheader option ...what is your wireless card ?

07-02-2004	#75 (permalink)
bubaka Posts: n/a	to sylvain Card is Atheros - MadWifi drivers. Problem is only with "giga" size files, weplab loads it ( very quickly - 30 seconds for 2G file, Ethereal needs 3-4 mins), selects 10 packets, prints first analyse message , starts working and crashes if i press enter to get statisticks. But it accepts captures made with Airopeek under windows ( and converted with Ethereal) w/o any problems. As i understand kismet put in dump all needed and unneeded info, so in any case i filter only "wanted" BSSID it before feeding weplab. May be i need to strip LCC data out of the dump also? Weplab in "-a" mode says that i should not use "PRISMHEADER" and - fcs is tryed also.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode