Description of problem: The 'wash' utility from the reaver suite - 'wash -i <monitoring_interface>' - shows no output and exits if the current version of libpcap (1.5.3-1.fc20) is installed. Version-Release number of selected component (if applicable): libpcap-1.5.3-1.fc20 How reproducible: Always Steps to Reproduce: 1. Run 'wash -i <monitoring_interface>' with libpcap-1.5.3-1.fc20 installed 2. 3. Actual results: 'wash' shows no output and exits immediately after execution, but should show vulnerable WPS routers. Expected results: 'wash' should show vulnerable WPS routers and continue execution until killed. Additional info: Adding the directory for the file reaver.db 'mkdir [/usr/local]/etc/reaver', as suggested in some posts, has no effect. Downgrading libpcap to 1.4.0-2 brings the desired outcome. I noticed that running 'lsof | grep wash' with wash functioning shows [...] wash xxxx root 4u pack xxxxxx 0t0 ALL type=SOCK_RAW while with a dysfunctional wash it shows something like [...] wash xxxx root 4u sock xxxxxx 0t0 ALL protocol: PACKET
Is there actually any response to that? If it is not a bug, please tell me.
This issue most likely related to the changes due to libpcap's adoption of TPACKETv3 memory mapped capture on Linux. I fill be rebasing to 1.6.2 in F21 and rawhide I will also rebuild version for F20. I will disable TPACKETv3 across the board.
libpcap-1.6.2-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/libpcap-1.6.2-1.fc21
libpcap-1.5.3-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libpcap-1.5.3-2.fc20
Created attachment 948556 [details] Strace output of 'wash -i mon0' after upgrading to the new libpcap for FC20 Still no output
Package libpcap-1.6.2-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libpcap-1.6.2-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-13320/libpcap-1.6.2-1.fc21 then log in and leave karma (feedback).
I tried 'yum update --enablerepo=updates-testing libpcap-1.6.2-1.fc21' in the last few days, but it says there is no such package. 'yum update' only lets me upgrade to 1.5.3.
Doing yum update works for me just fine. Please give it one more shot. Anyway, thanks for the strace output. I can see there, setsockopt(5, SOL_PACKET, PACKET_RX_RING, {block_size=0, block_nr=0, frame_size=0, frame_nr=0}, 16) = -1 EINVAL (Invalid argument) I've had a brief look at kernel source and actually block_size=0 is of course not allowed, hence -EINVAL return value. Question is why block_size==0 in your case, this is very weird given that in libpcap-1.5.2 we have following code req.tp_block_size = getpagesize(); To debug this further I'd like to run wash on my machine but it seems it is not packaged in Fedora. Can you provide *step-by-step* instructions how to setup the environment for running wash. Thanks.
libpcap-1.6.2-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
dear Michal, sorry for the delay. I could not install libpcap-1.6.2 from the named repository you gave on 2014-10-20, I guess that the URL was the wrong one since I am on FC20, not FC 21 (yum said: 'not available' all the time, it only offered the version 1.5.3 which does not work). Nevertheless, I succeeded in installing libpcap-1.6.2 - found it online - and the issue is, as far as I can tell, gone (wash works now, it could find a WPS-vulnerable network). So for me, it is fixed, though I will test a bit more today. Best regards and thank you for dealing with my issue, Patrick
Can you provide exact version of libpcap-1.5.3? If there is no other bug causing wash not to work then it should be fixed with libpcap-1.5.3-2.fc20. Please test with that version and let me know. Thanks.
Yes, its working with 1.5.3-2. But it is not in the repository yet, had to download it from rpmfind.
Hmm that is strange, according to bodhi it should have been in updates-testing for some time now. Anyway, here is a link for koji build. Also, I pushed the update to stable now. http://koji.fedoraproject.org/koji/buildinfo?buildID=581521
libpcap-1.5.3-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Michal Sekletar from comment #2) > This issue most likely related to the changes due to libpcap's adoption of > TPACKETv3 memory mapped capture on Linux. I fill be rebasing to 1.6.2 in F21 > and rawhide I will also rebuild version for F20. I will disable TPACKETv3 > across the board. Note that libpcap issues 380 and 364 are both due to a *kernel* bug, wherein TPACKET_V3 was delivering wakeups whenever a packet was added to a buffer (not all that useful, as you're not supposed to process that buffer in userland until it's closed) and *not* delivering wakeups when a buffer is closed (very bad, as it means that you won't see that the buffer is closed until another packet arrives, adding an arbitrary random non-useful delay, and can allow an arbitrary number of empty closed buffers to pile up unprocessed, potentially causing packet drops). The fix for this, from Dan Collins, was checked in: http://www.spinics.net/lists/netdev/msg309630.html and is in the 3.19 kernel.
We were discussing the possibility to reenable TPACKET_V3 in Fedora and we will do that for Fedora 27. Also these fixes were recently backported to RHEL/CentOS kernel. We could potentially reenable TPACKET_V3 there as well. But for now we will stay with TPACKET_V2 in RHEL/CentOS.