Raspberry pi terminates wlandump-ng about hcxtools HOT 79 CLOSED

Now, have fun with hcxtools.

from hcxtools.

Cheers

from hcxtools.

Othery way around would be to just add the interface name in /etc/network/interfaces like this:

iface wlan0 inet manual

And then restart.
NetworkManager is ignoring any interfaces described in /etc/network/interfaces by default, so it will no longer try to control it and you wouldn't have to bother and kill the processes anymore. You can confirm if it works by using:

nmcli d

It should show that the interface is not being managed by networkmanager.

from hcxtools.

Guys, looks like we need a place to write all those tips&tricks, since they will get lost in bugtracker.
@ZerBea , how about enabling the Wiki module for the repo(or maybe better, for hcxdumptool repo)? Then @strasharo can write some tips there, we can add something and etc. Looks like everyone have his own set of scripts and configurations :)

from hcxtools.

Hi.
Failed to stop NetworkManager.service: Unit NetworkManager.service not loaded.
The script is designed to use with arch LINUX. UBUNTU use different commands.
I think the correct UBUNTU command is "sudo stop network-manager", but I'm not shure.

command failed: Operation not supported (-95)
This means, iw isn't able to put your device into monitor mode, because the driver doesn't support monitor mode.
The build-in WiFi chip doesn't support minitor mode, too:
addr b8:27:eb:30:42:63
$ whoismac -m b827eb304263
b827eb Raspberry Pi Foundation

type managed
This means, that the device is not in monitor mode, so wlandump-ng and hcxdumptool will fail.

Any ideas how I can fix this?
-use an external USB-WiFi-adapter which support monitor mode
-identify all UBUNTU networking services and stop them.
https://askubuntu.com/questions/21654/how-to-temporarily-turn-off-networkmanager-from-the-command-line

from hcxtools.

You have to use nexmon driver, stock ones for the RPI on board wifi don't support monitor mode.
https://github.com/seemoo-lab/nexmon

from hcxtools.

from hcxtools.

I got an external wifi adapter, which does support monitoring mode. After a few seconds of running wlandump-ng, the programm still terminates. The output is as follows:

Any idea, what I am missing? This time, my device is definitly in monitoring mode.

from hcxtools.

Can you try running this prior switching the interface to monitor:
sudo systemctl stop network-manager
And then switch the interface in monitor.

from hcxtools.

Can you try running this prior switching the interface to monitor:
sudo systemctl stop network-manager
And then switch the interface in monitor.

Still the same problem. The program just simply terminates after a couple of seconds.

Could there be a problem with my operating system on the pi? I am currently running "ubuntu mate".
The wifi adapter, that I am using is the CSL USB 2.0 WIFI adapter 300Mbit (2,4/5GHz) (Chipset: Ralink RT5572).

Also did the testing with one of my laptops (with the same usb wifi adapter) and it works fine. So it seems like that there is a problem with the raspberry pi 3b+.
Has anyone experienced using the wlandump-ng tool and a raspberry pi?

from hcxtools.

I mean it explicitly says in the description of this repo, that the scripts are designed to run on raspberry pis, right?

from hcxtools.

The next possible issue you ran into is the power supply as described here
https://forum.hashkiller.co.uk/topic-view.aspx?t=24607&m=178014#178014
and here:
https://forums.kali.org/showthread.php?31887-problem-with-raspberry-pi-3-and-alfa-awus036nha
It is also possible that wlandump-ng terminates when it can't access the device, because another tool has access to the device (for example: network-manger)

