bringing back the realtime display

[g18z0n]

hello, i see you recently decided to remove the realtime status display from the dump tool.

i know that the display had a performance impact but it was really useful, i had made a wrapper that showed me a consolidated view of multiple dump processes running in parallel that depended on the status information.

again, i know it might not be best for performance but is there any way that you can bring it back? maybe an option or compilation flag for "debug purposes" ?

currently i'm using and older version but it would be a shame not to have more updates because of the realtime display feature :(

anyway thanks for your efforts on improving these amazing tool!

[ZerBea]

The real time display has not been removed: By default (e.g. running headless or inside a scipt) it is disabled by default (option rds=0)

--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

Depending on what you're looking for, either option rds=1 or rds=2 or rds=3 bring it back.

[g18z0n]

hello, i'm having a strange issue that didn't happen with the old "default" realtime display.

after several hours of not knowing what was happening with the new version i was able to isolate the issue, basically when redirecting stdout of hcxdumptool (latest git version) the process "exit on error" with this message:

"101 ERROR(s) during runtime (mostly caused by a broken driver)"

i would think this is a driver/kernel issue like the message says, but the strange thing is this only happens when redirecting stdout to a file or other type of pipe/buffer (like my wrapper script did), if redirecting stderr for example this does not happen, also with the old version with the default realtime display i can "handle" stdout/stderr output without issues and capture/pmkid works.

here is a simple shell stdout redirect test evidence with the new version:

$ sudo hcxdumptool-6.3.5-124-g5af64cc -i wlan1 -w /tmp/hcxd_wlan1.pcapng -c 1a,2a,3a,4a,5a --rds=3 --tot=6 > hcxdumptool_new_stdout.txt
BPF is unset! Make sure hcxdumptool is running in a 100% controlled environment!
...
6044 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
exit on error

101 ERROR(s) during runtime (mostly caused by a broken driver)

and here is the same command with the old version:

$ sudo hcxdumptool-6.3.5-98-g7264d09 -i wlan1 -w /tmp/hcxd_wlan1.pcapng -c 1a,2a,3a,4a,5a --rds=3 --tot=6 > hcxdumptool_old_stdout.txt
BPF is unset! Make sure hcxdumptool is running in a 100% controlled environment!
...
6101 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
156 EPB written to pcapng dumpfile

exit on TOT

1 ERROR(s) during runtime
Possible reasons:
 driver is broken
 driver is busy (misconfigured system, other services access the INTERFACE)

the '--tot=6' is placed on purpose for testing, the failed processes always exit exactly at 5.4 minutes, i assume that is the time it takes to reach the 101 Errors that trigger the exit?

finally, here is information about my system and wifi adapter, note that the tests were run on the same environment and device.

$ sudo hcxdumptool -L
available physical wlan devices:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0   4 <masked>    106fd9da60d3 * wlan0            mt7921e (NETLINK)
  4   8 <masked>    7233ec85a972 * wlan1            mt76x0u (NETLINK)
 
$ uname -a
Linux mx 6.12.17-1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 6.12-22~mx23ahs (2025-03-02) x86_64 GNU/Linux

$ lscpu            
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          48 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   16
  On-line CPU(s) list:    0-15
Vendor ID:                AuthenticAMD
  Model name:             AMD Ryzen 7 5800X3D 8-Core Processor

$ lsmod | grep mt76
mt76x0u                12288  0
mt76x0_common          49152  1 mt76x0u
mt76x02_usb            20480  1 mt76x0u
mt76_usb               49152  2 mt76x02_usb,mt76x0u
mt76x02_lib            98304  3 mt76x02_usb,mt76x0_common,mt76x0u
mt76_connac_lib        98304  3 mt792x_lib,mt7921e,mt7921_common
mt76                  143360  9 mt792x_lib,mt7921e,mt76_usb,mt76x02_lib,mt76x02_usb,mt7921_common,mt76x0_common,mt76_connac_lib,mt76x0u
mac80211             1429504  8 mt792x_lib,mt76,mt76x02_lib,mt76x02_usb,mt7921_common,mt76x0_common,mt76_connac_lib,mt76x0u
cfg80211             1323008  8 wl,mt76,mt76x02_lib,mac80211,mt76x02_usb,mt7921_common,mt76x0_common,mt76_connac_lib

