missing frames in .pcapng

[gemesa]

So I have been doing some measurements with my new Awus036ACHM:

$ sudo ./hcxdumptool -i wlp0s20f0u1 --rds=1 -c 36b,40b,44b,48b,52b,56b,60b,64b,100b,104b,108b,112b,116b,120b,124b,128b,132b,136b,140b,144b,149b,153b,157b,161b,165b,169b,173b

And when I checked it I saw there are some missing frames reported. Why could this happen? I did not clean the .pcapng and did not use any filtering. It happened only in one of my recordings.

$ ./hcxpcapngtool ../hcxdumptool/20230416224715-wlp0s20f0u1.pcapng 
hcxpcapngtool 6.2.9 reading from 20230416224715-wlp0s20f0u1.pcapng...

summary capture file
--------------------
...
EAPOL M1 messages (total)................: 26
EAPOL M2 messages (total)................: 1
EAPOL M3 messages (total)................: 4
EAPOL M4 messages (total)................: 1
EAPOL M4 messages (zeroed NONCE).........: 1
EAPOL pairs (total)......................: 2
EAPOL pairs (best).......................: 1
EAPOL M32E2 (authorized).................: 1
RSN PMKID (useless)......................: 2

frequency statistics from radiotap header (frequency: received packets)
-----------------------------------------------------------------------
 5180: 15    5200: 38    5300: 1     5500: 1    
 5560: 2    

Information: missing frames!
This dump file does not contain undirected proberequest frames.
An undirected proberequest may contain information about the PSK.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it hard to recover the PSK.

Information: no hashes written to hash files

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

[ZerBea]

Three possibilities: 1) The runtime was too short - during capturing no PROBEREQUEST was received.

2) There are several frequencies in your scan list on which a CLIENT is not allowed (by wireless regulatory domain) to transmit PROBEREQUESTs. Additional, depending on your wireless regulatory setting, the kernel doesn't allow hcxdumptool, to transmit/receive on several frequencies, too.

