Closed GoogleCodeExporter closed 8 years ago
Same issue
What steps will reproduce the problem?
1. sudo ./walsh -i mon0
2.
3.
What is the expected output? What do you see instead?
~/bin/reaver-wps-read-only/src$ sudo ./walsh -i mon0
Scanning for supported APs...
[!] Found packet with bad FCS, skipping...
[!] Found packet with bad FCS, skipping...
[!] Found packet with bad FCS, skipping...
[!] Found packet with bad FCS, skipping...
[!] Found packet with bad FCS, skipping...
[!] Found packet with bad FCS, skipping...
[!] Found packet with bad FCS, skipping...
[!] Found packet with bad FCS, skipping...
[!] Found packet with bad FCS, skipping...
[!] Found packet with bad FCS, skipping...
[!] Found packet with bad FCS, skipping...
[!] Found packet with bad FCS, skipping...
...
^C
What version of the product are you using? On what operating system?
At revision 56
Please provide any additional information below.
Machine one:
uname -a
Linux arch 3.1.5-1-ARCH #1 SMP PREEMPT Sat Dec 10 14:43:09 CET 2011 x86_64
Celeron(R) Dual-Core CPU T3100 @ 1.90GHz GenuineIntel GNU/Linux
lspci | grep Wireless
02:00.0 Network controller: Ralink corp. RT3090 Wireless 802.11n 1T/1R PCIe
kernel module: rt2800pci
Machine tow:
uname -a
Linux cell 2.6.38-13-generic #53-Ubuntu SMP Mon Nov 28 19:33:45 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
lsusb | grep Wireless
Bus 001 Device 004: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070
Wireless Adapter
kernel module: rt2800usb
Reaver works on both machines with BSSID 58:6d:8f:73:0f:f6
but walsh can't find APs it just display "[!] Found packet with bad FCS,
skipping..."
Original comment by mich4th3...@googlemail.com
on 4 Jan 2012 at 7:19
Attachments:
Use the --ignore-fcs option:
$ sudo ./walsh -i mon0 --ignore-fcs
Original comment by cheff...@tacnetsol.com
on 4 Jan 2012 at 7:20
oki thanks the "bad FCS" messages are gone =)
It don't displays my Cisco router BSSID 58:6d:8f:73:0f:f6
but I can run "sudo ./reaver -i mon0 -b 58:6d:8f:73:0f:f6 -vv -c 6 --pin mypin"
with success is this normal ?
Original comment by mich4th3...@googlemail.com
on 4 Jan 2012 at 7:46
walsh should display your Cisco router if it is reporting that it supports WPS
in its beacon packets. Although with the bad checksum errors data might be
getting corrupted. Did walsh display any other APs? How long did it run (it
takes a minute to hop through all the channels). You can also lock walsh onto
your AP's channel using the -c option like you did with Reaver.
Original comment by cheff...@tacnetsol.com
on 4 Jan 2012 at 7:55
beacon packet includes "Tag: Vendor Specific: Microsoft: WPS" option
unfortunately my router is the only one with WPS support but I will check this
tomorrow at lunchtime with some other APs.
I run walsh about 5 minutes very close to my router but nothing
sudo ./walsh -i mon0 -C -c 6
Scanning for supported APs...
^C
Original comment by mich4th3...@googlemail.com
on 4 Jan 2012 at 8:25
Attachments:
In my case is perfect with the option -C
Thanks a lot.
Original comment by mikereav...@gmail.com
on 4 Jan 2012 at 10:23
mich, here is my output when running your pcap file through walsh:
$ walsh -f walsh_test.pcap --ignore-fcs
Scanning for supported APs...
58:6D:8F:73:0F:F6 hl3
Original comment by cheff...@tacnetsol.com
on 4 Jan 2012 at 10:57
Livebox 2 and/or iwlagn issue again here.
Walsh 1.3 from Reaver 1.3 r58 doesn't list the Livebox 2 as supported AP.
Beacons say WPS is enabled, as does the admin web interface.
Original comment by b1957...@nwldx.com
on 5 Jan 2012 at 12:35
b1957, can you provide a pcap of the beacons?
Original comment by cheff...@tacnetsol.com
on 5 Jan 2012 at 12:46
Here's one attached.
Also, M1 (or maybe 2/3/4) contain this:
http://img35.imageshack.us/img35/1853/pushbutton.jpg
That first made me think WPS is not accessible through Reaver's method and
requires Push Button, but someone showed me the same screenshot from an AP he
said was vulnerable.
Original comment by b1957...@nwldx.com
on 5 Jan 2012 at 3:47
Attachments:
That data in the M1 message just identifies the WPS methods that can be used to
connect clients to the AP, but that is separate from the registrar
functionality that Reaver targets.
I don't see anything out of the ordinary in the beacon packet, that AP should
(obviously) be displayed by walsh. Have you tried capturing the beacons with
another tool (wireshark, tcpdump, etc) and then running the pcap through walsh?
If that works, then this is likely an issue with Reaver and your wireless
driver.
Original comment by cheff...@tacnetsol.com
on 5 Jan 2012 at 3:56
Another way to check WPS on beacon frames is use airodump-ng and wireshark, in
my case I use:
airodump-ng mon0 -w file (collect beacons on all channels)
Wireshark and open file-01.pcap
And apply these filters:
wlan_mgt.tag.number==5 and wps.wifi_protected_setup_state==0x02
I obtain same results like walsh, but walsh is faster to check
Original comment by fug...@gmail.com
on 5 Jan 2012 at 9:22
when i run "./walsh -f walsh_test.pcap --ignore-fcs" I get no output
I did "./walsh -f walsh_test.pcap | wc -l" to get the number of bad FCS messages
and I recognized that the number of bad FCS messages is equal to the number of
packets in walsh_test.pcap.
I also run walsh in gdb and found this:
Breakpoint 1, next_packet (header=0x7fffffffe850) at 80211.c:38
38 {
(gdb) n
42 while((packet = pcap_next(get_handle(), header)) != NULL)
(gdb) n
44 if(get_validate_fcs())
(gdb) p packet
$6 = (const u_char *) 0x6498c0 ""
(gdb) p/x *packet
$7 = 0x0
(gdb) n
62 }
think there is something wrong with *packet = 0x0
I test this situtation for the first 20 breaks but I think this will repeat for
all 155 packets in walsh_test.pcap
O and I am running walsh as root all the time just in case ^^
Original comment by mich4th3...@googlemail.com
on 5 Jan 2012 at 9:40
@fuguet: The state may not necessarily be 0x02, although this is usually
correct (I love the non-standard behavior of some of these APs...).
@mich: Good that you're running as root, there is a bug that actually requires
that walsh be run as root in order to work, even when reading from a pcap file
(file permissions issue, will be fixed on the next SVN check in). However, this
is my output when running walsh from the latest SVN code against the
walsh_test.pcap file:
$ sudo ./walsh -f walsh_test.pcap --ignore-fcs
Walsh v1.4 beta WiFi Protected Setup Scan Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner
<cheffner@tacnetsol.com>
BSSID Channel WPS Version WPS Locked
ESSID
--------------------------------------------------------------------------------
--------------
58:6D:8F:73:0F:F6 6 1.0 N
hl3
Original comment by cheff...@tacnetsol.com
on 5 Jan 2012 at 5:25
oki thanks for the info
my output is ( also test 4 other APs with WPS enabled always the same ) :
sudo ./walsh -f walsh_test.pcap -C
Walsh v1.4 beta WiFi Protected Setup Scan Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner
<cheffner@tacnetsol.com>
BSSID Channel WPS Version WPS Locked ESSID
--------------------------------------------------------------------------------
--------------
I will test this on weekend and report here if I find something out =)
Original comment by mich4th3...@googlemail.com
on 5 Jan 2012 at 8:55
Thanks 4 all;
I have it more clear, I put that state to see that the tag was as "configured".
then better to use the filter without specifying the type of state.
I will continue to learn and follow your advice :)
Original comment by fug...@gmail.com
on 6 Jan 2012 at 3:22
@mitch: try doing a 'make distclean' to remove everything, then rebuild from
scratch './configure && make'. Then see if you get any output from the
walsh_test.pcap file.
Original comment by cheff...@tacnetsol.com
on 6 Jan 2012 at 4:22
I've reproduced this issue on another machine, and it looks to be a bug with
database permissions. If I do a 'make install' and run walsh as root, I get the
expected output from walsh_test.pcap; else, no output. Work in progress...
Original comment by cheff...@tacnetsol.com
on 6 Jan 2012 at 9:29
Thanks for all ... think I can learn a lot from your source-code
keep the good work up =)
Original comment by mich4th3...@googlemail.com
on 6 Jan 2012 at 10:23
This issue is fixed for me as of r82.
I do have to use -C otherwise I'm spammed with bad FCS, but otherwise the
Livebox 2 appears properly in Walsh's list, with all the right info.
Good job! :)
Original comment by b1957...@nwldx.com
on 9 Jan 2012 at 6:22
Issue 111 has been merged into this issue.
Original comment by cheff...@tacnetsol.com
on 9 Jan 2012 at 8:42
I was able to reproduce no-output bug in walsh. It is now working for me as of
r83.
You MUST do an install in order for walsh to work properly:
$ svn up
$ sudo make distclean
$ ./configure && make
$ sudo make install
Original comment by cheff...@tacnetsol.com
on 9 Jan 2012 at 8:45
oki thx for the fix.
Revision 83 works perfect for me
Original comment by mich4th3...@googlemail.com
on 10 Jan 2012 at 9:10
Original comment by cheff...@tacnetsol.com
on 10 Jan 2012 at 12:38
yo tengo otro problema de esa forma no lo detecta tampoco hver si me lo pueden
aclarar ajunto una copia del primer paso sta ese..
root@bt:~# airmon-ng start wlan0
Found 5 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!
PID Name
1241 dhclient3
1298 dhclient3
12953 wpa_supplicant
12959 dhclient
12977 dhclient
Process with PID 1298 (dhclient3) is running on interface wlan0
Process with PID 12953 (wpa_supplicant) is running on interface wlan0
Process with PID 12977 (dhclient) is running on interface wlan0
Interface Chipset Driver
mon1 Atheros ath5k - [phy0]
mon5 Atheros ath5k - [phy0]
mon0 Atheros ath5k - [phy0]
mon4 Atheros ath5k - [phy0]
wlan0 Atheros ath5k - [phy0]
(monitor mode enabled on mon6)
mon3 Atheros ath5k - [phy0]
mon2 Atheros ath5k - [phy0]
root@bt:~# wash -i mon0 ignore-fcs
Wash v1.4 WiFi Protected Setup Scan Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner
<cheffner@tacnetsol.com>
BSSID Channel RSSI WPS Version WPS Locked
ESSID
--------------------------------------------------------------------------------
-------------------------------
[!] Found packet with bad FCS, skipping...
[!] Found packet with bad FCS, skipping...
Original comment by kenion...@gmail.com
on 1 Mar 2013 at 7:39
use -C instead of ignorefcs your hyphenating wrong
Original comment by omdre...@gmail.com
on 11 Mar 2014 at 2:27
wash -i mon0 --ignore-fcs
This works too
Original comment by davz...@gmail.com
on 31 Jan 2015 at 9:47
Curious to know why wash indicates that WPS isn't locked? I'm guessing that
this means that WPS isn't available.. Just learned about the 'wash' app via
scanning net for something else.
00:26:18:C6:23:52 1 -77 1.0 No
SSID1
2C:39:96:FD:32:D4 1 -79 1.0 No
SSID2
40:F2:01:F2:28:37 1 -79 1.0 No
SSID3
2C:39:96:3E:62:2A 1 -82 1.0 No
SSID4
0C:47:3D:E9:62:68 4 -89 1.0 No
SSID5
0C:47:3D:C3:03:38 4 -91 1.0 No
SSID6
68:B6:FC:C6:E8:B8 6 -80 1.0 No
SSID7
2C:E4:12:8E:10:C5 6 -89 1.0 No
SSID8
34:8A:AE:FB:EA:AE 11 -90 1.0 No
SSID9
Original comment by afssolut...@gmail.com
on 8 Feb 2015 at 9:22
Original issue reported on code.google.com by
mikereav...@gmail.com
on 4 Jan 2012 at 7:12Attachments: