status display tips for concurrent runs?

[g18z0n]

hello, let me start by saying your work on this tools is truly amazing and inspired me to start playing with the wifi again :)

im currently testing a raspberry pi 4b with 6 usb wifi adapters, 4 of them on a usb hub external powered and 2 directly on the rpi.

i have a script that creates a tmux session with 6 window panes split and run hcxdumptool with different channels on each of them.

the issue i have is that the display status gets messed up and i cannot see much on the 6 split windows.

do you have any tips to fix the display to be more friendly on this cases or maybe another approach could be to integrate the 6 outputs into one? i saw that you once had a server/client display status but seems that is no longer available.

any suggestions would be appreciated!

[ZerBea]

Nice to read that. Thanks.

Unfortunately I have no solution to handle 6 split windows.
I have a 24 inch monitor. Four open terminal windows are ok, but more is a mess.

Maybe my lessons learned are helpful:

• a beautiful status output make the attack tool slow and sluggish
• too many features make an attack slow and sluggish
• response time behavior becomes very bad on big ring buffers
• transmitting too many packets makes a channel busy
• a Raspberry Pi is not able to handle more than one interface at the same time
• multiple interfaces interfere with each other
• pselect doesn't like to be interrupted by another timer
• epoll is a better solution than pselect
• timerfd in combination with epoll is easier to handle than comparing timestamps
• active monitor require to set virtual MAC on interface - that is too slow
• setting a short preamble in radiotap header is ignored on tx
• entire AUTHENTICATION process should be done using a low data rate of 1.0 Mb/s and a low bandwidth
• there are (much) better ways than injecting stupid DEAUTHENTICATION frames to disconnect a CLIENT
• the most useful EAPOL frame is an EAPOL M2 frame(!)
• NL80211 provide a lot more features than WIRLESS EXTENSIONS
• NL80211 / RTNETLINK protocol can be used without libnl dependency
• sharing the interface (e.g. iw phy phy1 interface add mon0 type monitor) is counterproductive
• TX power is (completely) meaningless - RX sensitivity and a good antenna is all
• it is a thousand times faster using a Berkeley Packet Filter (BPF) than walking through endless filter lists

To find out if the system is at the limit of its performance you can use this command:

$ sudo hcxdumptool --tot=1 --rcascan=active
...2869 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
1290 PROBERESPONSE(s) captured

exit on TOT

Everything is fine and no packets have been dropped!

[g18z0n]

about this lines on your lessons learned:

"a Raspberry Pi is not able to handle more than one interface at the same time"
"multiple interfaces interfere with each other"

if you have time could you elaborate a little more on the subjects?

in what way an RPI can only handle one adapter at a time, any RPI is the same? Zero? 4b/5 ? do you recommend any other better portable system?

also, if each adapter is configured to listen on separated channels, does the same level of interference apply too?

[ZerBea]

multiple interfaces interfere with each other
The 2.4 GHz Wi-Fi spectrum is 70 MHz wide (14 channels at 5 KHz steps). The bandwidth of a single channel is 20 MHz or 40 MHz..
If interface 1 is on channel 1, interface 2 is on channel 6 and interface 3 is on channel 11, all other channels are busy!
Please note that if you are running TX high power adapters, or frequency instable devices, the bandwidth is much higher.
Nearly all home WiFi adapters are unshielded. This makes them even more sensitive to interference
An explanation is here:
https://en.wikipedia.org/wiki/List_of_WLAN_channels
and here:
https://www.beaming.co.uk/knowledge-base/prevent-wireless-interference/

Run two interfaces in parallel:
terminal 1
$ hcxdumptool -i INTERFACE1 --tot=2 -c 1a,6a,11a
terminal 2
$ hcxdumptool -i INTERFACE2 --tot=2 -c 3a,8a,
Do you see on terminal 1 other channels than 1a, 6a or 11a?
Do you see on terminal 2 other channels than 3a or 8a?
If yes, these are the visible interferences.
Interferences, you don't see (spectrum analyzer is mandatory to detect them), e.g:
decrease of signal strength on neighbor channels
unwanted RF irradiation from interface 1 into unshielded interface 2

a Raspberry Pi is not able to handle more than one interface at the same time
I think this is explained here (bottle neck is the driver):
#500
I've added code to run hcxdumptool with 3 interfaces at the same time - and gave it up due to driver bottle neck and heavy interference.

Maybe the situation is better when running hcxdumptool in parallel.
Run three interfaces in parallel:
terminal 1
$ hcxdumptool -i INTERFACE1 --rcascan=active --tot=2 -c 1a
terminal 2
$ hcxdumptool -i INTERFACE2 --rcascan=active --tot=2 -c 6a
terminal 3
$ hcxdumptool -i INTERFACE3 --rcascan=active --tot=2 -c 6a
do you see packet drops when they finished!