Capture second level 5G AP test

[LLH-l]

ever tried such a experiment ?

1. AP is in living room,
2. Another router is in own room

room router use 2.4g bridge connect to living room APs, and using 5gh signals launch
capture own room router 5gh signals handshake fail
Use kali2023-3 wifislax3.4test
Network card, RTL8812AU RTL8812BU RT5572

but can capture own room router 2.4gh signals

[ZerBea]

Possible three reasons:
This drivers are not part of the Linux kernel: RTL8812AU RTL8812BU
5GHz depend on wireless regulatory settings (DFS unset will not work).
MESH connections are untouched.

[LLH-l]

also use other network card test each channel, work best is 8812AU
test airodump it also facing fail
prompt: No such BSSID available (in airodump)

But wifite can capture handshake, and in each channel test capture
test channel: 36,40,44,48,52,56,60,64,149,153,157,161,165
capture success channel: 44,52,56,60,64,153,157,161
capture fail channel: 36,40,48,149,165

[ZerBea]

wifite is running hcxdumptool in background.
output of iw reg get?

[LLH-l]

No,
Not is in wifite run hcxdumptool
is independent run hcxdumptool

I don't know, wifite is how works, use v2.7
wifite use command
wifite -5 --new-hs
I may need some time to investigate the cause

[LLH-l]

hcxdumptool -i wlan0 -w a.pcapng -F --rds=1 --bpf=attack.bpf
The seems is hcxdump and BPF filters work coordination between issue
Still fail ...

not use BPF can capture, but it need a lot time
hcxdumptool -i wlan0  -c 149c -w a.pcapng -F --rds=1
CHA    LAST   R 1 3 P S    MAC-AP    ESSID (last EAPOL on top)  SCAN-FREQUENCY:   5610
-----------------------------------------------------------------------------------------
 [149] 14:57:32 + + +   + d1ee07661a55 test_5
 [ 11] 14:57:59 + + +   + 4597cce5475b TP-LINK_**
 

   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last M2ROGUE on top)
-----------------------------------------------------------------------------------------
 14:49:41     4597cce5475b d4ee07341b37 TP-LINK_**
 14:56:00     d1ee07661a55 6360fa8cf03b test_5

^C
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
585 EPB written to pcapng dumpfile
exit on sigterm

if specify capture channel signal, e.g, specify 149c, only capture 149 channel signals,
hcxdumptool -i wlan0 -c 149c  -w a.pcapng -F --rds=1
but it seems ignoring this parameter, will other all channels signals capture

[ZerBea]

Please double check your command line, because it is wrong:
Channel 149 is band b (5745 [149]) - correct option = -c 149b
You told hcxdumptool to scan channel 149 (option c) and(!) to scan all channels (option F).
The correct command line is:
$ hcxdumptool -i wlan0 -c 149b -w a.pcapng --rds=1

You are right, scanning all available channels take a long, long time.
Exactly that is the reason why hcxdumptool onl scan 1a,6a,11a by default.

[LLH-l]

hcxdumptool -i wlan0 -c 149 -w a.pcapng --rds=1
no using "b" , it can normally work ?

[ZerBea]

Since WiFi 6 channel numbers are no longer unique. It is mandatory to add the band -c 149b or to use the frequency -f 5745.

[LLH-l]

[ZerBea]

Option changed, because hcxdumptool now provide active and passive scanning.
hcxdumptool -h will show this:

--rcascan=<character>     : do (R)adio (C)hannel (A)ssignment scan only
                             default = passive scan
                             a = active scan
                             p = passive scan
                            packets are not stored to dump file
                            not in combination with attack modes

[ZerBea]

Option changed, because hcxdumptool now provide active and passive scanning.
hcxdumptool -h will show this:

--rcascan=<character>     : do (R)adio (C)hannel (A)ssignment scan only
                             default = passive scan
                             a = active scan
                             p = passive scan
                            packets are not stored to dump file
                            not in combination with attack modes

[LLH-l]

@ZerBea
How in without any clients capture handshake ?
Forge a client to and the AP communicate, handshake can be capture ?

[ZerBea]

No CLIENT == no handshake

These are the three options

1. get PMKID from AP
2. get M1 from AP and M2 from a CLIENT associated with the AP
3. get M2 from a CLIENT associated with hcxdumptool