$ sudo dmesg -wH
[Mar14 14:56] usb 3-6: new high-speed USB device number 6 using xhci_hcd
[  +0.143172] usb 3-6: New USB device found, idVendor=0e8d, idProduct=7610, bcdDevice= 1.00
[  +0.000007] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000004] usb 3-6: Product: WiFi
[  +0.000003] usb 3-6: Manufacturer: MediaTek
[  +0.000002] usb 3-6: SerialNumber: 1.0
[  +0.112806] usb 3-6: reset high-speed USB device number 6 using xhci_hcd
[  +0.133528] mt76x0u 3-6:1.0: ASIC revision: 76100002 MAC revision: 76502000
[  +1.194751] mt76x0u 3-6:1.0: EEPROM ver:01 fae:08
[  +0.040562] ieee80211 phy4: Selected rate control algorithm 'minstrel_ht'
[Mar14 14:58] mt76x0u 3-6:1.0 wlan1: entered promiscuous mode
[Mar14 15:04] mt76x0u 3-6:1.0 wlan1: left promiscuous mode

my usb wifi adapter is a Panda Wireless PAU0B AC600.

hope you can help me make sense of this strange issue.

if you need any other information or want me to do further tests just let me know.

as always thanks for your excelent work!

[ZerBea]

Your problem is located here:
https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L476

if(ioctl(STDOUT_FILENO, TIOCGWINSZ, &w) == -1) errorcount++;

To resize the status display depending on the display type, hcxdumptool uses a system call.
This call fails if you redirect the status to a file. Adding some debug code confirmed that.

if(ioctl(STDOUT_FILENO, TIOCGWINSZ, &w) == -1)
	{
	perror("failure: ");
	errorcount++;
	}

$ sudo ./hcxdumptool --rds=3 > test.log
BPF is unset! Make sure hcxdumptool is running in a 100% controlled environment!

ioctl system call failed: Inappropriate ioctl for device
ioctl system call failed: Inappropriate ioctl for device
ioctl system call failed: Inappropriate ioctl for device
^C
3 ERROR(s) during runtime (mostly caused by a broken driver)

[ZerBea]

A quick and dirty workaround for you is to remove the error counter:
ioctl(STDOUT_FILENO, TIOCGWINSZ, &w);
here:

hcxdumptool/hcxdumptool.c

Line 476 in 5af64cc

if(ioctl(STDOUT_FILENO, TIOCGWINSZ, &w) == -1) errorcount++;

and here:

hcxdumptool/hcxdumptool.c

Line 586 in 5af64cc

if(ioctl(STDOUT_FILENO, TIOCGWINSZ, &w) == -1) errorcount++;

Some more information is here:
https://www.man7.org/linux/man-pages/man2/TIOCGWINSZ.2const.html

[g18z0n]

it worked! commenting the last line that is the display i use on my wrapper fixed the issue.

guess i'll maintain a branch with this patch for my use case.

regards.

[ZerBea]

Added a new new switch (--rds=4) that disables TIOCGWINSZ.
Please test latest git head:

--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)
                     4 = show all APs, show CLIENTs (M1M2ROGUE)
                          disabled TIOCGWINSZ for redirect to stdout

[g18z0n]

yesterday while i was looking at the rds modes on the show_realtime() i finally understood what the rds=2 mode did, prioritizing pmkid/m2/m3, and that is exactly what i was doing on my wrapper! so i started using that mode instead of rds=3

would you mind change this rds=4 behavior more alike the rds=2, or maybe other approach you consider better for the tool.

anyway thanks for considering this new option to allow my use case!

[ZerBea]

By latest commit I added a new option (--rdt) to disable TIOCGWINSZ on all displays.
--rdt : disable TIOCGWINSZ for real time displays

e.g.:
--rds=2 --rdt

[g18z0n]

the new --rdt flag worked like a charm!

i think the description on this line is more useful to remember the purpose of --rdt on the future:
https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L5361

maybe replacing this one with that one:
https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L5373

regards.