Why --help doesn't show usage?

[fa1rid]

hcxdumptool --help

hcxdumptool 6.3.5  (C) 2025 ZeroBeat
Additional information:
-----------------------
press GPIO button to terminate
 hardware modification is necessary, read more:
 https://github.com/ZerBea/hcxdumptool/tree/master/docs
to store entire traffic, run tshark in parallel on the same interface:
 $ tshark -i <interface> -w allframes.pcapng

Berkeley Packet Filter:
-----------------------
  see man bpfc

Important recommendation:
-------------------------
Do not set monitor mode by third party tools or third party scripts!
Do not use virtual interfaces (monx, wlanxmon, prismx, ...)!
Do not use virtual machines or emulators!
Do not run other tools that take access to the interface in parallel (except: tshark, wireshark, tcpdump)!
Do not use tools to change the virtual MAC (like macchanger)!
Do not merge (pcapng) dump files, because this destroys assigned hash values!

[fa1rid]

Also, I was trying to run it on RPI 3B+, the latest git version seems broken. It will get stuck at starting...
I tried the last released version 6.3.5 instead and it worked. What's going on with the master git?
I find this tool unstable since the major refactor you did. It used to be better before the refactor and able to get more handshakes.

hcxdumptool --help
hcxdumptool 6.3.5  (C) 2024 ZeroBeat
Additional information:
-----------------------
get information about running services that have access to the device:
 $ sudo systemctl --type=service --state=running
stop all services that have access to the interface, e.g.:
 $ sudo systemctl stop NetworkManager.service
 $ sudo systemctl stop wpa_supplicant.service
run hcxdumptool - it will set an appropriate monitor mode
 scan for ACCESS POINTS in range (packets are not stored to dump file, not in combination with attack modes)
  $ hcxdumptool -i INTERFACENAME -F --rcascan=active
 attack target(s) (not in combination with rcascan)
  $ hcxdumptool -i INTERFACENAME -w dumpfile.pcapng -F --rds=1
   i     : name of the interface to be used
   w     : name of file to which packets are written
   F     : use all available channels
   rds=1 : sort real time display by status (last PMKID/EAPOL on top)
press ctrl+c to terminate
press GPIO button to terminate
 hardware modification is necessary, read more:
 https://github.com/ZerBea/hcxdumptool/tree/master/docs
to store entire traffic, run tshark in parallel on the same interface:
 $ tshark -i <interface> -w allframes.pcapng

Berkeley Packet Filter:
-----------------------
tcpdump decimal numper format:
 example: tcpdump high level compiler:
  $ tcpdump -s 1024 -y IEEE802_11_RADIO wlan addr3 112233445566 -ddd > filter.bpf
  see man pcap-filter
 example: bpf_asm low level compiler
  $ bpf_asm filter.asm | tr ',' '\n' > filter.bpf
  see https://www.kernel.org/doc/html/latest/networking/filter.html
 example: bpfc low level compiler:
  $ bpfc -f tcpdump -i filter.asm > filter.bpf
  see man bpfc
tcpdump C style format:
 example: tcpdump high level compiler:
  $ tcpdump -s 1024 -y IEEE802_11_RADIO wlan addr3 112233445566 -dd > filter.bpf
  see man pcap-filter
 example: bpfc low level compiler:
  $ bpfc -f C -i filter.asm > filter.bpf
  see man bpfc

Important recommendation:
-------------------------
Do not set monitor mode by third party tools or third party scripts!
Do not use virtual interfaces (monx, wlanxmon, prismx, ...)!
Do not use virtual machines or emulators!
Do not run other tools that take access to the interface in parallel (except: tshark, wireshark, tcpdump)!
Do not use tools to change the virtual MAC (like macchanger)!
Do not merge (pcapng) dump files, because this destroys assigned hash values!

But this --help doesn't seem to complete either.

[strasharo]

try -h instead

[ZerBea]

First of all, I see several questions, but not an issue report. So I'm going to move this report to discussions.

As you noticed, hcxdumptool has been refactored since version 6.3.0. I did this due to performance reasons.
This reasons are detailed explained in the changelog:
https://github.com/ZerBea/hcxdumptool/blob/master/changelog

and in the git discussion section, e.g.:
#348
#503
#343

the latest git version seems broken. It will get stuck at starting...
No, it isn't. Due to performance reasons (e.g. running headless on a Raspberry Pi Zero) the real time display is disabled by default:

--rds=<digit>    : enable real time display
                    attack mode:
                     0 = off(default)
                     1 = show APs on current channel, show CLIENTs (M1M2ROGUE)
                     2 = show all APs (M1M2, M1M2M3 or PMKID), show CLIENTs (M1M2ROGUE)
                     3 = show all APs, show CLIENTs (M1M2ROGUE)
                     columns:
                      E = encryption (e)ncrypted / (o)pen
                      A = AKM (p)re-shared key
                      1 = received M1
                      2 = received M1M2
                      3 = received M1M2M3
                      P = received PMKID
                    rcascan mode
                     0 = show APs on current channel sorted by BEACON timestamp
                     1 = show APs on current channel sorted by PROBERESPONSE timestamp
                     2 = show APs on current channel sorted by RSSI
                     3 = show APs of all channels sorted by RSSI
--rdt            : disable TIOCGWINSZ for real time displays

BTW:
By latest commit aI added an information to --help that there is another menu (-h):

$ hcxdumptool --help
hcxdumptool 6.3.5-149-g935b518  (C) 2025 ZeroBeat
Additional information (for commonly used options use -h):
----------------------------------------------------------
...