$ iw reg get
global
country HU: DFS-ETSI
    (2400 - 2483 @ 40), (N/A, 20), (N/A)
    (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
    (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
    (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
    (5725 - 5875 @ 80), (N/A, 13), (N/A)
    (5945 - 6425 @ 160), (N/A, 23), (N/A), NO-OUTDOOR
    (57000 - 66000 @ 2160), (N/A, 40), (N/A)

3) A combination of both

Please notice that the RANGE on > 5GHz is (extreme poor - mostly less than half of 2.4GHz).

I do not recommend to use such a scan list.

[ZerBea]

BTW: ....not use any filtering. You may not know it, but unfortunately you did filtering (frequency usage and tx power by wireless regulatory domain settings).

If the regulatory domain is unset (00 = highest restriction). You are not allowed to transmit on most of the frequencies.

$ iw reg get
global
country 00: DFS-UNSET
    (755 - 928 @ 2), (N/A, 20), (N/A), PASSIVE-SCAN
    (2402 - 2472 @ 40), (N/A, 20), (N/A)
    (2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN
    (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
    (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN
    (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN
    (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
    (5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
    (57240 - 63720 @ 2160), (N/A, 0), (N/A)

That makes your scan list mostly useless.

[ZerBea]

BTW: If you are not stationary (over a long time) such a huge scan list (27 entries) doesn't make sense. Let's do some math: By design, 5ghz wifi cannot cover as much distance as 2.4ghz wifi can. On > 5GHz wall-penetration is poor - we can expect a RANGE of 50 meters.

If you're going by car at speed of 50km/h you're going 13.88m/sec hcxdumptool stay up to 5 seconds on a channel (if an AUTHENTICATION started it will stay longer). 5s * 13, 88m/s = 65 m

Scanning all frequencies from your list will take 27ch 5s 13,88m/s = 1873,8 m/27ch! In other words: You are out of range (on every channel) long before you can spell the word PROBEREQUEST.

[gemesa]

Thank you for the explanation. So first I checked the available frequencies:

$ sudo ./hcxdumptool -I wlp0s20f0u1
...
available frequencies: frequency [channel] tx-power of Regulatory Domain: HU

  2412 [  1] 2.0 dBm      2417 [  2] 2.0 dBm      2422 [  3] 2.0 dBm      2427 [  4] 3.0 dBm
  2432 [  5] 3.0 dBm      2437 [  6] 3.0 dBm      2442 [  7] 3.0 dBm      2447 [  8] 3.0 dBm
  2452 [  9] 3.0 dBm      2457 [ 10] 3.0 dBm      2462 [ 11] 3.0 dBm      2467 [ 12] 3.0 dBm
  2472 [ 13] 3.0 dBm      2484 [ 14] disabled     5180 [ 36] 16.0 dBm     5200 [ 40] 16.0 dBm
  5220 [ 44] 16.0 dBm     5240 [ 48] 16.0 dBm     5260 [ 52] 15.0 dBm     5280 [ 56] 15.0 dBm
  5300 [ 60] 15.0 dBm     5320 [ 64] 15.0 dBm     5500 [100] 12.0 dBm     5520 [104] 12.0 dBm
  5540 [108] 12.0 dBm     5560 [112] 12.0 dBm     5580 [116] 12.0 dBm     5600 [120] 12.0 dBm
  5620 [124] 12.0 dBm     5640 [128] 12.0 dBm     5660 [132] 12.0 dBm     5680 [136] 12.0 dBm
  5700 [140] 13.0 dBm     5720 [144] 13.0 dBm     5745 [149] 13.0 dBm     5765 [153] 13.0 dBm
  5785 [157] 13.0 dBm     5805 [161] 13.0 dBm     5825 [165] 13.0 dBm     5845 [169] 6.0 dBm
  5865 [173] 6.0 dBm

bye-bye

And after that I basically added all these 5G channels to the scan list. I wanted to record 'all' communication but now I see this list is way too long, even though I am not moving while doing the scanning. I will reduce it.

There are several frequencies in your scan list on which a CLIENT is not allowed (by wireless regulatory domain) to transmit PROBEREQUESTs. Additional, depending on your wireless regulatory setting, the kernel doesn't allow hcxdumptool, to transmit/receive on several frequencies, too.

All of the channels above can be used by APs and CLIENTs here in Hungary, right? They have to respect the maximum allowed TX power but there is no other constraint if I understand correctly.

The runtime was too short - during capturing no PROBEREQUEST was received.

This is the rootcause for sure because I made very short recordings.

[ZerBea]

This is the rootcause for sure because I made very short recordings. I agree. If you take a look at the default WiFi scan interval of e.g. an Android device: https://developer.android.com/guide/topics/connectivity/wifi-scan The chance is poor that hcxdumptool and the Android device are on the same frequency at the same time.

Also please take a look at the regulatory domain setting of HU:

$ iw reg get
global
country HU: DFS-ETSI
    (2400 - 2483 @ 40), (N/A, 20), (N/A)
    (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
    (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
    (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
    (5725 - 5875 @ 80), (N/A, 13), (N/A)
    (5945 - 6425 @ 160), (N/A, 23), (N/A), NO-OUTDOOR
    (57000 - 66000 @ 2160), (N/A, 40), (N/A)

especially this frequency range:

    (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
    (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS

DFS is mandatory on this frequencies. Transmissions are not allowed if a RADAR signal is detected by the device.

[gemesa]

DFS is mandatory on this frequencies. Transmissions are not allowed if a RADAR signal is detected by the device.

Hm, this is very interesting. There is a military base near my hometown and they do a lot of military exercises, I hope I can do some measurements during them.

[gemesa]

Thanks for all the info, issue is solved meanwhile.

[ZerBea]

WiFi stuff is really complex. There are a lot of screws you can turn.

That's why knowledgeof radio technology and wave engineering is on a high rank:

* knowledge of radio technology
* knowledge of electromagnetic-wave engineering
* detailed knowledge of 802.11 protocol
* detailed knowledge of key derivation functions
* detailed knowledge of Linux
* detailed knowledge of filter procedures (Berkeley Packet Filter, capture filter, display filter)