Open GoogleCodeExporter opened 8 years ago
That sounds like a bug.
Have you tried cracking the access point using aircrack-ng and the command-line?
Follow this tutorial:
http://www.aircrack-ng.org/doku.php?id=simple_wep_crack#step_1_-_start_the_wirel
ess_interface_in_monitor_mode_on_ap_channel
If the tutorial works for you, then it's definitely a bug with Wifite.
If the tutorial does not work, your wireless cards may not be capable of
monitor mode or injection.
Please let me know whether or not you are successful.
Original comment by der...@gmail.com
on 26 Apr 2012 at 5:48
i swapped out the wireless card to an Atheros internal and it seems to work,
seems this was happening with Broadcomm b/g/n wireless card using brscmac
drivers.
So not a bug in wifite i think
Original comment by cn.robe...@me.com
on 29 Apr 2012 at 10:57
[deleted comment]
[deleted comment]
same issue here
tested on two different compters
one of them has cracked WEP pwds before
[0:10:00] preparing attack "xxxx" (xxxx)
[0:10:00] attempting fake authentication (5/5)... failed
[0:10:00] attacking "xxxx" via arp-replay attack
[0:09:54] attack failed: aireplay-ng exited unexpectedly
[0:10:00] attempting fake authentication (5/5)... failed
[0:10:00] attacking "xxxx" via chop-chop attack
[0:09:54] attack failed: unable to generate keystream
[0:10:00] attempting fake authentication (5/5)... failed
[0:10:00] attacking "xxxx" via fragmentation attack
[0:09:54] attack failed: unable to generate keystream
[0:10:00] attempting fake authentication (5/5)... failed
[0:10:00] attacking "xxxx" via caffe-latte attack
[0:09:54] attack failed: aireplay-ng exited unexpectedly
[0:10:00] attempting fake authentication (5/5)... failed
[0:10:00] attacking "xxxx" via p0841 attack
[0:10:00] attempting fake authentication (5/5)... failed
[0:00:00] unable to carry out hirte attack: no clients
[0:00:00] attack complete: failure
Original comment by plokij...@gmail.com
on 27 Oct 2012 at 5:49
I have the same problem with an atheros card when i try to crack WEP.
I tested my wirecard with aireplay-ng -9 mon0 and it seems to work ok.
Any suggestions???
Original comment by madski...@gmail.com
on 7 Nov 2012 at 12:11
[deleted comment]
i reinstalled to bACKTRACK 5 R3 and im getting this issue back again
Original comment by cn.robe...@me.com
on 12 Nov 2012 at 9:12
Having the same issue here. Machine is a Asus EeePC 900 running Backbox 2.5,
seems to work when using the internal Atheros wireless chipset, won't work when
using the connected ALFA AWUS036H Wireless USB Adapter, though it has been
reported as one of the most compatible USB adapters for linux. Used to work in
the past, but now i am getting this "attack failed: aireplay-ng exited
unexpectedly" error every time.
Original comment by a.ghi...@gmail.com
on 28 Nov 2012 at 7:56
mencoba otentikasi palsu (5/5) ... gagal
saya tidak terlalu paham dengan ke gagalan ini
tolong kasih saya saran???
Original comment by andysa...@gmail.com
on 24 Mar 2013 at 10:36
aireplay-ng exited unexpectedly
Original comment by solloman...@gmail.com
on 26 Mar 2013 at 4:16
same here
Original comment by watge...@gmail.com
on 16 Apr 2013 at 5:55
This may be due to not having the channel set properly. By patching in a call
to iwconfig just before the call to airodump-ng, this problem was eliminated in
our setup.
Add the following lines right before " # Start airodump process to capture
packets"
#HACK set channel with iwconfig
print G+' setting channel'
cmd_iwconfig = ['iwconfig',
iface,
'channel', target.channel]
proc_iwconfig = Popen(cmd_iwconfig, stdout=DN, stderr=DN)
Also, you can retrieve a wep key much faster with aircrack-ptw. Maybe a patch
for that in the future...
Original comment by ad...@openschemes.com
on 21 Apr 2013 at 1:57
Apologies, our last post only works for some simple cases. Please ignore it.
The problem seems to be in channel set, but some stubborn interfaces only set
properly after they are first brought up in monitor mode. After a few
operations, iwconfig will die due to interface busy.
The real fix is to bring down ALL monitors with airmon-ng (even the base
interface), then bring up a monitor and immediately set it's channel to the
target. This code gets pasted in the same place: Right before # Start airodump
process. It seems to work for stubborn interfaces as well.
#HACK set channel with iwconfig. Need to stop/start for clean channel set. Dunno why
print G+' Shutting down all interfaces and bringing up clean with channel set'
proc = Popen(['airmon-ng'], stdout=PIPE, stderr=DN)
for line in proc.communicate()[0].split('\n'):
if len(line) == 0 or line.startswith('Interface'): continue
print W+' Stopping ' + line.split('\t')[0] #Just for debug
call(['airmon-ng', 'stop', line.split('\t')[0]], stdout=DN, stderr=DN)
print G+' Stopped...'
#Now restart monitor mode and set channel FIRST before doing anything else
iface=get_iface()
call(['iwconfig', iface, 'channel', target.channel])
print 'done'
Original comment by ad...@openschemes.com
on 21 Apr 2013 at 4:58
Found there's an even easier solution that takes no hacking to the script.
Simply use airmon-ng (or ifconfig/iwconfig) to put down and bring up the
interface before running the script. Then, the script runs properly without
having to bring down the interfaces midway through.
This was added to /etc/init.d/done on an openwrt box to take care of the
interface upon bootup.
/usr/sbin/airmon-ng stop wlan0
/usr/sbin/airmon-ng start wlan0
Then, once the openwrt box is done booting a user can SSH in over wifi and use
wifite to analyze their network (on the same wifi hardware) without ever being
disconnected. Much nicer than being booted off SSH halfway through!
Original comment by ad...@openschemes.com
on 23 Apr 2013 at 1:02
Same issue - wifite has worked great for well over a year, even after making
the move to Kali from BT5.
All of a sudden it will no longer associate with WEP access points. I get the
same failure notices as those posting before me.
What I've tried
Various laptops with various wifi devices known to have worked in the past
Un-installed / re-installed wifite
Adding and removing possible hardware conflicts (removed second wifi card for
example)
Deleted OS, re-downloaded and installed. (did not resolve outlined issue)
Created live Kali USB and tried it on various hardware pieces with the same
results.
I also tried the suggestions here with no luck (example: forced mon0 to
matching channel)
Thoughts?
Original comment by brock1...@gmail.com
on 17 Nov 2013 at 7:23
Same here, i;'m using TP link TL-WN722N on Nexus 7 with kali pwnpad installed.
Original comment by gatkowsk...@gmail.com
on 17 Nov 2013 at 8:04
I had the same issue and found the solution in this link
https://code.google.com/p/wifite/issues/detail?id=127 I hope it helps everyone.
Original comment by andrad...@gmail.com
on 23 Apr 2014 at 3:40
As far as I can tell, the cause of this is the reckless technique currently
used to identify the MAC address of the interface in use. Currently wifite is
scraping ifconfig. I am currently using net-tools 2.10. Instead of scraping the
MAC it is scraping the MTU, and unsurprisingly aireplay dislikes this.
Stack Overflow has plenty of superior, reliable methods for reliably getting an
interface's MAC address:
https://stackoverflow.com/questions/159137/getting-mac-address
I suggest someone implements one of these.
Original comment by innocenc...@googlemail.com
on 26 May 2014 at 6:18
[deleted comment]
The attached patch should get it working.
Original comment by innocenc...@googlemail.com
on 29 May 2014 at 3:42
Attachments:
L.ait.tahala@gmail.com
hey brother
when u have this problem be seriously that you need own client in the wifi that
you want to crack
it's very important
Original comment by L.ait.ta...@gmail.com
on 12 Oct 2014 at 3:46
I still encounter this issue, even after adding the ignore -1 lines and after
no success adding the channel set script in this thread.
Aircrack works fine standalone. My setup is capable of injection. Ubuntu
14/Alfa NHA.
Is there any help lurking around out there?
Original comment by highp...@gmail.com
on 28 Oct 2014 at 2:22
In case anyone else comes across the same issue, the answer is embarrasingly
simple.
'stop network-manager' prior to running wifite.
Original comment by highp...@gmail.com
on 30 Oct 2014 at 1:23
[deleted comment]
[deleted comment]
Same problem here.
Original comment by dlanileonardo
on 7 Jan 2015 at 6:25
[deleted comment]
I think #19 innocenc...@googlemail.com nailed the problem. There is someone
that is working on the project that could use his patch?
Original comment by piercost...@gmail.com
on 8 Jan 2015 at 9:57
Original issue reported on code.google.com by
cn.robe...@me.com
on 8 Apr 2012 at 8:27