BTW2:
You mentioned that you're running a Raspberry3+. I suggest to give OpenWRT 24.10 a try

[fa1rid]

I don’t know what to say, but this tool has the potential to be much better than it currently is. Some aspects are improving, while others seem to be getting worse.

The usage is confusing, switches and syntax keep changing frequently. Can we settle on something stable and robust? I really love this tool, and I wish it didn’t have these unnecessary annoyances, which feel entirely avoidable.

For example, I strongly think --help and -h should be merged, or at least there should be a clear message indicating that they serve different purposes. The new line, "Additional information (for commonly used options use -h):", isn’t eye-catching for someone who just wants to get things running quickly.

There’s also a lack of important features, such as displaying signal strength during operation. Some tool switches and parameters are unclear, for instance, the --rds= option doesn’t clearly explain the differences between values like 0, 1, 2, and 3 due to awkward phrasing. It’s not even obvious whether column customization is possible.

I tried using bpfc, but it didn’t work. Could you verify if it’s functioning correctly?
I ran:
hcxdumptool --bpfc="wlan addr1 <myMACaddress>" > attack.bpf
Then attempted to use it with:
--bpf=attack.bpf
But no networks were being attacked, the list remained empty. Removing --bpf made the network reappear in the list.

I also remember there used to be an option to test injection. Has that been removed?
Additionally, the README.md should document major changes from the past few years. It's getting unnecessarily lengthy.

There are certain features in aircrack-ng that I find more intuitive.

Please take my notes constructively, I genuinely want this tool to be the best out there. If you’re facing challenges maintaining it, I’d love to hear about them.

Any reasons about suggesting OpenWRT 24.10?

Finally, thank you for all the hard work you’ve put into this tool despite its current issues. I really appreciate your efforts.

---

Edit:
After some searching I found that addr is the issue.

addr1 = Receiver (could be client or AP)
addr2 = Transmitter (could be client or AP)
addr3 = Destination (usually AP if frame is from client)

so putting wlan addr3 makes it appear now. However how can I make it work with essidlist?

[fa1rid]

In the list display the column EA123P shows ep which is unclear, it used to show + instead for each column inside it.
For --essidlist is there documentation on how to use it and what does it do? I assume it takes list of ESSIDs line be line, and create fake APs for them? Or it will only attack those ESSIDs?

[ZerBea]

In the list display the column EA123P shows ep which is unclear
The columns (explained in -h)::

• E = encryption (e)ncrypted / (o)pen
• A = AKM (p)re-shared key
• 1 = received M1
• 2 = received M1M2
• 3 = received M1M2M3
• P = received PMKID

You're right, it is unclear due to missing information. I pushed an update, because possible values for columns 1,2,3, and P are missing.
columns:

• E = encryption (e)ncrypted / (o)pen
• A = AKM (p)re-shared key
• 1 = received M1 (+)
• 2 = received M1M2 (+)
• 3 = received M1M2M3 (+)
• P = received PMKID (+)

EAP123P
------------
ep

e = NETWORK is encrypted (possible values (e)ncrypted / (o)pen)
p = AUTHENTICATION MANAGEMENT SYSTEM (AKM) in use is pre-shared-key (possible values (p)re-shared key), hashcat or JtR can work on.

For --essidlist is there documentation on how to use it and what does it do?
It doesn't really create a fake AP.

Once a PROBEREQUEST that contains an ESSID has been received, hcxdumptool send a PROBERESPONSE using the ESSID of this PROBEREQUEST. Additional it adds this ESSID to the essidlist.
Once a PROBEREQUEST that contains a wildcard ESSID (empty ESSID) has been received, hcxdumptool send a PROBERESPONSE using an ESSID of this essidlist.

Than it waits fo an AUTHENTICATION request of the CLIENT.

[fa1rid]

So how to create fake AP for specific ESSID only?

[ZerBea]

That highly depends on the behavior of CLIENT (sends PROBEREQUESTs containing wildcard ESSIDs only, running MAC randomization, ...)

Add ESSID to essidlist in case CLIENT sends wildcard PROBEREQUESTs only.
Create a BPF (add BROADCAST MAC and at least one target MAC) which allows hcxdumptool to respond to the CLIENT requests (PROBEREQUEST, AUTHENTICATIONREQUEST, ASSOCIATIONREQUEST, REASSOCIATIONREQUEST).
That only works is the CLIENT does not use MAC randomization)
run hcxdumptool with options

