RTL8812AU [X] ERROR: pcap_activate status -1 #265

gantarone · 2018-11-21T11:32:45Z

Raver Error "RTL8812AU [X] ERROR: pcap_activate status -1" from ver. 1.6.4 to 1.6.5
(only ver form 1.4 to 1.6.3 work)

err:
Reaver v1.6.5 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner cheffner@tacnetsol.com

[X] ERROR: pcap_activate status -1
[X] PCAP: generic error code
couldn't get pcap handle, exiting

my wifi device :
Bus 004 Device 010: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter

rofl0r · 2018-11-21T15:22:11Z

what driver do you use for the 8812 ? what distro ? does it work when you put the card into monitor mode before starting reaver ?

gantarone · 2018-11-21T16:10:12Z

Driver:
version: v5.3.4_28226.20180614_COEX20171103-6c6d
Distro:
Linux kk 4.18.0-kali2-amd64 #1 SMP Debian 4.18.10-2kali1 (2018-10-09) x86_64 GNU/Linux

card in monitor mode work well (Ex. airodump-ng)!!!but when i use reaver ver >= 1.6.4 I get :
[X] ERROR: pcap_activate status -1

rofl0r · 2018-11-21T20:59:50Z

try this #202 (comment)

kcdtv · 2018-11-22T14:51:04Z

Hi there!
I am back from hell! 😺
Before going to hell I noticed this issue too.
It happens only with the latest version of the drivers: v5.3.4
It doesn't seems to be related #202 as there is no such issue with debian based systems
I have the chipset to do deeper testing...

rofl0r · 2018-11-22T15:33:16Z

hi @kcdtv ! glad you're back.

in case you can reproduce this issue, could you test the potential fix i pointed out anyway?

kcdtv · 2018-11-22T17:36:14Z

Hi again!
I've tried the fix you pointed out and it solved a part of the issue:
Wash now starts but remains"silent" (no AP shows up)
Fail
no packets received according to tcpdump

rofl0r · 2018-11-22T19:29:03Z

odd. if it affects tcpdump too, then reaver can't be blamed... if you feel adventurous, you could try to use git bisect on the driver's repo, to find the commit that introduced the bug. that would probably help a lot to understand the issue.

kcdtv · 2018-11-23T15:45:23Z

odd. if it affects tcpdump too, then reaver can't be blamed...

It affects tcpdump if i use it over wash
If i use tcpdump alone it works (in monitor mode).
The rest of aircrack-ng suite works correctly too.
I am not blaming reaver; There is definitely something new with this version of the drivers as there is no problem with others branches. As this drivers are unofficial and a bit "hackish" we can expect some strange little things.

if you feel adventurous, you could try to use git bisect on the driver's repo, to find the commit that introduced the bug.

The problem is that the issue appears since the first publication of this version of the drivers (v5.3.4). Reaver and wash never worked with them.

To solve the issue i also edited pcap_set_promisc to set the value of handle to 0 and wash worked.
In this case it is necessary to set pcap_set_rfmon and pcap_set_promisc to 0

if (handle) {
		pcap_set_snaplen(handle, 65536);
		pcap_set_timeout(handle, 50);
		pcap_set_rfmon(handle, 0);
		pcap_set_promisc(handle, 0);
		if(!(status = pcap_activate(handle)))
			return handle;
		if(status == PCAP_ERROR_RFMON_NOTSUP) {
			pcap_set_rfmon(handle, 0);
			status = pcap_activate(handle);
			if(!status) return handle;
		}

In the link you gave i understood it was only pcap_set_rfmon, maybe you were speaking about bothes.
Cheers 😺

rofl0r · 2018-11-23T15:51:09Z

thanks. i reported the issue here aircrack-ng/rtl8812au#238 . let's wait a little to see what @kimocoder has to say...

kimocoder · 2018-11-29T23:16:28Z

I have noticed this. Offline due to work offshore, brb!

kimocoder · 2018-12-07T16:29:43Z

@rofl0r and @kcdtv I've been looking a bit on it, can't really say whats wrong there.

This base is from Edimax, don't really know what changes/additions they've added to the drivers besides MESH mode and some other fixes, but I think the other dev had to disable the MESH mode support as it gave issues to other functions/parts of the driver. Anyway, scanning with "iw" and issues like that have been fixed in that release and it 'seems' more stable than the others. Also noticed "lwfinger" (Larry Finger) additions to the drivers, so it seems it is based on https://github.com/lwfinger/rtl8812au which is fairly known for making good Realtek drivers.

We've got together and we're trying to get in touch of Realtek about the matter on these issues/drivers or at least make an effort in getting it linux staging or something.

If chip-designers would go for a Realtek chipset, it is clearly that providing a working driver with it/them would be useful for both ends of the party and the rest of us 3rd-party.

Just updated the v5.2.20(.2) branch a bit and pushed it to Kali, wont push a non-Reaver-functional v5.3.4 driver as the reason we work on it as the main use of it is ment for it's penetration testing abilities (injection support).

kcdtv · 2018-12-10T14:11:31Z

Thanks for the updating... The drivers 5.2.20 works pretty well for me and have already some interesting patches like this anti KRACK ones. And it works as one module for all chipset so it is very handy (well, for the weird people that have several devices with chipsets form this kind, it might not be so relevant for normal users)

We've got together and we're trying to get in touch of Realtek about the matter on these issues/drivers or at least make an effort in getting it linux staging or something.

Good luck with that and thanks for your efforts 😺 Maybe speak about it with Alfa Network, it might help to get in touch with the adequate people from realtek. If you go through regular channel of communication it is pretty hard to get somewhere... Cheers

kimocoder · 2019-02-11T00:29:31Z

@kcdtv @rofl0r

I've added some penetration testing abilities to the new Realtek (clean Realtek base, not from vendor this time) multichip driver from 2018, the rtl8188eus (with support for rtl8188eu and rtl8188etv too) and I was shocked, cause the base is v5.3.9 and actually got much better code quality and stability than prior. Anyhow, with this driver, Realtek actually added frame injection themselves (wtf?) and also got this "pcap_activate" status.. really annoying when I found this new base.

repo is here

rofl0r · 2019-02-11T01:59:39Z

@kimocoder interesting. does the potential fix i suggested in #265 (comment) help ?

kimocoder · 2019-02-11T02:10:24Z

I'll check tomorrow 👍
What's new since lwfinger's v5.2.2.4 is

802.11s MESH mode supporter
Fixed signal leakage when testing MKK
Fixed external LNA CCK RSSI bug

Som the injection is faster than the 8812au (v5.2.2 base originally), packetloss (peaking) is fixed and they've been all over the place cleaning up, cause it's the same main base they always used for their multichip solution. Easy to pick patches/fixes from one to other though.

I'll give you feedback, cause I need it resolved so the 8812/14/21 experience could jump up a notch at least. And also for those other chipsets, they must have reaver aupported 🥇

kimocoder · 2019-02-15T14:38:47Z

Ok. @rofl0r @kcdtv I may confirm turning "pcap_set_rfmon" and "pcap_set_promisc" to "0" works fine.
Diving into..

kcdtv · 2019-02-15T17:42:18Z

Great news! I'll be around this weekend to check out and give you feedback. I have to try your latests commits in monitor mode. I tested some day ago hostapd in 5Ghz band with ac support and it worked smoothly. Reay cool. See you!

kimocoder · 2019-02-15T17:50:52Z

Great, jumped over to v5.3.4 and fixed the injection just now, also lots of data wasn't dropped in txdesc film and urb was leaking a bit. But overall it should be better than the 5.2.20(2).

Will fiddle around and try find the cause of the pcap_activate status ☺️

ligmaDX800 · 2019-03-22T13:48:37Z

is the fix to this found yet ?
help needed

even though most drivers on linux properly work with rfmon turned on, a few badly written ones create issues: issue #202 : rfmon mode causes additional interfaces to appear issue #265 : issues with RTL8812AU hackjob driver

rofl0r · 2019-03-22T20:55:02Z

@ligmaDX800 check PR #276

ligmaDX800 · 2019-03-22T23:17:33Z

rtl8188eu I have this one
tried your way still the same error

rofl0r · 2019-03-23T01:57:52Z

tried your way

you actually checked out the branch of that PR, compiled it, and still get the error ?

ligmaDX800 · 2019-03-23T07:42:29Z

I am actually new to linux so I dunno how it works correct me if I am wrong.
I copied the lines of code from commit that were changed and replaced them in the src/init.c file.

ligmaDX800 · 2019-03-23T08:14:20Z

update
its working thanks alot mate <3
I just read the read me file and it taught me how to do certain things I wasn't doing.
@rofl0r

rofl0r · 2019-03-23T13:32:06Z

alright thanks for testing

ligmaDX800 · 2019-03-23T16:30:45Z

I have come across another issue after running the reaver command following happens:

reaver -b 98:DE:D0:B2:F6:CA -i wlan0 -c 10 -vv

Reaver v1.6.5-git-18-g48a0a8b WiFi Protected Setup Attack ToolCopyright (c) 2011, Tactical Network Solutions, Craig Heffner cheffner@tacnetsol.com
[+] Switching wlan0 to channel 10
[+] Waiting for beacon from 98:DE:D0:B2:F6:CA
[+] Received beacon from 98:DE:D0:B2:F6:CA
[+] Vendor: AtherosC
[+] Trying pin "12345670"
[+] Sending authentication request
[!] WARNING: Receive timeout occurred

rofl0r · 2019-03-23T16:49:03Z

new issue -> [new issue]

but check https://github.com/t6x/reaver-wps-fork-t6x/wiki/Troubleshooting first

rofl0r · 2019-04-06T16:51:41Z

ok since #276 was merged this can be closed.

MichaelChay · 2019-05-03T02:48:54Z

To solve the issue i also edited pcap_set_promisc to set the value of handle to 0 and wash worked.
In this case it is necessary to set pcap_set_rfmon and pcap_set_promisc to 0
if (handle) {
		pcap_set_snaplen(handle, 65536);
		pcap_set_timeout(handle, 50);
		pcap_set_rfmon(handle, 0);
		pcap_set_promisc(handle, 0);
		if(!(status = pcap_activate(handle)))
			return handle;
		if(status == PCAP_ERROR_RFMON_NOTSUP) {
			pcap_set_rfmon(handle, 0);
			status = pcap_activate(handle);
			if(!status) return handle;

@kimocoder where to locate this file in directory for editing pcap_set_rfmon and pcap_set_promisc to 0 ????

rofl0r · 2019-05-03T03:09:54Z

@kimocoder where to locate this file in directory for editing pcap_set_rfmon and pcap_set_promisc to 0 ????

grep for pcap_set_snaplen. grep -r pcap_set_snaplen .

MichaelChay · 2019-05-03T11:22:38Z

grep -r pcap_set_snaplen .
it take too long to search in the root directory !!!!!!

do you have the file path ????

rofl0r · 2019-05-03T13:06:46Z

it take too long to search in the root directory !!!!!!

try it inside the source directory of reaver

neilkerman · 2019-05-25T11:26:26Z

it take too long to search in the root directory !!!!!!

try it inside the source directory of reaver

Where do i find the source directory of reaver? I am new to linux so i really dont know how to find it. I also tried using grep, but it doesn't gives a proper output.

neilkerman · 2019-05-25T11:27:54Z

update
its working thanks alot mate <3
I just read the read me file and it taught me how to do certain things I wasn't doing.
@rofl0r

May you please tell me what are the steps you did to fix it?

maxrull0 · 2019-06-05T00:30:54Z

odd. if it affects tcpdump too, then reaver can't be blamed...

It affects tcpdump if i use it over wash
If i use tcpdump alone it works (in monitor mode).
The rest of aircrack-ng suite works correctly too.
I am not blaming reaver; There is definitely something new with this version of the drivers as there is no problem with others branches. As this drivers are unofficial and a bit "hackish" we can expect some strange little things.

if you feel adventurous, you could try to use git bisect on the driver's repo, to find the commit that introduced the bug.

The problem is that the issue appears since the first publication of this version of the drivers (v5.3.4). Reaver and wash never worked with them.

To solve the issue i also edited pcap_set_promisc to set the value of handle to 0 and wash worked.
In this case it is necessary to set pcap_set_rfmon and pcap_set_promisc to 0
if (handle) {
		pcap_set_snaplen(handle, 65536);
		pcap_set_timeout(handle, 50);
		pcap_set_rfmon(handle, 0);
		pcap_set_promisc(handle, 0);
		if(!(status = pcap_activate(handle)))
			return handle;
		if(status == PCAP_ERROR_RFMON_NOTSUP) {
			pcap_set_rfmon(handle, 0);
			status = pcap_activate(handle);
			if(!status) return handle;
		}
In the link you gave i understood it was only pcap_set_rfmon, maybe you were speaking about bothes.
Cheers 😺

Where is the destination of the mentioned file that should be edited ?

My output from "reaver -i wlan0 -b MAC is :
[X] ERROR: pcap_activate status -1
[X] PCAP: generic error code
couldn't get pcap handle, exiting

rofl0r · 2019-06-05T00:41:30Z

there's no need to edit anything, the patches mentioned here are already merged into master.
if you have problems with pcap, you should probably first try to get aircrack-ng working (which i assume doesn't work either, because you seem to have forgotten to activate monitor mode...).
if you have further issues, open a new issue. i will close this now for good since the original issue is long resolved.

rofl0r mentioned this issue Nov 23, 2018

5.3.4 issues with promisc/rfmon mode aircrack-ng/rtl8812au#238

Closed

pilotnbr1 mentioned this issue Dec 17, 2018

Missing Modules RespawnDespair/wifibroadcast-image-builder#106

Open

rofl0r mentioned this issue Mar 22, 2019

activate rfmon only on apple #276

Merged

rofl0r closed this as completed Apr 6, 2019

vav4eg mentioned this issue May 10, 2019

ERROR: pcap_activate status -8 and pcap_activate status -1 #282

Open

Repository owner locked as resolved and limited conversation to collaborators Jun 5, 2019

RTL8812AU [X] ERROR: pcap_activate status -1 #265

RTL8812AU [X] ERROR: pcap_activate status -1 #265

Comments

gantarone commented Nov 21, 2018 • edited Loading

rofl0r commented Nov 21, 2018

gantarone commented Nov 21, 2018 • edited Loading

rofl0r commented Nov 21, 2018

kcdtv commented Nov 22, 2018

rofl0r commented Nov 22, 2018

kcdtv commented Nov 22, 2018

rofl0r commented Nov 22, 2018

kcdtv commented Nov 23, 2018 • edited Loading

rofl0r commented Nov 23, 2018

kimocoder commented Nov 29, 2018

kimocoder commented Dec 7, 2018 • edited Loading

kcdtv commented Dec 10, 2018

kimocoder commented Feb 11, 2019

rofl0r commented Feb 11, 2019

kimocoder commented Feb 11, 2019 • edited Loading

kimocoder commented Feb 15, 2019

kcdtv commented Feb 15, 2019

kimocoder commented Feb 15, 2019

ligmaDX800 commented Mar 22, 2019

rofl0r commented Mar 22, 2019

ligmaDX800 commented Mar 22, 2019

rofl0r commented Mar 23, 2019

ligmaDX800 commented Mar 23, 2019

ligmaDX800 commented Mar 23, 2019

rofl0r commented Mar 23, 2019

ligmaDX800 commented Mar 23, 2019

rofl0r commented Mar 23, 2019

rofl0r commented Apr 6, 2019

MichaelChay commented May 3, 2019

rofl0r commented May 3, 2019

MichaelChay commented May 3, 2019

rofl0r commented May 3, 2019

neilkerman commented May 25, 2019

neilkerman commented May 25, 2019

maxrull0 commented Jun 5, 2019

rofl0r commented Jun 5, 2019

gantarone commented Nov 21, 2018 •

edited

Loading

gantarone commented Nov 21, 2018 •

edited

Loading

kcdtv commented Nov 23, 2018 •

edited

Loading

kimocoder commented Dec 7, 2018 •

edited

Loading

kimocoder commented Feb 11, 2019 •

edited

Loading