[LLH-l]

have some questions
hcxdumptool -i wlan0 --rcascan=a
--2.4gh default: only scan channel 1a, 6a, 11a, and ignoring other channel
--5gh default: only scan some mainstream channel ?
How can scan all channel (2.4gh+5gh) ?

If need write so much 
hcxdumptool -i wlan0 -c 1a,2a,3a,4a,5a,6a,7a,8a,9a,10a,11a,12a,13a,14a,36b,40b,44b,48b,52b,56b,60b,64b,100b,104b,108b,112b,116b,120b,124b,128b,132b,136b,140b,149b,153b,157b,161b,165b  --rcascan=a
have simpler parameters to represent them 

hcxdumptool -i wlan0 --rcascan=a
hcxdumptool -i wlan0 --rcascan=p
passive and active the have between difference ?

Also seems
scan work, need will best signals to sort
Display whether there a client ( best signals client )

[ZerBea]

default: scan channels 1a,6a,11a
-F scan all by device available and by regulatory domain allowed channels
Frequencies >= 5GHz depend on the capabilities of the device and the regulatory settings. There are no common used channels.

active scan: count BEACONs, send PROBEREQUESTs and count PROBERESPONSEs
passive scan: receive and count BEACONs only

Your feature requests are not feasible because hcxdumptool interacts with the target and it must(!) respond in the assigned time interval. This is not hashcat or JtR zone. In contrast to this off-line tools, hcxdumptool must do everything on the fly!
More information is here:
https://en.wikipedia.org/wiki/Guard_interval

On systems like a Raspberry or a router (running openwrt) we simply do not have the time to

• print a beautiful realtime display
• to handle all incoming frames
• to walk through the entire radiotap header to get RSSI
• to walk through all NMEA0183 sentences to evaluate all GPS values
• and much more

If you don't believe this, analyze a dump file and take a look at the request/respond times.
Add a time measurement to hcxdumtool's functions.
Than take a look at the remaining time.

That is the reason (save CPU cycles) why there is an option to disable NMEA0183 and the disable the REALTIME DISPLAY in make file.

To give an impression about the elapsed time to handle such a simple frame like a BEACON:

handle BEACON 1413 nsec
handle BEACON 992 nsec
handle BEACON 1272 nsec
handle BEACON 1333 nsec
handle BEACON 1052 nsec
handle BEACON 1443 nsec
handle BEACON 1533 nsec
handle BEACON 1743 nsec
handle BEACON 911 nsec

And hcxdumptool must handle hundreds of BEACONs in a second.

[LLH-l]

@ZerBea
I finally found the issues cause
I by manually changing the MAC,in instant capture to it
tcpdump -i wlan0 wlan addr3 BC:D1:77:5C:B7:84 or wlan addr3 B9:D1:77:5C:B7:84 -ddd > attack.bpf

e.g..
2.4ghz: Use MAC address is: BC:D1:77:5C:B7:84
5ghz: Use MAC address is: B9:D1:77:5C:B7:84
They use not same MAC addresses

Usually have some AP MAC chang characteristic
2.4ghz: 00:0C:41:82:B2:05
5ghz: 00:0C:41:82:B2:06

[ZerBea]

With regard to hcxdumtpool the MAC used in the filter must match to the target. That is mandatory!

With regard to airodump-ng you should ask your questions here:
https://github.com/aircrack-ng/aircrack-ng/discussions

With regard to wifite you should ask your questions here:
https://github.com/kimocoder/wifite2

[LLH-l]

[ZerBea]

You should do some investigations about your target.
Usually an AP could use several different MACs, e.g.:

• LAN MAC
• WLAN MAC 2.4GHz
• WLAN MAC 5 GHz
• WLAN MAC 2.4 GHz guest
• WLAN MAC 5 GHz guest

Do a rcascan to discover all MACs. Than add them to your filter and run the attack.

https://networkengineering.stackexchange.com/questions/54662/is-there-any-relation-between-mac-addresses-of-a-dual-band-2-4-and-5-ghz-route

[LLH-l]

@ZerBea
Sorry, all work fine, I in MAC a mistake
will wrong MAC wrote to BPF

[ZerBea]

Ok