-c 11 (for a fixed channel - the CLIENT will find hcxdumptool)
--essidlist (containing target ESSID)
--bpf (Berkeley packet filter containing the target MAC(s)
--rds=x (x = 1,2, or 3 to enable realtime display)

as explained here:
#493
or in the adapter test section:
#361 (comment)
or here (downgrade attack WPA3 -> WPA2)
#485

[ZerBea]

If the CLIENT uses MAC randomization, you need a different approach.
Due to MAC randomization you can't use a BPF.

An example (as of now) - my target CLIENT is running full MAC randomization!

$ echo "test-network -" > essidlist

$ sudo hcxdumptool --essidlist=essidlist --rds=1 -c 1a --associationmax=0 --disable_disassociation --m2max=100 -w test.pcapng
 wait until CLIENT send its EAPOL M2

CHA|  LAST  |EA123P|   MAC-CL   |   MAC-AP   |ESSID          (SCAN:  2412/1)
---+--------+------+------------+------------+--------------------------------
  1|16:44:15|ep++  |62cf83e4cd55|dc7014045838|test-network -
  1|16:44:14|ep++  |be886bc73444|dc7014045838|test-network -

$ hcxpcapngtool test.pcapng -o test.22000
hcxpcapngtool 6.3.5-78-gd9f2a8d reading from test.pcapng...

summary capture file
--------------------
file name................................: test.pcapng
version (pcapng).........................: 1.0
operating system.........................: Linux 6.12.37-1-lts
application..............................: hcxdumptool 6.3.5-149-g935b518
interface name...........................: wlp48s0f4u2u1
interface vendor.........................: 74da38
openSSL version..........................: 1.1
weak candidate...........................: 12345678
MAC ACCESS POINT.........................: dc7014045838 (incremented on every new client)
MAC CLIENT...............................: e804109c23db
REPLAYCOUNT..............................: 62263
ANONCE...................................: cb54cb9d52f210617ceca5db8f230110fc74f1538ad5fc7dc5e605070bad28d7
SNONCE...................................: 00a70e89791136620eec1b9c481a7dcce3c991c3c69ab6f8e9eac214aa8bbd25
timestamp minimum (timestamp)............: 12.07.2025 14:43:07 (1752331387)
timestamp maximum (timestamp)............: 12.07.2025 14:44:15 (1752331455)
duration of the dump tool (minutes)......: 1
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11_RADIO (127)
endianness (capture system)..............: little endian
packets inside...........................: 27
packets received on 2.4 GHz..............: 25
ESSID (total unique).....................: 13
BEACON (total)...........................: 8
BEACON on 2.4 GHz channel (from IE_TAG)..: 1 
PROBEREQUEST (undirected)................: 1
PROBEREQUEST (directed)..................: 1
PROBERESPONSE (total)....................: 9
AUTHENTICATION (total)...................: 2
AUTHENTICATION (OPEN SYSTEM).............: 2
ASSOCIATIONREQUEST (total)...............: 2
ASSOCIATIONREQUEST (PSK).................: 2
EAPOL messages (total)...................: 4
EAPOL RSN messages.......................: 4
EAPOL ANONCE error corrections (NC)......: not detected
EAPOL M1 messages (total)................: 2
EAPOL M2 messages (total)................: 2
EAPOL pairs (total)......................: 2
EAPOL pairs (best).......................: 2
EAPOL ROGUE pairs........................: 2
EAPOL pairs written to 22000 hash file...: 2 (RC checked)
EAPOL M12E2 (challenge - ANONCE from M1).: 2

frequency statistics from radiotap header (frequency: received packets)
-----------------------------------------------------------------------
 2412: 25	

Information: missing EAPOL M3 frames!
This dump file does not contain EAPOL M3 frames (possible packet loss).
It strongly recommended to recapture the traffic or to use --all option to convert all possible EAPOL MESSAGE PAIRs.

session summary
---------------
processed pcapng files................: 1

$ wget https://wpa-sec.stanev.org/dict/cracked.txt.gz

$ hashcat -m 22000 test.22000 cracked.txt.gz
hashcat (v6.2.6-997-g4b93a6e93) starting
...
CUDA API (CUDA 12.9)
====================
* Device #01: NVIDIA GeForce RTX 4080, 15698/15943 MB, 76MCU

OpenCL API (OpenCL 3.0 CUDA 12.9.90) - Platform #1 [NVIDIA Corporation]
=======================================================================
* Device #02: NVIDIA GeForce RTX 4080, skipped

Minimum password length supported by kernel: 8
Maximum password length supported by kernel: 63

Hashes: 2 digests; 2 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Optimizers applied:
* Zero-Byte
* Single-Salt
* Slow-Hash-SIMD-LOOP

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 1459 MB

Dictionary cache built:
* Filename..: cracked.txt.gz
* Passwords.: 682912
* Bytes.....: 7626925
* Keyspace..: 682912
* Runtime...: 0 secs

45a4855c7b6e48c2df9d819afedb2fbc:dc7014045838:62cf83e4cd55:test-network -:12345678
c0a9aa2b3630ee2e55d54431bc9c7748:dc7014045838:be886bc73444:test-network -:12345678
                                                          
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: test.22000
Time.Started.....: Sat Jul 12 16:50:26 2025 (0 secs)
Time.Estimated...: Sat Jul 12 16:50:26 2025 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (cracked.txt.gz)
Guess.Queue......: 1/1 (100.00%)
Speed.#01........:  1482.9 kH/s (5.94ms) @ Accel:16 Loops:128 Thr:256 Vec:1
Recovered........: 2/2 (100.00%) Digests (total), 2/2 (100.00%) Digests (new)
Progress.........: 311307/682912 (45.59%)
Rejected.........: 11/311307 (0.00%)
Restore.Point....: 0/682912 (0.00%)
Restore.Sub.#01..: Salt:0 Amplifier:0-1 Iteration:1-3
Candidate.Engine.: Device Generator
Candidates.#01...: 12345678 -> 43702848
Hardware.Mon.#01.: Temp: 40c Fan:  0% Util:  3% Core:2505MHz Mem:10801MHz Bus:16

Started: Sat Jul 12 16:50:25 2025
Stopped: Sat Jul 12 16:50:28 2025

That's all.

[fa1rid]

So can you please tell me what's the command to do the following:
I have two target WiFi networks 2G & 5G.

Router_2G (CH 1) 00:00:00:00:00:01
Router_5G (CH 100) 00:00:00:00:00:02

Let's say I have one adapter that supports 2G only.
I want to target Router_2G on CH 1, as well as create fake AP for Router_5G.

So I currently I do this:

hcxdumptool --bpfc="wlan addr1 000000000001 or wlan addr3 000000000001" > attack.bpf
hcxdumptool -i wlan1 -c 1a --rds=2 --bpf=attack.bpf -w capture.pcapng

So how to modify the above commands to create fake AP for Router_5G (assuming the CLIENT uses MAC randomization)?

How likely the client will prefer to connect to our fake 2G AP pretending to be 5G over the real 5G AP?

[ZerBea]

Back to your example. Let's say in one of the CLIENTs wpa-supplicant.conf is also an entry "Router_6G".
Running method 2, you will get this M2 too.

[fa1rid]

So you mean it's not possible to do what I asked with attack filter, it has to be protect filter, right? And I should add the essid list also?

[fa1rid]

My problem now that if I run it without attack filter, it's creating a lof of fake APs of so many random ESSIDs the whole day non-stop, how to stop it from doing that?

[ZerBea]

It is possible with an attack filter (as you use it right now), too.
Router_2G (CH 1) 00:00:00:00:00:01
Router_5G (CH 100) 00:00:00:00:00:02
$ hcxdumptool --bpfc="wlan addr1 000000000001 or wlan addr3 000000000002"

In this case hcxdumptool only responds to directed PROBEREQUESTs and it responds to frames addressed to the MACs in the BPF.

• Undirected PROBEREQUESTs are ignored.
• PROBEREQUESTs to wildcard ESSID are ignored.
• All requests to other MACs are ignored.

Unfortunately an attack filter can't handle unknown stations, wildcard ESSIDs or randomized MACs.
That is only possible running a filter that exclude all unwanted MACs.

But let me think about a solution that limits the entries of the internal ESSIDs list by an option.

[ZerBea]

Adding a soft coded ESSID filter (yet an additional ring buffer, we have to walk through) does not make sense.
It slows down hcxdumptool and prevents that hcxdumptool can't respond just in time any longer.
Only the way via BPF (attack filter if you know all target MACs / or protect filter to eliminated all unwanted if you don't know the target MACs) is fast enough. It does not slow down hcxdumptool.

[ZerBea]

Conclusion:
Mac randomization ensures the safety and privacy of your devices on public or shared Wi-Fi networks.
Unfortunately this mechanism prevents to use an attack filter, because we do not know the MAC address against we can run an attack.
If the MAC is not inside the attack filter, hcxdumptool does not respond to this CLIENT.

To handle such CLIENTs,

• either do not use an attack BPF or
• use a protect BPF (when you have eliminated the unwanted/known MACs, whatever remains, could be the targeted MACs).

[fa1rid]

My goal is to create a fake AP and whatever client connects to it should work without filter. I think this tools doesn't support this feature, right?

[ZerBea]

You are absolutely right, I wrote this before:
#518 (reply in thread)
"It doesn't really create a fake AP."
That means:

• it doesn't transmit a BEACON
• it doesn't' ACK frames in monitor mode
• layer 2 frames only

hcxdumptool is designed to run attacks on week CLIENTs and some (old) school attack on APs as well as a PMKID attack.
These are layer 2 attacks only.
https://www.geeksforgeeks.org/computer-networks/open-systems-interconnection-model-osi/

You need a patched hostap running in AP mode - not an attack tool running in monitor mode.
https://w1.fi/hostapd/

[fa1rid]

Maybe you didn't fully get me. What I meant is that I can see hcxdumptool creating the fake APs while it's working, but it doesn't keep them always broadcasting, it just kinda rotate between them. What I meant by fake AP is just for the purpose of capturing handshakes, not to let clients stay connected there. You got me?

[ZerBea]

To make it more clear:
hcxdumptool does not broadcast frames like BEACONs.

It only responds on CLIENT PROBEREQUESTs. That is the starting point to get an M2 from the CLINET
https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/802.11_Association_Process_Explained

Unfortunately nearly all up to date CLIENTs use MAC randomization. As a result you can't filter them by an attack filter because you don't know the MAC to be filtered. If you do not respond to this PROBEREQUEST the CLIENT leaves the channel.

Unfortunately most of the CLIENTs run a wildcard ESSID so that you don't know the ESSID. If you do not respond to this PROBEREQUEST the CLIENT leaves the channel.

Attached an exam
PROBEREQUEST.pcapng.zip
ple:

hcxdumptool must(!) respond to this!

MAC is randomized

$ whoismac -m e6c2bd
VENDOR: unknown (LAA - likely randomized!), unicast

BSSID is BROADCAST MAC
ff:ff:ff:ff:ff:ff:

ESSID is wildcard.
Tag: SSID parameter set: Wildcard SSID

That is not possible via attack filter. You need a protection filter that eliminates all unwanted stations from this channel!

To runt through an entire ASSOCIATION process it is mandatory to respond to:
CLIENT PROBEREQUEST - regardless if the MAC is randomized, a BROADCASMAC is used or a WILDCARD ESSID is used
CLIENT AUTHENTICATIONCLIENT ASSOCIATIONREQUEST

Filtering via attack filter is absolutely easy, if:
CLIENT does not use MAC randomization. In that case you can run an attack filter containing all expected MACs.
Exactly that is prevented by the manufacturers

An example:
((wlan addr1 MAC_AP or wlan addr2 MAC_AP or wlan addr3 MAC_AP or wlan addr1 MAC_CLIENT or wlan addr2 MAC_CLIENT or wlan addr3 CLIENT) or (wlan addr2 MAC_CLIENT and wlan addr3 ffffffffffff))
This "(wlan addr2 MAC_CLIENT and wlan addr3 ffffffffffff)" eliminates other CLIENTs
It only works if the CLIENT use its real MAC!

I suggest to play around with the FILTER codes until you get the expected result.

[oayz-git]

Hi Mike, thanks for making "rds" section of help cleaner (the one in the head of this thread is outdated). I think it's worth to mention that default=0

I have a some RDS related suggestion in no particular order, maybe you would agree to entertain some:

1. Add sorting by SSID option
2. Filter out by min RSSI (too many remote APs garble the screen and slows down)
3. Sort by RSSI option

[ZerBea]

Let me think about it, how to add this new sorting options.
But be warned. They will have a huge performance impact.

[oayz-git]

NP, if we state this in help. But an you help me to understand why? Text sorting of 50 names, most are shorter than 16 chars.

[ZerBea]

Some of your requests have allready been added to hcxdumptool, if it is running in rca scan mode. In this mode, we can ignore performance impacts, because we do not interact with targets.

But when running in attack mode, we don't have the time to do such sortings. Priority is to receive all packets transmitted by the target(s) and tl respond just in time to the requests of the target(s).
We can't do both (respond to target and beautiful status display with several sorting options) at the same time and end up in a packet loss.

That's the major reason why the status display is disabled by default. If you enable it, you accept a packet loss and you accept that hcxdumptool can't respond in time.

[oayz-git]

Right, I know I'm not the first one asking for it :-) It's just sometimes when in attack mode it's good to know what the heck is going on. So how about screen update on keypress?

[ZerBea]

Sorting by ESSID seems to be possible without huge perfomance impact.
Sorting by RSSI need a tag walk through the radiotap header. A performance impact is very likely.
Monitoring the keyboard will cost cpu cycles and a performance impact is very likely too.

During the next two weeks I'm not at home. When I'm back, I'll do some tests. If the impact is small, I'll publish it.

[oayz-git]

As a compromise, sorting/filtering by RSSI can be done once, at program launch.  I'm not Linux expert but I don't think polling keyboard takes lots of cycles. Actually I'm sure there should be a callback which will interrupt your program only when key is pressed.  Couple more things to fill your queue :-) 1. With RDS=0 last message is "starting.." which is kind of confusing. 2. In RDS=0 can you print print something nice every time handshake is captured? I think it's worth few CPU cycles All these is cosmetics, low priority. Thanks for providing great tools to the community! On Wednesday, October 8, 2025 at 01:18:18 PM PDT, Mike ***@***.***> wrote: Sorting by ESSID seems to be possible without huge perfomance impact. Sorting by RSSI need a tag walk through the radiotap header. A performance impact is very likely. Monitoring the keyboard will cost cpu cycles and a performance impact is very likely too. During the next two weeks I'm not at home. When I'm back, I'll do some tests. If the impact is small, I'll publish it. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[ZerBea]

Do you mean a rds option that print a waterfall status e.g

time - channel - mac ap - mac client - essid - handshake/pmkid captured

I'll give it a try, as long as we don't loose packets.

Polling the keyboard is no prpblem, but sorting an internal list after a key stroke is.
I'm not a friend doing this. Fortunately it is not necessary when running s waterfall display.

BTW:
Interrupting hcxduptool is always possible by ctrl÷c or sending sigterm.

[oayz-git]

Yes, the line you've suggested is fine. I don't think handshake capture happens so often that loosing packets become a concern. Anyway, could be another RDS option

My keyboard suggestion was to show RDS=N screen (is it what you call it waterfall?) on keyboard press instead of current continuous update. This is again an attempt to strike the balance between "I want to see" and "I want all packets". Basically you run RDS=0 unless keyboard is pressed, than run RDS=N for one screen update and go back to RDS=0

If the above makes sense to you, we can encode all in RDS=ikh (i=current 0..3, k is on keyboard, h is on handshake)

[ZerBea]

No. rds=0 is do absolutely nothing Neither keyboard poll nor slow sorting code nor slow printf.
Everything else need an additional option switch.

I suggest to take a look at the pcapng file by wire shark. 100 times a received handshake means 100 times the display will be updated and sorted if we do it your way.
If you press a key while no handshake has been received at this moment, the status display will show nothing.

Also please take a look at the rssi values. They change very often. I don't want to collect and sort this absolutely useless values.
100 times the rssi changes means 100 times the display will be updated and sorted if we do it your way.

If you press a key while rssi is low at this moment, you'll see nothing if we do it your way.

rssi is a "one way value" which depends on vendor.
For a successfull attack it is mandatory that the target receive us.

All this has nothing to do with Linux. Some options are just not working as you expect it.

Every new option need code that formats the incoming packets
Every algo that is doing this need cpu cycles.
While hcxdumptool formats and print the beautiful status, packets get lost.

An example:
A handshake has been received.
Now hcxdumptool has to go back in history to check if it has allready been shown.
100 handshakes have been received.
Now hcxdumptool has to go back in history to check if they have been allready shown.

You press a key and hcxdumtool has to go back in history to collect all values.

Is that really what you want?

[ZerBea]

To make it more clear:
Each option need an additional internal buffer (list) that collect the information.
On every action, all values of this buffer have to be evaluated and the buffer has to be sorted.

Hcxdumptool does not know when the user press a key.
To satisfy the user. it must do the procedures mentioned above all the time in background.

[oayz-git]

rds=0 is do absolutely nothing ... Everything else need an additional option switch
Sure

100 times a received handshake means 100 times the display will be updated and sorted if we do it your way
My fault, wrong name. I've meant captured valid PKMID or EAPOL (e.g. WPA01 / WPA02 can be generated). IMHO it's a relatively rare but important event most users want to be notified about. Similar to HashCat is printing password when one cracked

Every new option need code that formats the incoming packets
That's why I'm trying to strike balance - no effect on performance most of time, only on important events (see above) or direct user request (keyboard).

To satisfy the user. it must do the procedures mentioned above all the time in background.
IMHO, 1-2% of dropped packets is accepted for improved UX but goal is zero

each option need an additional internal buffer (list) that collect the information.
OK, but circular buffer to store packet data doesn't take much MIPS. Just to make it clear - target is modern multicore PC, not a headless Berry

On every action, all values of this buffer have to be evaluated and the buffer has to be sorted.
No, buffer processing should only be done on the keyboard press

Regarding RSSI - you're right, signal quality is better qualifier but heck - everyone is using RSSI. I'm OK to drop if it takes MIPS, if not - use sliding average (two MULT, one ADD) to avoid fluctuations

Just curious - is one parameter packet sorting takes more than 1% of packer capture/decoding time? Say on 2GHz, 4-core Intel.

[ZerBea]

An interface running in monitor mode receive thr entire traffic on a xhannel. Every incoming packet has to be handled, stored and srored in a buffer.
The buffer has to be sorted after a new packet has been received.
Open wire shark.
Set a crowded channel.
Start capturing and dump the packets to a file.
Soon you reach sizes of 1GB or more.
Now imagine that this packet are stored in a buffer that has to be sorted on every new incoming packet (thousand timed aminute)
I don't think your 4 core can handle it.

Run hcxduptool on a crowded channel awhile.
Terminate it and check the stats. Do you have a packet loss?
Set next rds mode and do the same procedure. Do you see a packet loss?

If yes, your 4 core us not able to handle even this optimized rds modes.

When I'm back home I add some mote modes. I'm sure the oacket loss increases.

[ZerBea]

https://unix.stackexchange.com/questions/144794/why-would-the-kernel-drop-packets

[oayz-git]

We're going in circles :-( Let's don't talk about peak load - I don't need to use shark, I can calculate theoretical data rate. And we need to decide if this will be for 20/40/80/160Mhz single or multi-channel. Heck, with WiFi7 we can get 46Gbps!

Let's review:

Proposal 1. Add new RDS mode, modification of RDS=1,2,3. "waterfall" is updated only on the valid EAPOL/PMKID capture (+ in columns 23P). Persistent (add, not erase). Assumption is that this will have much less packet drop than normal RDS=1,2,3

Proposal 2. In RDS=0 on each packet check for keyboard. If key is pressed switch to RDS=1,2,3 for X seconds, when go back to RDS=0. Assumption is that keyboard check doesn't increase packet drop

I understand that only RDS=0 guarantees minimum packet drop since minimum processing of the packets and they simply dump to PCAP. Currently I have to run hcxpcapngtool on PCAP once in a while to see if EAPOL/PMKID is captured

Please let me know if I still missing something. You can clearly see I'm not and expert

[ZerBea]

I'll add a new mode when I'm back home.

BTW:
We are not talking about data rates. And we are not talking about peak loads.
We are are talking about the kernel internal packet ring buffer.

In case of a managed interface it has to handle this traffic only.
In case of monitor mode it has to handle everything on the operating channel and 3 overlapped channels below and 3 channels above.

Does hcxdumptool report by kernel dropped packets?
If yes, your system reached its limit.

[ZerBea]

"I can calculate theoretical data rate. And we need to decide if this will be for 20/40/80/160Mhz single or multi-channel. Heck, with WiFi7 we can get 46Gbps!"

I'm very interested in how to calculate this data rates of an interface running in monitor mode and the utilization of its ring buffer?

BTW:
hcxdumptool sets the interface to lowest possible rate and to smallest band width.
You can use iw to verify this.

[ZerBea]

Maybe this exxplains it a way better:
Normally, a NIC works in managed mode. In managed mode, a network card will only manage traffic with the addressed Mac.

When your wireless network interface is in monitor mode, it will pass all the incoming packets to the CPU.
From now on hcxdumptool It is responsible for ensuring that all packages are read and handled (evaluate incoming packet, build a response packet, send the respose packet to the raw socket) just in time.
If it is not able to read the packets from this buffer just in time (e.g because it is sorting a list), the kernel drops packets.
If the response packet is not transmitted just in time, the target ignore it

[oayz-git]

Hi Mike, thanks for taking time explaining. It's Sunday so this will be quick, more details later

Data rate. I was talking about full channel capacity, the absolute worst case:
https://www.qorvo.com/resources/d/qorvo-wifi-data-rates-channels-capacity-white-paper

Running one channel with RDS=0 and bo BPF on my ancient HP Presario CQ62: 86130 packets, 1801 dropped (2%)

[ZerBea]

Ok, thanks for the information.

We definitely talk past each other.
You are talking about data rates on managed interfaces
I'm talking about monitor mode and packet injection.

In managed mode everything is handled by the interface. Packets which are not addressed to the MAC are ignored.
The interface respond to the sending station.

In monitor mode all packets must be handled by the cpu!

On every packet:
evaluate radiotap header
evaluate MAC header
evaluate payload
evaluate headers inside the payload like EAP header
evaluate headers inside the EAP header like EAPOL
Evaluate data inside the EAPOL header to get e.g the PMKID

build a response packet
send the response packet

While hcxdumptool is doing this, it is not able to sort lists or to print a status.

While hcxduptool sort a list or print a status, it is not able to evaluate incoming packets.

[ZerBea]

1801 dropped packets is not too much and we can ignore it if we have received 1000000 packets.

But 1801 dropped packets on only 86130 received packets is huge!

This is a good reason not to touch rds 0, e.g if a user is running a Raspberry Pi Zero.

Maybe we can decrease dropped packets with the new mode.
The water fall display print e.g the PMKID as soon as it has been received.
If the AP transmit e.g. 100 PMKIDs, the water fall spams the display.
If AP and CLIENT exchange 100 handshakes, the water fall spams the display.
That is the price we have to pay, because I don't want to add a new list that holds this information.
Walking through such a list to evaluate the entries and sorting it on every new handshake is out of scope due to a huge performance impact.

I'm sure that the rates mentioned in the PDF are far away from the rates in monitor mode. You might have noticed that too, or do you still think that your 4 core can handle 46Gbps incomming RAW data when runnin monitor mode.

[ZerBea]

Just to mention it for other users:
Running an essential OpenWRT (only mandatory tools compiled in and absolutely no unnecesssry servkce started) and hcxlabtool (headless, BPF and no status display) on a Raspberry Pi Zero connected to a TL-WN822N, I get 0 (zero) dropped packets, regardless how many packets have been received. That is the/my reference.

[ZerBea]

We're going in circles :-( Let's don't talk about peak load - I don't need to use shark, I can calculate theoretical data rate. And we need to decide if this will be for 20/40/80/160Mhz single or multi-channel. Heck, with WiFi7 we can get 46Gbps!

It's a pity that you don't want to use shark.
I suggest to do it and to take a look at the real data rate in the radiotap header.
The kernel starts to drop packets even if it is processing incoming raw packets (at the lowest possible data rate) because your cpu is too busy to handle them.
And that's no peak load. Every AP on the channel transmits 10 beacons on each second.
hcxdumptool must process every single beacon (walking through all headers of the beacon) every time. You can calculate and multiply the cpu cycles yourself.
If not, I can add some real mesurements here, when I'm back home.

[ZerBea]

While hcxduptool print a status message it can''t read incoming packets from the kernel packet buffer.
Sooner or later (mostly sooner) the buffer is full and packets are overwritten.

[ZerBea]

BTW, I think it's worth to mention in help that RDS>0 will drastically affect performance and should not be used until absolutely required.

That depend on how many tasks are allready running on the cpu.
Use btop, htop or top to identify them.

If you are runnig hcxdumptool on a system like KALI or Ubuntu, the impact is different to e.g. OpenWRT or Arch Linux.
If a system is configured as multimedia system and you are running a beautiful status display, the impact is huge.
On a minimal system the impact i small.

BTW:
If a user knows what he is doing, there is absolutely no need to run a status display.
Unfortunaley most of the users prefere this display.

[oayz-git]

While hcxduptool print a status message it can''t read incoming packets from the kernel packet buffer.
Msg is only on important event. How often do you think we are getting valid EAPOL/PKMID? If too often may be don't print msg on repetitions? Can we get msg print in another thread?

Anyway, this is just a cosmetics and I feel sorry you have to spend so much of your valuable time on me. Thanks for accepting this request !

[ZerBea]

I'll do some measurement, than we see what we can add,

[oayz-git]

Upgraded from HP Presario CQ62 ((2.2GHz Intel Celeron, 1 core, 900MHz, ) to Lenovo ThinkPad W530 (Intel i7-3840QM, 4cores/8threads, 2.80GHz, 3.8MHz turbo)

CQ62: 86130 packets, 1801 dropped (2%)
W530: 81761 packets, 211 dropped (0.26%)

So fast processor helps a lot but still Linux can't get close OpenWRT.

BTW, I'm running Parrot, not KALI

[ZerBea]

Glad to hear this.

BTW:
OpenWRT is 100% Linux. I'm running a self compiled essential build. Leave out everything superfluous.
All other systems are running Arch Linux (manually installed), Leave out everything superfluous.

Like KALI, Parrot is a Debian clone too. Both have in common that many unnecessary programs are installed and started as daemons/services by default (especially if you use the GUI installer). It is absolutely mandatory to configure Debian (and its clones) by hand after installation.

[oayz-git]

Thanks for the guidance! I'm windows guy, for me whole Linux is superfluous :-) Spent 2 days trying to figure out how to downgrade included in Parrot libcurl to the one your tool was asking to compile. It's happened my wasn't even debian (-deb), it was from some other Linux but version was 8x while your is 7x (sorry, no detail, I'm on the Win PC but you are well familiar with this issues, I've seen several threads on the topic).

[ZerBea]

I'm coding hcxtools an hcxdumptool/hcxlabtool running a rolling release distribution (Arch and OpenWRT git).
The difference between a fixed(like Debian) and a rolling release distribution(like Arch) is explained here:
https://www.geeksforgeeks.org/linux-unix/rolling-vs-fixed-release-linux-distros/

As long as you stay inside the distribution and use its package manager everything is fine. But if you decide to compile additional tools, you'll end-up in a dependency hell, because theby the distribution provided packages often lag behind the current versions and might be outdated.

[oayz-git]

Rolling Release Distros ... are extremely popular among Linux veterans (not me) who are familiar with using Linux (not me) and are not afraid of tinkering (me!)

Anyway, I did install ArchLinux and hcxdumptool tool there is old 6.3.5. I used archinstall script and picked HDT and hcxtools from the list of additional packages. Seems like still need to fetch latest from the git and recompile. Or may be I didn't do things right

L8R and as usual - thanks for heads up, appreciated!

[v74863]

If you want to play with hcxdumptool on your laptop, it is not mandatory to install Linux. Just download iso-file from https://archlinux.org/download/ and boot it using Ventoy https://www.ventoy.net/

[oayz-git]

Thanks, this is exactly how I install both Parrot and Arch (tried KALI too). The problem with running Live ISO - hard if possible to upgrade/compile any packages or apps. Both Parrot and Arch have older ZerBea's tools pre-installed

[ZerBea]

Arch:

Current Release: 2025.10.01
Included Kernel: 6.16.8
ISO Size: 1.4 GB

https://archlinux.org/download/

Debian and clones:

amd64/iso-cd/debian-13.1.0-amd64-netinst.iso
[debian-13.1.0-amd64-netinst.iso](https://cdim
2025-09-06 14:34 	783M

https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/

OpenWRT (inclusive latest hcxdumptool & latest hcxlabtool):

openwrt-bcm27xx-bcm2708-rpi-ext4-factory.img.img.gz
5. Okt 13:56
66M 

https://openwrt.org/docs/guide-developer/toolchain/start
#478 (reply in thread)

[oayz-git]

Mike, here is ArchLinux setup. I got it on Friday, it's newer than yours, yet as you can your tools are still 6.3.5, not 7.0.2:

ArchLinux is naked, no multithreading, no UI. Doesn't even automount USB or do screenshot. I guess I have two options:

1. Clean up ParrotOS from unnecessary stuff
2. Add unnecessary stuff to Arch or OpenWRT
   I wonder if end results will be the same :-)

BTW, I afraid this Linux shouldn't be discussed in this thread, care to move it somewhere?

[ZerBea]

hcxdumptool and hcxtools are already flagged out:
https://archlinux.org/packages/extra/x86_64/hcxdumptool/
https://archlinux.org/packages/extra/x86_64/hcxtools/

Major difference between the three distributions:
Parrot:

• fixed release
• no development packages (header files) included by default
• mostly outdated packages

Arch Linux:

• rolling release (pacman -Syu does an update to latest versions)
• development packages (header files) included by default
• mostly no outdate packages
• excellent WiKi in 31 languages

OpenWRT:

• designed to run (headless) on a router (slow CPU and less RAM)
• fixed release
• no development packages (header files) included by default
• older Linux Kernel

Every distribution has its advantages and disadvantages.
I prefer to use Arch (xfce4 desktop & lxdm display manager & systemd-boot & latest stable and latest lts kernel) on my notebook and my desktop and OpenWRT on my Raspberry Pi Zero.
You'll learn a lot about Linux internals if you install and configure Arch Linx. The same applies to OpenWRT, compiled and configured via toolchain.

[oayz-git]

[oayz-git]

Well, this Intel adapter never was a problem but just in case - this is well respected RaLink with dual 3db antennas. It's got more packets (500k in an hour), more dropped ones than intel (900 over 3x less time) and it bombed with WDT:

[oayz-git]

Do you think there are hidden errors which can only be seen in hcxdumptool debug mode? As I mentioned earlier if I start hcxdumptool with "-m" first and then run capture no errors are reported.

[ZerBea]

Packet drops increase, because the other adapter receives more packets, but the CPU is too buys to handle them,

In normal mode, hcxdumptool only counts WRRORs.
In debug mode, it prints the detailed ERROR messages as received from the kernel to hcxerror.log.

[oayz-git]

But other adapter (Intel) is not in monitor mode, does it matter? It's "disconnected" and I can try to disable it (Google or you can teach me)

I guess no point for DEBUG if I'm getting errors no more. Any idea why watchdog? This is 1st time I see something like this

[ZerBea]

If the adapter does not receive packet over a period of 10 minutes the watchdog terminates hcxdumptool.
possible reasons:

• adapter failed (e.g. thermal problems
• broken USB connection
• broken antenna connection
• driver killed
• too restrict BPF (all incoming packets are filtered out)

[ZerBea]

Added new status display (rds=4).

changelog:

05.11.2025
==========
hcxdumptool: added waterfall status display mode (rds=4)
Wraning: Expect massive packet drops especially when running the real time display on slow CPUs

The same applies if hcxdumptool is running on a virtual interface! Even a really fast CPU can't handle this. Expect massive packet drops, especially in combination with the real time display.

[oayz-git]

Cool, just did quick try and don't see any significant effect on dropped packets, same few hundreds in the beginning, Sorry, had to crop screenshot not to show MACs:

Driver is Ralink

Two comments:

1. Screen floods when we have many successful captures. Maybe don't display if it's repeated?
2. I think my WDT is due to non-activity. Can it be that we shut down all APs on the channel since no BPF?

P.S. Typo in "Wraning: Expect massive packet drops"

[ZerBea]

Screen floods when we have many successful captures. Maybe don't display if it's repeated?

Good idea, I've added this by latest commit. And I noticed a small performance increase 0,000132s (flooded status) vs. 0.000096s (non flooded status.

I think my WDT is due to non-activity. Can it be that we shut down all APs on the channel since no BPF?

To monitor this, you can run tshark in parallel on the same interface.

Typo in "Wraning: Expect massive packet drops"

Also fixed, Thanks.