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.