Please try hcxdumptool (https://github.com/ZerBea/hcxdumptool). It shows read errors immediately.

And from the readme.md
Requirements:
Linux recommended Arch
Raspberry Pi (Recommended: A+ = very low power consumption or B+)

from hcxtools.

Yep, but usually folks run either Raspbian or Kali on those, Ubuntu isn't that commonly used. Personally I use it on multiple Raspberry Zero's with external WN722N adapter and it works without any issues.

I have two guesses for it, either something tried to take control of the adapter and prevents the dump tool from using it or at least for the external adapter it's possible the Raspberry doesn't provide it with enough power. Prior launching the dump can you just try one more thing:`

sudo airmon-ng check

And post the output here.

from hcxtools.

Which driver do you use for the CSL USB 2.0 WIFI?
As far as I know this is the only working driver (full monitor mode support for Realtek chipsets):
https://github.com/kimocoder/rtl8812au
The Ralink RT5572 use the rt2800USB driver, and that one has trouble on kernel 4.4 (rt2x00 driver regression).

from hcxtools.

Did wlandump-ng terminate after 5 seconds? Exactly after that time it will try to change the channel.
If it can't do that, it will terminate.

from hcxtools.

Pushed an update wlandump-ng:
show info about internal errors if wlandump-ng terminates
If this value isn't 0, wlandump-ng doesn't have full and only access to the device.

from hcxtools.

The next possible issue you ran into is the power supply

I am running the RP3+ with a power supply module with 5 Volts and 3 Amps which should be plently. Of course I dont know how much power still reaches the usb plug. Furthermore, the wifi module CSL USB 2.0 WIFI is said to be compatible with the raspberry pi. Of course, I can't exclude that the power supply is the problem but since I am working a lot with electronical devices myself, it doesn't make much sense to be the problem in this situation.

EDIT: Just measured the voltage of the usb plug. There are 5.1 volts reaching the plug.

from hcxtools.

Pushed an update wlandump-ng:
show info about internal errors if wlandump-ng terminates

Somehow it is working now.
Have you changed anything besides printing the errors to the console?

Thanks a lot for your help. If you want, I can still show you the requested outputs.

from hcxtools.

Please try hcxdumptool (https://github.com/ZerBea/hcxdumptool). It shows read errors immediately.

Here the output of the hcxdumptool. It shows a seg,entation fault after approximately 10 seconds:

from hcxtools.

Prior launching the dump can you just try one more thing:`

sudo airmon-ng check

The output after entering the monitor mode is:

Found 6 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to run 'airmon-ng check kill'

  PID Name
  349 avahi-daemon
  358 avahi-daemon
  359 dhcpcd
  392 wpa_supplicant
  482 wpa_supplicant
  511 dhclient

EDIT: After running airmon-ng check kill, hcxdumptool worked perfectly fine.

from hcxtools.

Everything seems to work now. I would still like to know:
@ZerBea, have you made any significant changes?

from hcxtools.

Nic, that it works.
No, there are no significant changes, only a debug printf if wlandump-ng terminates:
printf("\nterminated (internal errors: %d)...\e[?25h\n", internalpcaperrors);

PID Name
349 avahi-daemon -> no need to stop it
358 avahi-daemon -> no need to stop it
359 dhcpcd -> no need to stop it
392 wpa_supplicant -> must be stopped
482 wpa_supplicant -> must be stopped
511 dhclient -> no need to stop it

It seems that network-manager isn't started by default. Now we know, why we can't stop it.

hcxdumptool:
The segmentation fault is caused by the driver!
So it looks like we have still some driver issues.

Power supply:
3 A are more than enough.

from hcxtools.

It seems that network-manager isn't started by default. Now we know, why we can't stop it.

So do I have to kill the network-manager using airmon-ng check kill every single time I want to use wlandump-ng?

The segmentation fault is caused by the driver!

How can I check what driver version my usb device is using? And would you recommend to upgrade the driver to https://github.com/kimocoder/rtl8812au ?

from hcxtools.

So do I have to kill the network-manager using airmon-ng check kill every single time I want to use wlandump-ng?

No, there is no need to run airmon-ng.
Just remove this line from makemonnb script:
sudo systemctl stop NetworkManager.service

Just remove this line from killmonnb script:
sudo systemctl start NetworkManager.service

How can I check what driver version my usb device is using?
$ sudo lshw -C network

Output should look like this:
*-network DISABLED
description: Wireless interface
physical id: 1
bus info: usb@1:2
logical name: wlp3s0f0u2
serial: c8:3a:35:df:37:2e
capabilities: ethernet physical wireless
configuration: broadcast=yes driver=rt2800usb driverversion=4.17.2-1-ARCH firmware=N/A link=no multicast=yes wireless=IEEE 802.11

And would you recommend to upgrade the driver to https://github.com/kimocoder/rtl8812au ?
No, because this driver doesn't work with you hardware

from hcxtools.

Could you please try aireplay-ng -9 to see if packet injection is working and how long it is working.
Which kernel version do you use (uname -r)?

from hcxtools.

Please try again hcxdumptool with option -t 5 (instead of -t 1000) to see if we got internal errors after a period of 5 seconds.

from hcxtools.

I don't have access to the pi right now. I will do the testing in about 2 hours and then show the results in this issue.

Thanks so far for all your effort!

from hcxtools.

The output of sudo lshw -C network:

  *-network:1
       description: Wireless interface
       physical id: 3
       bus info: usb@1:1.1.2
       logical name: wlx24050ff61e8d
       serial: ee:7b:17:36:22:dd
       capabilities: ethernet physical wireless
       configuration: broadcast=yes driver=rt2800usb driverversion=4.14.34-v7+ firmware=0.36 link=no multicast=yes wireless=IEEE 802.11

The output of uname -r is:

4.14.34-v7+

from hcxtools.

That looks fine. LINUX kernel is ok and driver is ok, too.
No let's test if we will get an error here:
please try hcxdumptool with option -t 5 (instead of -t 1000)

from hcxtools.

The output of sudo hcxdumptool -i wlx24050ff61e8d -o test.cap -c 11 -t 5 -s is:

And it crashed (runs into segmentation fault) after about 45 seconds.

from hcxtools.

Ok, we have no internal errors: err=0
But I'm still not shure about the services from MATE.
According to this:
https://raspberrypi.stackexchange.com/questions/67997/wifi-not-connecting-on-raspberry-pi-3-with-ubuntu-mate-16-04
NetworkManager is started on default.

According to this:
#40 (comment)
it isn't running.

what shows
$ ps -ALL | grep anag

from hcxtools.

$ ps -ALL | grep anag
  158   158 ?        00:00:00 charger_manager
  875   875 ?        00:00:01 NetworkManager
  916   916 ?        00:00:00 ModemManager

Seems like NetworkManager is running.

from hcxtools.

This should stop the NetworkManager:
$ sudo service NetworkManager stop

from hcxtools.

Now we can test if wlandump-ng terminates again and/or hcxdumptool run into a segmentation fault

from hcxtools.

This should stop the NetworkManager:
$ sudo service NetworkManager stop

Should I stop the NetworkManager before or after entering the monitoring mode?

from hcxtools.

Does wlandump-ng terminate with an error > 0 ?

from hcxtools.

You can Stop it before or after entering monitor mode!

from hcxtools.

Before starting wlandump-ng none of this services must run:
NetworkManager
wpa-supplicant

If wlandump-ng terminates we can do a check again if some of the services
are started by another (unknown) service.
Just do a
ps -All | grep ana
ps -A | grep wpa
to see if on of this services run again.

from hcxtools.

When I am killing the NetworkManager service, I am not able to run wlandump-ng anymore:

$ sudo wlandump-ng -i wlx24050ff61e8d -o new_test.cap -s -c 11 -t 86400
error opening device wlx24050ff61e8d: wlx24050ff61e8d: That device is not up

from hcxtools.

One side question:
Is it normal that hcxdump recieves more handshakes than wlandump-ng?

from hcxtools.

Just bring the device up:
$ sudo ip link set wlx24050ff61e8d up
and check if monitor mode is enabled:
$ sudo iw dev wlx24050ff61e8d info

from hcxtools.

hcxdumptool is the successor of wlandump-ng.
I dropped libpcap because latest Android and LINUX are running counter measures against ap-less attacks. So we have to add counter counter measures and libpcap is too slow for that purpose.
Result is an extreme fast and very agressive new attacker. Receiving an associationrequest and a M2 from a client is enough. Packets from an AP are not needed any longer.

from hcxtools.

After entering the monitoring mode:
$ ./makemonnb wlx24050ff61e8d

stopping the NetworkManager:
$ sudo service NetworkManager stop

bringing up the device:
$ sudo ip link set wlx24050ff61e8d up

checking if the device is in monitoring mode:

$ sudo iw dev wlx24050ff61e8d info
Interface wlx24050ff61e8d
	ifindex 3
	wdev 0x1
	addr 24:05:0f:f6:1e:8d
	type monitor
	wiphy 0
	channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
	txpower 20.00 dBm

Running sudo hcxdumptool -i wlx24050ff61e8d -o test.cap -c 11 -t 5 -s, I am still getting the seg fault after a couple of seconds:

Segmentation fault rcv=11137, err=0

EDIT:
Although I killed the NetworkManager, the wpa_supplicant was still online.
I then killed those processes by entering: sudo airmon-ng check kill

sudo airmon-ng check

Found 6 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to run 'airmon-ng check kill'

  PID Name
  352 avahi-daemon
  378 dhcpcd
  389 avahi-daemon
  457 wpa_supplicant
  479 wpa_supplicant
  507 dhclient

When I then ran hcxdumptool, there was no segmentation fault anymore.

from hcxtools.

Edited the comment above.

from hcxtools.

please try aireplay-ng -9 on that interface
is injection working ?

from hcxtools.

Yes, injection is working:

$sudo aireplay-ng -9 wlx24050ff61e8d
20:52:28  Trying broadcast probe requests...
20:52:28  Injection is working!
20:52:30  Found 20 APs

20:52:30  Trying directed probe requests...
20:52:30  
............................................
.............................................
..............................................

from hcxtools.

No need to test it any longer using aireplay-ng!

from hcxtools.

Updated comment above.
Injection is working.

from hcxtools.

When I then ran hcxdumptool, there was no segmentation fault anymore.
That sounds good. We must stop this services:
NetworkManager
wpa-supplicant
dhclient (I'm not shure, but better to kill this service on UBUNTU-MATE)

Last step is to add this to the script makemonnb:
remove this 2 lines from the script:
sudo systemctl stop NetworkManager.service
sudo systemctl stop wpa_supplicant.service

and add this commands to stop the services
sudo service NetworkManager stop
sudo killall -9 wpa_supplicant
sudo killall -9 dhclient

from hcxtools.

run the script and check if the services really stopped
ps -All | grep ana
ps -All | grep wpa
ps -All | grep dhc

if none of the services is running, everything should be fine.
Otherwise we must look for the UBUNTU-MATE commands to stop/kill them.

from hcxtools.

The default conversiontool (cap to hccapx, cap to john) for hcxdumptool is hcxpcaptool.
And at least, please close this issue if everything's running like expected

from hcxtools.

The remaining services are:

$ ps -All | grep ana
4 S     0   356     1  0  80   0 - 13224 -      ?        00:00:00 ModemManager

and

$ ps -All | grep dhc
5 S     0   373     1  0  80   0 -   754 -      ?        00:00:00 dhcpcd

But those dont harm the scripts right?

from hcxtools.

No, that's ok
dhcpcd is running here too

from hcxtools.

Ok thanks a lot for your effort!
I will close this Issue now.

from hcxtools.

Nice info about NetworkManager. I didn't know this, before (I don't use NM). So, thanks.

from hcxtools.

@strasharo thanks, that works also perfectly fine.

from hcxtools.

It works with no issues or hassle on the regular desktop, why it couldn't run same on Raspi.

I have similar issue. I run through Kali + Raspi 3 B + Alfa + battery bank (5v; 2.4A) = consistently rebooting, TP-LiNK 722 doesn't force to reboot, but monitor fails with SEG problem all the time almost instantly after run airodump-ng. Neither removing NetworkManager or WPAsupplicant.

from hcxtools.

That is based on several factors:

1. hardware (incl WiFi hardware)
2. operating system (OS)
3. configuration of the OS
4. knowledge of the user

Nearly all of the issues are related to the factors 1 to 3. To be able to correct an error depends on factor 4.
It doesn't make sense to install an oversized OS or a multimedia OS to dump WiFi traffic.
This OS run services by default which you do not need and you have to identify them and to stop them. Latest airmon-ng has 1525 lines to identify this services and stop them.
It makes sense to install an OS tailored to the task. That is the main reason, why I recommend arch LINUX. No beautifull GUI to install and all configs must be done "by hand".
But you will learn much about LINUX. You know the services and you know which service has access to your hardware (and last but not least how to disable/enable the service). From now on, you do not need a big script to put your device into monitor mode. Only a few lines of code are enough.
You will be rewarded with an absolute stable and fast system.

For shure, UBUNTU, KALI, WIFISLAX makes life easier, but you will learn nothing!
The distrubutor decides for you and you have to live with his decision!

from hcxtools.

ZerBea, thanks for your opinion.
I'm currently running specifically designed for Raspberry Pi 3 B model Kali distribution, which is generally suggested to be used with ALFA Networks wifi devices and for use in penetration testing activities.

from hcxtools.

Raspberry Zero attached to a powerbank works fine for me with TL-WN722N and some Alfa adapters as well. Running on Kali from here https://re4son-kernel.com/re4son-pi-kernel/. I'm not removing NetworkManager or wpa_supplicant, because I use NetworkManager to manage the onboard wireless interface in client mode, the external interfaces I use for hcxdumptool/Kismet are exclude from NetworkManager using /etc/network/interfaces as described above. Since sometimes I'm attaching multiple external wifi interfaces I'm assigning them static interface names using udev rules. hcxdumptool is started on boot using crontab + detached screen session.

from hcxtools.

Nice info. Thanks for sharing this. It looks like they included all "neccessary" drivers:
RTL8188EU driver (TL-WN722N v2) with monitor mode support
RTL8812AU (AWUS036ACH) & RTL8814AU with monitor & injection support
Wifi injection support for Alfa AWUS051NH v2
I'm shure this info will help many people to get their system up.

from hcxtools.

strasharo, great info, thanks.

from hcxtools.

If you have any questions on the setup of fully automated mobile handshake capture boxes just let me know, if have some know how to share.

from hcxtools.

strasharo, twit me on @eugenekreger

from hcxtools.

@eugenekreger Done.

Also, since the exclusion solution above is for Debian based distributions, a generic way to exclude an interface from Network Manager would be this:
nmcli dev set <interface name> managed no

from hcxtools.

Yup, that's a great idea. Guess there's demand for it and it would be helpful to exchange some ideas regarding the setup of such devices.

from hcxtools.

Yes, please do that!

from hcxtools.

Great idea!
Wiki enabled for hcxtools and hcxdumptool.

from hcxtools.

Hi.
Failed to stop NetworkManager.service: Unit NetworkManager.service not loaded.
The script is designed to use with arch LINUX. UBUNTU use different commands.
I think the correct UBUNTU command is "sudo stop network-manager", but I'm not shure.

command failed: Operation not supported (-95)
This means, iw isn't able to put your device into monitor mode, because the driver doesn't support monitor mode.
The build-in WiFi chip doesn't support minitor mode, too:
addr b8:27:eb:30:42:63
$ whoismac -m b827eb304263
b827eb Raspberry Pi Foundation

type managed
This means, that the device is not in monitor mode, so wlandump-ng and hcxdumptool will fail.

Any ideas how I can fix this?
-use an external USB-WiFi-adapter which support monitor mode
-identify all UBUNTU networking services and stop them.
https://askubuntu.com/questions/21654/how-to-temporarily-turn-off-networkmanager-from-the-command-line

Hi ,
I'm actually trying hcxdumptool on my external usb alfa awus036h wich I was using with my PC and kali to test stuff. if your looking for someone to test hcxdumptool on an external usb alfa antenna I'll be glad to help.
BTW I got that error:
interface is not up
failed to init scket

hope it will help.

from hcxtools.

Hi,
With "interface is not up" hcxdumptool will notice you, that it isn't able to activate
the interface, because another process / tool takes access to the interface.
A direct result of this is that hcxdumptool can not create the socket for that interface "failed to init socket".
Read more about this and how to find out if the interface is set to monitor mode, here:
https://hashcat.net/forum/thread-6661-post-41821.html#pid41821

The awus036h is a good adapter, but the signal is going to be crappy if tx output is too high or the power consumption is higher than usb can provide.

from hcxtools.

Hi,
With "interface is not up" hcxdumptool will notice you, that it isn't able to activate
the interface, because another process / tool takes access to the interface.
A direct result of this is that hcxdumptool can not create the socket for that interface "failed to init socket".
Read more about this and how to find out if the interface is set to monitor mode, here:
https://hashcat.net/forum/thread-6661-post-41821.html#pid41821

The awus036h is a good adapter, but the signal is going to be crappy if tx output is too high or the power consumption is higher than usb can provide.

I actually just manage to make it work by using the unmanaging interface trick from @strasharo
if you want I can give you updates on that adapter.

from hcxtools.

The downside of the command I provided is that it's not permanent and the unmanaged status doesn't persist over reboots. I'll try to doc a permanent solution via an udev rule in the next day or two in the wiki section.

from hcxtools.

That sounds good. It will be a nice option (for example in combination with a Raspberry PI ZERO W).
Today I'll test a new adapter: DIGITUS DN-70440-1 (Ralink RT7601)
During many tests I noticed, that this cheap adapters (connected to a Raspberry Pi, in combination with an external high gain antenna) are on the same level (or better: their power consumption is much lower) as the expensive Alfas.

from hcxtools.

Yup, that's my main setup, a Zero W with the onboard wifi being managed by NetworkManager and roaming around networks for Internet and an external one connected via OTG for the injection stuff (usually a TL-WN722N v1 or a TOTOLINK N300UA (Ralink RT3072)). I also sometimes use the onboard bluetooth of the Raspberry as a PAN AP, so I'm connecting to it from my phone and follow the status via SSH. Will try to write up those in case someone might use those as well.

The Digitus one looks nice, what antenna do you use with it?

from hcxtools.

I got the DIGITUS DN-70440-1 today - and sent it back!
Instead of the Ralink RT7601 chipset, the adapter has a build in RTL8188ETV chipset. I think DIGITUS made an update, but doesn't inform the dealers about this "internals":
[20757.733622] usb 5-4.5: Manufacturer: Realtek
[20757.733624] usb 5-4.5: SerialNumber: 00E04C1A0B63
[20757.762572] r8188eu: module is from the staging directory, the quality is unknown, you have been warned.
[20757.767046] Chip Version Info: CHIP_8188E_Normal_Chip_TSMC_D_CUT_1T1R_RomVer(0)
[20757.787120] usbcore: registered new interface driver r8188eu
The staging driver is unuseable for monitor mode!

from hcxtools.

Perhaps they have different versions like TL-WN722N does? (V1 is Atheros, V2 to V4 are Realtek).

from hcxtools.

I'm sure they have different versions:
Just do a google search for
DIGITUS 70440-1 RT7601
and for
DIGITUS 70440-1 RTL8188ETV
Life could be so easy..., but there is absolutely no version info (like 70440-1 and 70440-2)!

BTW:
I'm using panel (TP-LINK TL-ANT2414), dish (LOGILINK WL0097) and mobile (D-Link ANT24-0501) antennas.

from hcxtools.

Added some notes on NetworkManager to the wiki:
https://github.com/ZerBea/hcxdumptool/wiki/Excluding-network-adapters-from-NetworkManager

from hcxtools.

That is great, thanks.
I pushed an update:
From now on hcxdumptool detect NetworkManager and wpa_supplicant and show a warning if they are running.

from hcxtools.