Closed GoogleCodeExporter closed 9 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
Original issue reported on code.google.com by
mikereav...@gmail.com
on 4 Jan 2012 at 7:12Attachments: