pita.cap exit status 1

[V0r-T3x]

I'm trying to run the pita.cap, but it fail with exit status 1 on the !monstop. I run P4wnP1_aloa (kali linux 4.14.80-Re4son+) on a raspberry pi zero W. I checked the processes who can interfere with the monitor mode with:

airmon-ng check
airmon-ng check kill

In general, i have to kill avahi-daemon, wpa_supplicant and dhcpcd.

I putted the wlan0 on monitor mode with:

airmon-ng start wlan0

Now i tried to start pita.cap:

bettercap -iface wlan0mon -caplet /usr/local/share/bettercap/caplets/pita.cap

i got this error: [sys.log] [err] error while running caplet /usr/local/share/bettercap/caplets/pita.cap: exit status 1

i tried the command !monstop and i got the same error. If i remove this command in the pita.cap, the script start, but rapidly i got this error: [sys.log] [err] wifi could not inject WiFi packet: send: Resource temporarily unavailable

Is it normal? What is the use of !monstop in that script, and is it important to avoid error...?

[V0r-T3x]

i figured out that the !monstop & !monstart, is just a command to put the wlan in monitoring mode. Then it's right in my situation to put the wlan0 into monitoring with aircrack-ng

now i will try to find whats causing the trouble with the injection packet.

[buffermet]

First of all your report is incomplete.

Some wifi chipsets don't support monitor mode/packet injection.

What network adapter are you using?

[V0r-T3x]

@buffermet What do you need to know to have a full report?

I use the native physical Broadcom bcm2835 chipset from the raspberry Pi zero W. I supposed, it doesn't support fast speed injection, but it can inject. I can put the chipset in monitoring mode and the injection work.

I follow partially the mass deauther tuto of evilsocket and the base concept of the Pwnagotchi to use bettercap as a service to avoid the need of a terminal.

I searched if we can put delay between each injection try. The only delay a find is the one for the ticker module, and this is not working to avoid this error.

[buffermet]

Hi @V0r-T3x, unfortunately the onboard wireless card on the Pi Zero W does not support monitor mode or packet injection.

You will need to use an external WiFi adapter that does support it.

What do you need to know to have a full report?

There is an issue template that you removed at the start of writing your report.

[V0r-T3x]

@buffermet by the way, when i try to create a new issus (even on desktop or mobile browser), there's no issue template.

i put the chipset in monitoring mode with airmon-ng start wlan0 and i test the injection with aireplay-ng --test wlan0mon. This is the result. The chipset is 43430, i though is was the bcm2835.

[buffermet]

Might be a driver issue then.

Try nexmon.

there's no issue template

My bad, looks like the caplets repo doesn't have an issue template.

[V0r-T3x]

@buffermet ok thanks for help, i will search in this way. I saw the P4wnP1_aloa (kali linux 4.14.80-Re4son+) have a custom wifi firmware build on the nexmon framework. I will see if i can try to find the source of the error there.

[buffermet]

Yep, try the nexmon firmware and see if it works.

Broadcom chips are notorious for not supporting monitor mode and packet injection, but nexmon can be a solution.

[V0r-T3x]

@buffermet I added events.stream off to my "custom pita caplet", I set net.sniff.verbose false, and the bettercap run in service on P4wnP1_aloa. The good version of nexmon driver was already install on this version, but with all the stream the chipset was lagguy. But now, i have way less errors! Maybe 3.5% of error compare with package, versus more then 150% of errors XD.

this is my caplet, is it ok? have I to change something? aloa.cap:

# every 5 seconds:
# - clear the screen
# - show the list of nearby access points
# - deauth every client from each one of them
set ticker.period 5
set ticker.commands clear; wifi.show; wifi.deauth ff:ff:ff:ff:ff:ff
# sniff EAPOL frames ( WPA handshakes ) and save them to a pcap file.
set net.sniff.verbose false
set net.sniff.filter ether proto 0x888e
set net.sniff.output ~/captures/wpa.pcap

set wifi.handshakes.file ~/captures/hds.pcap

# uncomment to only hop on these channels:
# wifi.recon.channel 1,2,3
events.stream off
wifi.recon on
ticker on
net.sniff on

# we'll see lots of probes after each deauth, just skip the noise ...
events.ignore wifi.client.probe
events.ignore wifi.log
# start fresh
events.clear
clear

[buffermet]

@V0r-T3x what errors are you talking about?

[V0r-T3x]

@buffermet with wifi.show I see the total error counting and the packets sent. If the net.sniff.verbose is set to true, the number of errors counted is rapidly superior of the number of packets sent (ex. After 8min: 6400 packets for 14000 errors, appprox. 218%). When is set to false, the ratio is approximately 75%(ex. After half an hour: 11400 packets for 8600 errors), even after an hour of test. Is the net.sniff.verbose is just to print info on the screen, or it's important for something else? The events.stream off, hide everything, I don't see errors, but the writing on the SD card is less heavy. Is seem to work and I think it's correct for my needs.

[buffermet]

The events.stream off, hide everything, I don't see errors

I still don't know what errors you're talking about, can you show some logs?

That your Pi Zero W is running slow does not surprise me, you need sufficient memory for bettercap to MITM active networks.

[buffermet]

Your other questions are answered in the documentation.

https://www.bettercap.org/

[V0r-T3x]

@buffermet if I show all logs, the only error I get is [sys.log] [err] wifi could not inject WiFi packet: send: Resource temporarily unavailable and the number of error corresponding exactly to them. I'm not surprise with the performance of the RPi0W. Thanks again for the help, I don't think I can do better with this set up, but it work.

[V0r-T3x]

I try the set up with a Alfa AWUSO36NH and I don't have any errors with this adaptor, it's really just the performance of the native wifi chipset of the RPi0W who cause this little trouble.

[buffermet]

Ok, great. Happy hacking!

[buffermet]

FWIW Resource temporarily unavailable looks like it's an error that comes from iw, but I could be wrong.

Related issue: https://github.com/bettercap/bettercap/issues/569#issuecomment-493670894