Closed 108806 closed 1 year ago
The segmentation fault is caused by the driver (NETLINK) in combination with Wireshark [code] [ 5595.350634] WARNING: CPU: 14 PID: 63499 at net/wireless/nl80211.c:3722 nl80211_send_chandef+0x179/0x190 [cfg80211] ... [ 5595.350794] CPU: 14 PID: 63499 Comm: wireshark Tainted: [/code] hcxdumptool doesn't use NETLINK [code] [ 5595.351067] netlink_rcv_skb+0x51/0x100 [ 5595.351070] genl_rcv+0x24/0x40 [ 5595.351073] netlink_unicast+0x242/0x390 [ 5595.351076] netlink_sendmsg+0x250/0x4c0 [/code]
Unfortunately the ALFA AWUS036AC is running a Realtek Chipset (RTL8812AU) and the driver depend on NETLINK. This driver is not recommended to be used with hcxdumptool. [code] Not recommended WiFi chipsets due to driver problems:
$ sudo hcxdumptool -o router_ddos.pcapng -i wlan0 --active_beacon --enable_status=15 is the most aggressive mode that hcxdumptool provide. The REASSOCIATION ATTACK worked as expected.packet 6 we got a REASSOCIATION RESPONSE followed by the 4way handshake (packets 7 to 10). After the handshake was capture, the attack stopped. In the dump file, I can't see a router crash.
The following options deactivate attacks against an AP:
disable old school deauthentication attack:
--disable_deauthentication
disable ASSOCIATION and REASSOCIATION attack:
--disable_ap_attacks
entire command line:
$ sudo hcxdumptool -o router_ddos.pcapng -i wlan0 --active_beacon --enable_status=15 --disable_ap_attacks --disable_deauthentication
I forgot to mention that DDoS attacks are not implemented in hcxdumptool. hcxdumptool will stop an attack if it got either a PMKID or a 4way handshake. Additional it give up if an attack is useless (can be controlled by this options).
--stop_ap_attacks=<digit> : stop attacks against ACCESS POINTs if <n> BEACONs received
default: stop after 600 BEACONs
--resume_ap_attacks=<digit> : resume attacks against ACCESS POINTs after <n> BEACONs received
default: 864000 BEACONs
I did the same test on my old Ralink2870/3070 with the driver rt2800usb, and I still got accidental DDoS against my router, my desktop pc is connected via cable and I couldn't even access my router home page for smthn about 20-30s, and to be even funnier there is nothing in the router's logs, idk maybe this router is just garbage, but again hash was correctly captured:
16:27:35 2457/10 88b4a6c73425 000df2aed8ed /'"''' [AUTHENTICATION]
16:27:35 2457/10 88b4a6c73425 000df2aed8ed /'"''' [ASSOCIATION]
16:27:35 2457/10 b4cd274b31a1 000df2aed8ed /'"''' [AUTHENTICATION]
16:27:36 2462/11 b4cd274b31a1 000df2aed8ed /'"''' [REASSOCIATION]
16:28:31 2457/10 88b4a6c73425 000df2aed8ed /'"''' [EAPOL:M1M2ROGUE EAPOLTIME:5525 RC:62878 KDV:2]
However, I assume that this capture was done using the old method hence the EAPOL being mentioned. So, how can I force PMKID mode? Tried running attack with --disable_deauthentication for a few hours and no success at all, looks like only the old mode is working via deauth.
Please run:
$ sudo hcxdumptool -o dump.pcapng -i wlan0 --active_beacon --enable_status=63 --disable_ap_attacks --disable_deauthentication
That disable all AP attacks.
Is the router still going down?
This
16:28:31 2457/10 88b4a6c73425 000df2aed8ed /'"''' [EAPOL:M1M2ROGUE EAPOLTIME:5525 RC:62878 KDV:2]
is a result of an AP less attack. The CLIENT connected to hcxdumptool instead of coneccting to the router.
If the router is not going down please do the next step:
$ sudo hcxdumptool -o dump.pcapng -i wlan0 --active_beacon --enable_status=63 --disable_deauthentication
If the router is not going down please do the last step:
$ sudo hcxdumptool -o dump.pcapng -i wlan0 --active_beacon --enable_status=63
Sorry for torturing you but I have encountered some additional issues with filters.
$cat filterlist.txt
d232e562b757
cc32e562b757
and while doing ie
$sudo hcxdumptool -o dump.pcapng -i wlan0 --active_beacon --enable_status=63 --filtermode=2 --filterlist_ap=filterlist.txt
hcxdumptool is attacking lots of random stuff in addition to the target macs in the filterlist, what am I doing wrong?
Are you sure that your router crashed? After NETLINK crashed, your wired connection went down.
[ 5628.811846] r8169 0000:04:00.0 eth0: Link is Down
[ 5654.873337] r8169 0000:04:00.0 eth0: Link is Down
[ 5660.328093] r8169 0000:04:00.0 eth0: Link is Down
Your PC was not longer able to connect to your router via wired eth0.
Your command line is ok:
$ sudo hcxdumptool -o dump.pcapng -i wlan0 --active_beacon --enable_status=63 --filtermode=2 --filterlist_ap=filterlist.txt
and hcxdumptool only interacts with this 2 APs.
Please notice that: hcxdumptool still acts as a passive dumper. If another AP transmit a 4way handshake, hcxdumptool will receive and show it. Also hcxdumptool respond to every CLIENT request, because CLIENT attacks are not disabled.
It is important to understand that this kind of filtering (filtermode + filterlist) is active only on transmission branch. It is neither a reception filter nor a display filter. That means that the reception branch is unfiltered and hcxdumptool will receive and show everything that is on the air. You can monitor this behavior if you're running Wireshark in parallel. You'll see that hcxdumptool interacts only with the 2 APs of the filterlist, but receive everything that is on the channel. It also interacts with all CLIENTs that try to connect to hcxdumptool.
If you want to filter transmission branch and reception branch or reception branch only it is mandatory to add a BPF!
This behavior is mentioned in --help:
--filtermode=<digit> : user space filter mode for filter list
notice: this filter option will let hcxdumptool protect or attack a target - it is neither a capture nor a display filter
in contrast to the kernel filter (BPF):
--bpfc=<file> : input kernel space Berkeley Packet Filter (BPF) code
affected: incoming and outgoing traffic - that include rca scan
Example 64:66:b3:8e:c3:fc = test target router add BPF to filter incoming and outgoing traffic on transmission branch and reception branch (this affects the real time display, too)
$ sudo hcxdumptool -m wlp39s0f3u1u1u1
setting interface wlp39s0f3u1u1u1 to monitor mode
$ sudo tcpdump -i wlan addr1 64:66:b3:8e:c3:fc or wlan addr2 64:66:b3:8e:c3:fc or wlan addr3 64:66:b3:8e:c3:fc -ddd > attack.bpf
$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --do_rcascan --bpfc=attack.bpf
BSSID FREQ CH RSSI BEACON RESPONSE ESSID SCAN-FREQ: 2432 INJECTION-RATIO: 28% [23:18:01]
-----------------------------------------------------------------------------------------------------
6466b38ec3fc 2462 11 -59 53 23 TP-LINK_HASHCAT_TEST
^C
terminating...
As you can see: only frames that have this BSSID MAC in addr1, addr2 or addr3 are displayed and nothing else only frames that have this BSSID MAC in addr1, addr2 or addr3 are attacked and nothing else
Some more information about filtering (hcxdumptool use the same technique): https://en.wikipedia.org/wiki/Berkeley_Packet_Filter https://tshark.dev/capture/capture_filters/ https://wiki.wireshark.org/DisplayFilters https://wiki.wireshark.org/CaptureFilters https://www.digihunch.com/2020/06/network-analyzer-capture-filter-and-display-filter/
The MAC addresses
Address 1: RA=DA (Receiver Address= Destination Address)
Address 2: TA=BSSID (Transmitter Address= Basic Service Set Identifier)
Address 3: SA (Source Address)
are explained here: https://mrncciew.com/2014/09/28/cwap-mac-headeraddresses/
BTW: Undirected PROBEREQUEST frames are very useful. I recommend to include them in the BPF:
$ sudo tcpdump -i wlan addr1 64:66:b3:8e:c3:fc or wlan addr2 64:66:b3:8e:c3:fc or wlan addr3 64:66:b3:8e:c3:fc or wlan addr3 ff:ff:ff:ff:ff:ff -ddd > attack.bpf
This avoid a warning of hcxpcapngtool (missing frames) when converting a BPF filtered dump file.
You encountered and reported three problems.
first: dmesg crash report
This was caused by Wireshark in combination with NETLINK and RTL8812AU driver
[ 5595.350794] CPU: 14 PID: 63499 Comm: wireshark Tainted:
second: you can't connect to your router
This is a result of the crash above, because the wired interface went down
[ 5660.328093] r8169 0000:04:00.0 eth0: Link is Down
third: misunderstanding of filtering techniques (transmission filter, capture filter, display filter)
hcxdumptool is attacking lots of random stuff in addition to the target macs in the filterlist, what am I doing wrong?
I'm not sure what to think about this, this new mode should be non-intrusive, right?
Interface is in monitor mode just listening, so I should be kinda invisible to the router, so how can it derail my router so bad?
This is bug tracker and none of the three reported bugs is a hcxdumptool bug. So I'm going to close this report.
BTW: "Third" are more questions than bugs. Exactly for that kind of questions I opened "discussions" https://github.com/ZerBea/hcxdumptool/discussions
Thank you for your help to understand this, you are a jedi.
Although, i'm not sure if this is entirely true (because I have eth0 down after deauth even with rtl2800usb), but I don't think hcxdumptool has anything to do with this at that point so I guess closing this issue makes sense, thanks again
Looks like you're not the only one having a problem on 6.0.0-kali6-amd64.
I think that crappy router software is also a separate issue.
I have done another small test today, I did start hcxdumptool on my laptop with kali and with using that not-recommended awus(no crashes in dmesg this time though), also with my router being filter protected, and with --disable_deauthentication
,
and when I got:
13:28:56 5223/44 88b4a624d6ac cc32e562b756 /'"''' [PROBERESPONSE] 13:28:58
5223/44 88b4a6c73425 cc32e562b756 /'"''' [AUTHENTICATION] 13:28:59 5223/44
88b4a6c73425 cc32e562b756 /'"''' [REASSOCIATION] 13:28:59 5223/44 88b4a6c73425
cc32e562b756 /'"''' [EAPOL:M1M2 EAPOLTIME:11484 RC:2 KDV:2] 13:28:59 5223/44
88b4a6c73425 cc32e562b756 /'"''' [EAPOL:M3M4ZEROED EAPOLTIME:42 RC:3 KDV:2]
My other PC connected to the router with Ethernet cable was unable to connect to the router again. I'm quite sure that router software is just buggy because this shouldn't disable any router, AFAIK, hcxdumptools was basically just sniffing frames between an android phone and router and this router got disabled for a few minutes from just that. Maybe I should let TP-Link know, but I don't see them anywhere on GH.
--disable_deauthentication doesn't disable attacks on an AP
hcxdumptool ran a successful REASSOCIATION attack on the AP
88b4a6c73425 cc32e562b756 /'"''' [REASSOCIATION] 13:28:59 5223/44 88b4a6c73425
to retrieve a handshake:
88b4a6c73425 cc32e562b756 /'"''' [EAPOL:M1M2 EAPOLTIME:11484 RC:2 KDV:2] 13:28:59 5223/44
At the moment I'm trying to reproduce it. Test target (very) old TPL-Link TL-WR841N hcxdumptool got the 4way handshake neither the AP nor the CLIENT crashed
Added an old FRITZ!BOX Fon WLAN 7270 as second target to the test environment. Same results as mentioned above. Both routers are accessible after the attack.
hcxdumptool ran a successful REASSOCIATION attack on the AP
So it means that client was disconnected from the network. This is exactly what I've tried to avoid with --disable_deauthentication
, so much reading and I still fail to recognize the type of attack.
Anyway, I can reproduce DDoS for all the other devices in the network every single time with ``--enable_status=15```, here is the pcapng from both the laptop and the desktop while this is happening (Desktop was pinging 1.1.1.1 constantly to make it more noticeable this time) Accidental_DDoS_TP-LINK_archer-c6v2.0_firmware-1.3.7.zip
I don't think I can do much more with it, maybe you should try to check this particular router if you will have your hands on ArcherC6v2.
Cheers.
You disabled deauthentications, but not ap_attacks. As a results, a REASSOCIATION attack was performed by hcxdumptool. This attack will not disconnect a CLIENT. It just forced a REASSOCIATION as seen in packet 5 5 Jan 18, 2023 16:50:18.136695000 CET IEEE 802.11 Reassociation Response, Flags: ........C
If you don't want this you have to add --disable _ap_attacks
--disable_ap_attacks : do not attack access points
affected: connected clients and client-less (PMKID) attack
If you don't want that hcxdumptool transmit you have to use the option --silent.
Now the important parts: Your dump files are not useful due to different timestamps:
$ tshark -r filtered_desktop_client_eth.pcapng -T fields -e frame.number -e frame.time
1 Jan 18, 2023 16:45:44.374795000 CET
2 Jan 18, 2023 16:45:44.385711000 CET
3 Jan 18, 2023 16:45:44.648041000 CET
4 Jan 18, 2023 16:45:44.648141000 CET
5 Jan 18, 2023 16:45:44.648207000 CET
...
371 Jan 18, 2023 16:48:35.847293000 CET
372 Jan 18, 2023 16:48:36.862083000 CET
373 Jan 18, 2023 16:48:36.870240000 CET
374 Jan 18, 2023 16:48:37.873323000 CET
375 Jan 18, 2023 16:48:37.882508000 CET
$ tshark -r notebook_wlan.pcapng -T fields -e frame.number -e frame.time
1 custom block
2 Jan 18, 2023 16:50:13.334460000 CET
3 Jan 18, 2023 16:50:13.334568000 CET
4 Jan 18, 2023 16:50:13.681962000 CET
5 Jan 18, 2023 16:50:18.136695000 CET
6 Jan 18, 2023 16:50:18.140608000 CET
...
28 Jan 18, 2023 16:50:47.760325000 CET
29 Jan 18, 2023 16:50:47.791242000 CET
30 Jan 18, 2023 16:51:18.063206000 CET
31 Jan 18, 2023 16:52:21.331302000 CET
32 Jan 18, 2023 16:52:28.873974000 CET
This is far behind of the timestamps of the first dump file.
You pinged 1.1.1.1 (in www) and not the local IP of your router. After this query the router told you that the query to 1.1.1.1 (in www) failed. Your internet was broken, not the connection to your router
179 Jan 18, 2023 16:46:27.938682000 CET
Internet Protocol Version 4, Src: 1.3.3.243, Dst: 1.1.1.1
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x4152 [correct]
[Checksum Status: Good]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence Number (BE): 3081 (0x0c09)
Sequence Number (LE): 2316 (0x090c)
[No response seen]
Data (32 bytes)
The REASSOCIATION was done at 16:50:18.136695000
5 Jan 18, 2023 16:50:18.136695000 CET
IEEE 802.11 Reassociation Response, Flags: ........C
which is far ahead when the router lost connection to the internet:
179 Jan 18, 2023 16:46:27.938682000 CET
But anyway, all the time there was a stable connection between your CLIENT and your router.
hcxdumptool is not able to break a connection between a router and the internet.
BTW: If you want to monitor the traffic on the channel it is mandator to setup 1 third interface an the same channel to monitor the entire wlan traffic on a channel. Also I suggest to ping the router address and not an address in www.
Timeframe is ok, but there is 4m26s difference between my notebook(+) and my desktop. I had my router ignoring ping for security reasons, so I thought pinging some public DNS would be enough to show that connectivity is totally broken when this occurs.
So this time with pinging the router itself, and third interface monitoring, all raw unfiltered (with some garbage too, and still with 4m26s difference): TPLINK_C6v2.zip
If that time difference is so important then I can sync it and conduct the test yet again, honestly idk if that monitoring is done properly because it was done by internal laptop interface which are not always working with the monitor mode properly, but maybe you can read something from it.
Thanks. This is helpful. I guess this is your router:
BSS Id: cc:32:e5:62:b7:57
Tag: SSID parameter set: "/'"'''"
There is another MAC d2:32:e5:62:b7:57 related to your AP
BSS Id: d2:32:e5:62:b7:57
Tag: SSID parameter set: Wildcard SSID
Is this a guest network?
There are 5 DEAUTHENTICATION frames coming from hcxdumptool. Both BSSID are attacked
$ tshark -r notebook_wlan1_channel-1-monitor.pcapng -Y "(wlan.fc.type_subtype == 0x0c)"
7456 19:07:59,871548862 d2:32:e5:62:b7:57 → ff:ff:ff:ff:ff:ff 802.11 86 Deauthentication, SN=1, FN=0, Flags=........C
8381 19:08:04,424314452 cc:32:e5:62:b7:57 → ff:ff:ff:ff:ff:ff 802.11 86 Deauthentication, SN=3, FN=0, Flags=........C
9643 19:08:05,806184596 d2:32:e5:62:b7:57 → ff:ff:ff:ff:ff:ff 802.11 86 Deauthentication, SN=4, FN=0, Flags=........C
11407 19:08:10,513001223 d2:32:e5:62:b7:57 → ff:ff:ff:ff:ff:ff 802.11 86 Deauthentication, SN=5, FN=0, Flags=........C
13397 19:08:14,816145809 d2:32:e5:62:b7:57 → ff:ff:ff:ff:ff:ff 802.11 86 Deauthentication, SN=6, FN=0, Flags=........C
There are 4 DISASSOCIATION frames recorded coming from your AP (cc:32:e5:62:b7:57) There is one DISASSOCIATION frames recorded coming from your CLIENT ( b4:cd:27:4b:31:a1)
$ tshark -r notebook_wlan1_channel-1-monitor.pcapng -Y "(wlan.fc.type_subtype == 0x0a)"
8134 19:08:03,094843449 cc:32:e5:62:b7:57 → b0:fe:bd:f0:cf:d3 802.11 86 Disassociate, SN=256, FN=0, Flags=........C
8135 19:08:03,095433296 cc:32:e5:62:b7:57 → b0:fe:bd:f0:cf:d3 802.11 86 Disassociate, SN=256, FN=0, Flags=....R...C
8136 19:08:03,095943037 cc:32:e5:62:b7:57 → b0:fe:bd:f0:cf:d3 802.11 86 Disassociate, SN=256, FN=0, Flags=....R...C
8137 19:08:03,096390936 cc:32:e5:62:b7:57 → b0:fe:bd:f0:cf:d3 802.11 86 Disassociate, SN=256, FN=0, Flags=....R...C
25464 19:09:06,182305512 b4:cd:27:4b:31:a1 → cc:32:e5:62:b7:57 802.11 86 Disassociate, SN=2856, FN=0, Flags=........C
There is one REASSOCIATIONREQUEST coming from hcxdumptool
$ tshark -r notebook_wlan1_channel-1-monitor.pcapng -Y "(wlan.fc.type_subtype == 0x02)"
9754 19:08:07,494893330 b4:cd:27:4b:31:a1 → cc:32:e5:62:b7:57 802.11 154 Reassociation Request, SN=9, FN=0, Flags=........C, SSID="/'"'''"
This attack was successful: we got a REASSOCIATIONRESPONSE
$ tshark -r notebook_wlan0_attacker.pcapng -Y "(wlan.fc.type_subtype == 0x03)"
32 19:08:07,493267 cc:32:e5:62:b7:57 → b4:cd:27:4b:31:a1 802.11 110 Reassociation Response, SN=260, FN=0, Flags=........C
followed by a 4way handshake
$ tshark -r notebook_wlan0_attacker.pcapng -Y "eapol"
33 19:08:07,499184 cc:32:e5:62:b7:57 → b4:cd:27:4b:31:a1 EAPOL 167 Key (Message 1 of 4)
34 19:08:07,500862 b4:cd:27:4b:31:a1 → cc:32:e5:62:b7:57 EAPOL 189 Key (Message 2 of 4)
35 19:08:07,508892 cc:32:e5:62:b7:57 → b4:cd:27:4b:31:a1 EAPOL 223 Key (Message 3 of 4)
36 19:08:07,511865 b4:cd:27:4b:31:a1 → cc:32:e5:62:b7:57 EAPOL 167 Key (Message 4 of 4)
Depending on your command line options this attack on the AP doesn't look very intrusive.
Additional there is a successful attack on the CLIENT to get its M2:
$ tshark -r notebook_wlan0_attacker.pcapng -Y "eapol" -T fields -e frame.number -e frame.time -e wlan.sa -e wlan.ta -e eapol.keydes.replay_counter
hcxdumptool request M2 from CLIENT:
11 Jan 18, 2023 20:08:04.591303000 CET cc:32:e5:62:b7:57 b4:cd:27:4b:31:a1 65514
12 Jan 18, 2023 20:08:04.594170000 CET cc:32:e5:62:b7:57 b4:cd:27:4b:31:a1 65514
13 Jan 18, 2023 20:08:04.598770000 CET cc:32:e5:62:b7:57 b4:cd:27:4b:31:a1 65514
14 Jan 18, 2023 20:08:04.602454000 CET cc:32:e5:62:b7:57 b4:cd:27:4b:31:a1 65514
15 Jan 18, 2023 20:08:04.606771000 CET cc:32:e5:62:b7:57 b4:cd:27:4b:31:a1 65514
16 Jan 18, 2023 20:08:04.611556000 CET cc:32:e5:62:b7:57 b4:cd:27:4b:31:a1 65514
18 Jan 18, 2023 20:08:04.617028000 CET cc:32:e5:62:b7:57 b4:cd:27:4b:31:a1 65514
20 Jan 18, 2023 20:08:04.618646000 CET cc:32:e5:62:b7:57 b4:cd:27:4b:31:a1 65514
client respond EAPOL M2 to hcxdumptool
21 Jan 18, 2023 20:08:04.618713000 CET b4:cd:27:4b:31:a1 cc:32:e5:62:b7:57 65514
22 Jan 18, 2023 20:08:04.628660000 CET b4:cd:27:4b:31:a1 cc:32:e5:62:b7:57 65514
23 Jan 18, 2023 20:08:04.628787000 CET b4:cd:27:4b:31:a1 cc:32:e5:62:b7:57 65514
24 Jan 18, 2023 20:08:04.632651000 CET b4:cd:27:4b:31:a1 cc:32:e5:62:b7:57 65514
25 Jan 18, 2023 20:08:04.641491000 CET b4:cd:27:4b:31:a1 cc:32:e5:62:b7:57 65514
26 Jan 18, 2023 20:08:04.643115000 CET b4:cd:27:4b:31:a1 cc:32:e5:62:b7:57 65514
28 Jan 18, 2023 20:08:04.646721000 CET b4:cd:27:4b:31:a1 cc:32:e5:62:b7:57 65514
Depending on your command line options this attack on the CLIENT doesn't look very intrusive.
Please take a look at this dump files: https://github.com/ZerBea/hcxtools/files/9836975/CAP.zip especially "1_(5631).cap"
timestamp minimum (GMT)..................: 24.09.2021 16:16:58
timestamp maximum (GMT)..................: 24.09.2021 16:17:29
32 seconds run time and 3401 DEAUTHENTICATON frames injected.
DEAUTHENTICATION (total).................: 3401
We can safely conclude that this was an intrusive attack:
$ hcxpcapngtool "/home/zerobeat/Downloads/CAP/1_(5631).cap"
hcxpcapngtool 6.2.7-91-gedcb0aa reading from 1_(5631).cap...
summary capture file
--------------------
file name................................: 1_(5631).cap
version (pcap/cap).......................: 2.4 (very basic format without any additional information)
timestamp minimum (GMT)..................: 24.09.2021 16:16:58
timestamp maximum (GMT)..................: 24.09.2021 16:17:29
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11 (105) very basic format without any additional information about the quality
endianess (capture system)...............: little endian
packets inside...........................: 14671
ESSID (total unique).....................: 1
BEACON (total)...........................: 1
BEACON on 2.4 GHz channel (from IE_TAG)..: 10
ACTION (total)...........................: 80
PROBERESPONSE (total)....................: 155
DEAUTHENTICATION (total).................: 3401
AUTHENTICATION (total)...................: 11
AUTHENTICATION (OPEN SYSTEM).............: 11
REASSOCIATIONREQUEST (total).............: 4
REASSOCIATIONREQUEST (PSK)...............: 4
WPA encrypted............................: 87
EAPOL messages (total)...................: 63
EAPOL RSN messages.......................: 63
EAPOLTIME gap (measured maximum usec)....: 5628
EAPOL ANONCE error corrections (NC)......: not detected
EAPOL M1 messages (total)................: 59
EAPOL M2 messages (total)................: 1
EAPOL M3 messages (total)................: 2
EAPOL M4 messages (total)................: 1
EAPOL pairs (total)......................: 4
EAPOL pairs (best).......................: 1
EAPOL M34E4 (authorized).................: 1
Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.
Information: limited dump file format detected!
This file format is a very basic format to save captured network data.
It is recommended to use PCAP Next Generation dump file format (or pcapng for short) instead.
The PCAP Next Generation dump file format is an attempt to overcome the limitations
of the currently widely used (but very limited) libpcap (cap, pcap) format.
https://www.wireshark.org/docs/wsug_html_chunked/AppFiles.html#ChAppFilesCaptureFilesSection
https://github.com/pcapng/pcapng
Information: no hashes written to hash files
Information: radiotap header is missing!
Radiotap is a de facto standard for 802.11 frame injection and reception.
The radiotap header format is a mechanism to supply additional information about frames,
from the driver to userspace applications.
https://www.radiotap.org/
Warning: too many deauthentication/disassociation frames detected!
That can cause that an ACCESS POINT change channel, reset EAPOL TIMER,
renew ANONCE and set PMKID to zero.
This could prevent to calculate a valid EAPOL MESSAGE PAIR
or to get a valid PMKID.
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.
session summary
---------------
processed cap files...................: 1
Analysis of eth0 will follow....
BTW: Can you please comment the command line and the content of filterlist_ap you have used?
Over the entire time the CLIENT (1.3.3.243) was connected to the ROUTER (1.3.3.7). But the connection between INTERNET and ROUTER got lost several times and the router reported this to the CLIENT:
$ tshark -r desktop_eth.pcapng -Y "(icmp.type == 3)"
9152 19:06:27,180449 1.3.3.7 → 1.3.3.243 ICMP 111 Destination unreachable (Network unreachable)
9173 19:06:27,698428 1.3.3.7 → 1.3.3.243 ICMP 98 Destination unreachable (Network unreachable)
9174 19:06:27,698428 1.3.3.7 → 1.3.3.243 ICMP 98 Destination unreachable (Network unreachable)
9175 19:06:27,698428 1.3.3.7 → 1.3.3.243 ICMP 98 Destination unreachable (Network unreachable)
9176 19:06:27,698428 1.3.3.7 → 1.3.3.243 ICMP 98 Destination unreachable (Network unreachable)
9203 19:06:27,933635 1.3.3.7 → 1.3.3.243 ICMP 111 Destination unreachable (Network unreachable)
9209 19:06:28,202012 1.3.3.7 → 1.3.3.243 ICMP 111 Destination unreachable (Network unreachable)
9214 19:06:28,274688 1.3.3.7 → 1.3.3.243 ICMP 110 Destination unreachable (Network unreachable)
9215 19:06:28,274764 1.3.3.7 → 1.3.3.243 ICMP 110 Destination unreachable (Network unreachable)
9226 19:06:28,522719 1.3.3.7 → 1.3.3.243 ICMP 113 Destination unreachable (Network unreachable)
9227 19:06:28,522791 1.3.3.7 → 1.3.3.243 ICMP 124 Destination unreachable (Network unreachable)
9241 19:06:28,940306 1.3.3.7 → 1.3.3.243 ICMP 111 Destination unreachable (Network unreachable)
packet 9151 CLIENT requested internet address 1.1.1.1
Internet Protocol Version 4, Src: 1.3.3.243, Dst: 1.1.1.1
ROUTER respond:
9152 19:06:27,180449 1.3.3.7 → 1.3.3.243 ICMP 111 Destination unreachable (Network unreachable)
packet 9173 CLIENT requested internet address 224.0.0.252
Internet Protocol Version 4, Src: 1.3.3.243, Dst: 224.0.0.252
ROUTER respond:
9173 19:06:27,698428 1.3.3.7 → 1.3.3.243 ICMP 98 Destination unreachable (Network unreachable)
the router retried this several times, but the CLIENT didn't respond:
9174 19:06:27,698428 1.3.3.7 → 1.3.3.243 ICMP 98 Destination unreachable (Network unreachable)
9175 19:06:27,698428 1.3.3.7 → 1.3.3.243 ICMP 98 Destination unreachable (Network unreachable)
9176 19:06:27,698428 1.3.3.7 → 1.3.3.243 ICMP 98 Destination unreachable (Network unreachable)
looks like the CLIENT have a problem
packet 9203 CLIENT requested internet address 239.255.255.250
Internet Protocol Version 4, Src: 1.3.3.243, Dst: 239.255.255.250
ROUTER respond:
9203 19:06:27,933635 1.3.3.7 → 1.3.3.243 ICMP 111 Destination unreachable (Network unreachable)
Also I double checked the timestamps from the ROUTER:
$ tshark -r desktop_eth.pcapng -Y "(ip.src == 1.3.3.7)" -T fields -e frame.number -e frame.time -e ip.src
2 Jan 18, 2023 20:03:26.901772000 CET 1.3.3.7
8 Jan 18, 2023 20:03:27.908486000 CET 1.3.3.7
10 Jan 18, 2023 20:03:27.921874000 CET 1.3.3.7
16 Jan 18, 2023 20:03:28.929080000 CET 1.3.3.7
38 Jan 18, 2023 20:03:29.938564000 CET 1.3.3.7
262 Jan 18, 2023 20:03:30.947933000 CET 1.3.3.7
264 Jan 18, 2023 20:03:30.963000000 CET 1.3.3.7
...
13053 Jan 18, 2023 20:06:46.558783000 CET 1.3.3.7
13056 Jan 18, 2023 20:06:46.559298000 CET 1.3.3.7
13059 Jan 18, 2023 20:06:46.596052000 CET 1.3.3.7
13062 Jan 18, 2023 20:06:46.768641000 CET 1.3.3.7
13064 Jan 18, 2023 20:06:46.823712000 CET 1.3.3.7
and there is no indication that the ROUTER went down.
I also checked the timestamps of the BEACON field of the ROUTER. This is the up time of the router.
$ tshark -r notebook_wlan1_channel-1-monitor.pcapng -Y "(wlan.fc.type_subtype == 0x0008 && wlan.bssid == cc:32:e5:62:b7:57)" -T fields -e frame.number -e frame.time -e wlan.fixed.timestamp -e wlan.bssid | head
5 Jan 18, 2023 20:07:38.224287768 CET 11736985984 cc:32:e5:62:b7:57
31 Jan 18, 2023 20:07:38.326729957 CET 11737088384 cc:32:e5:62:b7:57
34 Jan 18, 2023 20:07:38.429062911 CET 11737190784 cc:32:e5:62:b7:57
39 Jan 18, 2023 20:07:38.531303293 CET 11737293184 cc:32:e5:62:b7:57
42 Jan 18, 2023 20:07:38.633639970 CET 11737395584 cc:32:e5:62:b7:57
45 Jan 18, 2023 20:07:38.735972377 CET 11737497984 cc:32:e5:62:b7:57
48 Jan 18, 2023 20:07:38.838407803 CET 11737600384 cc:32:e5:62:b7:57
51 Jan 18, 2023 20:07:38.940635607 CET 11737702784 cc:32:e5:62:b7:57
70 Jan 18, 2023 20:07:39.043033958 CET 11737805184 cc:32:e5:62:b7:57
204 Jan 18, 2023 20:07:39.147203764 CET 11737909367 cc:32:e5:62:b7:57
...
$ tshark -r notebook_wlan1_channel-1-monitor.pcapng -Y "(wlan.fc.type_subtype == 0x0008 && wlan.bssid == cc:32:e5:62:b7:57)" -T fields -e frame.number -e frame.time -e wlan.fixed.timestamp -e wlan.bssid | tail
25712 Jan 18, 2023 20:09:09.099746234 CET 11827918578 cc:32:e5:62:b7:57
25726 Jan 18, 2023 20:09:09.201172841 CET 11828020020 cc:32:e5:62:b7:57
25791 Jan 18, 2023 20:09:09.405413982 CET 11828224384 cc:32:e5:62:b7:57
25798 Jan 18, 2023 20:09:09.507678013 CET 11828326784 cc:32:e5:62:b7:57
25800 Jan 18, 2023 20:09:09.610083739 CET 11828429184 cc:32:e5:62:b7:57
25802 Jan 18, 2023 20:09:09.712414827 CET 11828531638 cc:32:e5:62:b7:57
25804 Jan 18, 2023 20:09:09.814752811 CET 11828633984 cc:32:e5:62:b7:57
25806 Jan 18, 2023 20:09:09.917091408 CET 11828736384 cc:32:e5:62:b7:57
25808 Jan 18, 2023 20:09:10.019346109 CET 11828838784 cc:32:e5:62:b7:57
25810 Jan 18, 2023 20:09:10.121793676 CET 11828941184 cc:32:e5:62:b7:57
The timestamps are increasing from 11736985984 to 11828941184 (as expected). No indication that the router went down.
Now I'm running out of ideas. All dump files looking fine for me.
The entire analysis took several hours and now I'm really tired. A way too many IP addresses and MAC addresses blinded me and perhaps I have overlooked something. Please re-check "desktop_eth.pcapng" and "notebook_wlan1_channel-1-monitor.pcapng" and tell me the frame number where the ROUTER crashed exactly.
d2:32:e5:62:b7:57
Is this a guest network?
Yes it is, the creepy thing about it is that I have it disabled in the router settings and yet it's always visible somehow.
I believe the commandline for this attack was:
sudo tcpdump -i wlan1 wlan addr1 cc:32:e5:62:b7:57 or wlan addr2 cc:32:e5:62:b7:57 or wlan addr3 cc:32:e5:62:b7:57 or wlan addr1 d2:32:e5:62:b7:57 or wlan addr2 d2:32:e5:62:b7:57 or wlan addr3 d2:32:e5:62:b7:57 or wlan addr3 ff:ff:ff:ff:ff:ff -ddd > attack.bpf
sudo hcxdumptool -i wlan0 --active_beacon --enable_status=15 --bpfc=attack.bpf -o dump.pcapng
Over the entire time the CLIENT (1.3.3.243) was connected to the ROUTER (1.3.3.7).
How can you tell this?
When I look on the desktop_eth.pcap I see that from
8982 2023-01-18 20:04:40.860714 ASUS-W11.local 1.3.3.7 ICMP 74 Echo (ping) request id=0x0001, seq=14873/6458, ttl=128 (no response found!) 2023-01-18 20:04:40.860714
To
9245 2023-01-18 20:06:29.184621 1.3.3.7 ASUS-W11.local ICMP 74 Echo (ping) reply id=0x0001, seq=14902/13882, ttl=64 (request in 9244) 2023-01-18 20:06:29.184621
There was a connection issue that lasted almost 2 minutes.
I still have a lot to learn, but I could bet everything that it is not a client issue at all, I have another router connected to this TP_LINK, and every time when network is down its LED turns orange instead of green, I also lose the network connection on all my phones when this happens, I have encountered this bug for first time over a year ago, but I thought that maybe upgrading router firmware will help and it didn't. I think I have played with aircrack and wifite many times while using that router and only hcxdumptools got this issue, so the old attack mode is not triggering this.
Does this even makes a sense that I have Wireshark running on the destination host, and I see in the Wireshark that the destination is not reachable, lol? Like, isn't this thing standing on a wrong side of a gun to claim such things? It feels like a huge pile of horse**** and some black magic so far.
Good thing is that I've learned a lot already thanks to your analysis, I think I will be back to this issue when I'll get an idea how to get deeper into that router because the frames are kinda lying or not telling the whole story at least, but I feel like maybe you shouldn't waste your valuable time on this because it can be a potentially dead end or an extremely marginal case.
PS.
crash
May not be precise word for what is going on with the router, we just know that it can't be connected and the blackout last about the time it needs to boot, I don't have any uptime statistics in settings unfortunately, idk yet if I can get a decent root shell on it to answer me some important questions, but I will try.
Thanks for all the help, you are awesome!
I forgot to attach the analysis of hcxpcapngtool on the monitor dump file:
$ hcxpcapngtool notebook_wlan1_channel-1-monitor.pcapng -o test.pcapng
hcxpcapngtool 6.2.7-91-gedcb0aa reading from notebook_wlan1_channel-1-monitor.pcapng...
summary capture file
--------------------
file name................................: notebook_wlan1_channel-1-monitor.pcapng
version (pcapng).........................: 1.0
operating system.........................: Linux 6.0.0-kali6-amd64
application..............................: Dumpcap (Wireshark) 4.0.2 (Git v4.0.2 packaged as 4.0.2-1)
interface name...........................: wlan1
interface vendor.........................: 000000
openSSL version..........................: 1.0
weak candidate...........................: N/A
MAC ACCESS POINT.........................: 000000000000 (incremented on every new client)
MAC CLIENT...............................: 000000000000
REPLAYCOUNT..............................: 0
ANONCE...................................: 0000000000000000000000000000000000000000000000000000000000000000
SNONCE...................................: 0000000000000000000000000000000000000000000000000000000000000000
timestamp minimum (GMT)..................: 18.01.2023 19:29:43
timestamp maximum (GMT)..................: 18.01.2023 20:41:17
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11_RADIO (127)
endianess (capture system)...............: little endian
packets inside...........................: 43037
frames with correct FCS..................: 43037
packets received on 2.4 GHz..............: 43037
ESSID (total unique).....................: 5
BEACON (total)...........................: 2848
BEACON on 2.4 GHz channel (from IE_TAG)..: 1 2 3
BEACON (SSID wildcard/unset).............: 1707
ACTION (total)...........................: 6
PROBEREQUEST.............................: 87
PROBEREQUEST (directed)..................: 2
PROBERESPONSE (total)....................: 111
DEAUTHENTICATION (total).................: 5
DISASSOCIATION (total)...................: 5
AUTHENTICATION (total)...................: 19
AUTHENTICATION (OPEN SYSTEM).............: 19
ASSOCIATIONREQUEST (total)...............: 1
ASSOCIATIONREQUEST (PSK).................: 1
REASSOCIATIONREQUEST (total).............: 1
REASSOCIATIONREQUEST (PSK)...............: 1
WPA encrypted............................: 19077
EAPOL messages (total)...................: 15
EAPOL RSN messages.......................: 15
EAPOLTIME gap (measured maximum usec)....: 37652882
EAPOL ANONCE error corrections (NC)......: not detected
REPLAYCOUNT gap (measured maximum).......: 1024
EAPOL M1 messages (total)................: 8
EAPOL M2 messages (total)................: 3
EAPOL M3 messages (total)................: 3
EAPOL M4 messages (total)................: 1
EAPOL pairs (total)......................: 1
EAPOL pairs (best).......................: 1
EAPOL pairs written to 22000 hash file...: 1 (RC checked)
EAPOL M32E2 (authorized).................: 1
Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.
frequency statistics from radiotap header (frequency: received packets)
-----------------------------------------------------------------------
2412: 43037
session summary
---------------
processed pcapng files................: 1
No indication of a DDoS attack. BTW: Timestamps of the monitoring machine are faulty. Now checking the packets you mentioned above.
When I look on the desktop_eth.pcap I see that from
8982 2023-01-18 20:04:40.860714 ASUS-W11.local 1.3.3.7 ICMP 74 Echo (ping) request id=0x0001, seq=14873/6458, ttl=128 (no response found!) 2023-01-18 20:04:40.860714
To
9245 2023-01-18 20:06:29.184621 1.3.3.7 ASUS-W11.local ICMP 74 Echo (ping) reply id=0x0001, seq=14902/13882, ttl=64 (request in 9244) 2023-01-18 20:06:29.184621
"There was a connection issue that lasted almost 2 minutes." Absolutely not. The pings are not responded because your CLIENT produced heavy traffic with several servers in the internet: It is mandatory to take a look at the entire sequence and not on a single packet: packet 8980 to 8982 ping requests and ping responds packet 8983 to 9043 heav internet traffic between your server and internet addresses Packet 9034 a ping request over eth0 to the server, but the server is still to busy to respond due to its internet traffic Packets starting with 8983 the CLIENT started heavy TLS traffic via the server to the internet
Your CLIENT produce heavy internet traffic between to internet addresses. That make the router going BUSY. So, Yes, I'm sure the ROUTER was not down, but it is BUSY from your CLIENT.
BTW: I suggest to investigate what's going on CLIENT side (1.3.3.243). Beside the pings, your CLIENT opened several connections to servers in the internet: 1.1.1.1 (name server) 8.8.8.8 (name server) 162.125.21.2 (dropbox) 104.18.12.173 (cloudflare) 131.253.33.239 (microsoft) - wow, your CLIENT is sending telemetry to microsoft - did you know that?) and later on this ones: 224.0.0.251 and 224.0.0.252 (https://www.pcreview.co.uk/threads/continuous-data-transfer-to-ip-224-0-0-252.3724885/)
8980 19:04:39,853116 1.3.3.243 → 1.3.3.7 ICMP 74 Echo (ping) request id=0x0001, seq=14872/6202, ttl=128
8981 19:04:39,853320 1.3.3.7 → 1.3.3.243 ICMP 74 Echo (ping) reply id=0x0001, seq=14872/6202, ttl=64 (request in 8980)
8982 19:04:40,860714 1.3.3.243 → 1.3.3.7 ICMP 74 Echo (ping) request id=0x0001, seq=14873/6458, ttl=128
8983 19:04:41,805545 1.3.3.243 → 162.125.21.2 TLSv1.2 199 Application Data
8984 19:04:41,805573 1.3.3.243 → 162.125.21.2 TLSv1.2 5046 Application Data
8985 19:04:42,115091 1.3.3.243 → 162.125.21.2 TCP 1494 [TCP Retransmission] 50531 → 443 [PSH, ACK] Seq=13053 Ack=817 Win=1026 Len=1440
8986 19:04:42,163216 1.3.3.243 → 104.18.12.173 TLSv1.2 109 Application Data
8987 19:04:42,163245 1.3.3.243 → 104.18.12.173 TLSv1.2 109 Application Data
8988 19:04:42,163254 1.3.3.243 → 104.18.12.173 TLSv1.2 213 Application Data
8989 19:04:42,163261 1.3.3.243 → 104.18.12.173 TLSv1.2 213 Application Data
8990 19:04:42,169903 1.3.3.243 → 104.18.12.173 TLSv1.2 109 Application Data
8991 19:04:42,169923 1.3.3.243 → 104.18.12.173 TLSv1.2 109 Application Data
8992 19:04:42,169934 1.3.3.243 → 104.18.12.173 TLSv1.2 213 Application Data
8993 19:04:42,169941 1.3.3.243 → 104.18.12.173 TLSv1.2 213 Application Data
8994 19:04:42,239626 1.3.3.243 → 8.8.8.8 QUIC 247 Protected Payload (KP0), DCID=ede5aaefa3d2237d
8995 19:04:42,239705 1.3.3.243 → 8.8.8.8 QUIC 248 Protected Payload (KP0), DCID=ede5aaefa3d2237d
8996 19:04:42,239741 1.3.3.243 → 8.8.8.8 QUIC 249 Protected Payload (KP0), DCID=ede5aaefa3d2237d
8997 19:04:42,239772 1.3.3.243 → 8.8.8.8 QUIC 250 Protected Payload (KP0), DCID=ede5aaefa3d2237d
8998 19:04:42,332358 1.3.3.243 → 8.8.8.8 QUIC 247 Protected Payload (KP0), DCID=ede5aaefa3d2237d
8999 19:04:42,409608 1.3.3.243 → 104.18.12.173 TCP 910 [TCP Retransmission] 24405 → 443 [PSH, ACK] Seq=20332 Ack=51534 Win=1028 Len=856
9000 19:04:42,425233 1.3.3.243 → 162.125.21.2 TCP 1494 [TCP Retransmission] 50531 → 443 [PSH, ACK] Seq=9356 Ack=817 Win=1026 Len=1440
9001 19:04:42,502318 1.3.3.243 → 8.8.8.8 QUIC 248 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9002 19:04:42,579176 1.3.3.243 → 8.8.8.8 UDP 1292 50292 → 443 Len=1250
9003 19:04:42,717899 1.3.3.243 → 104.18.12.173 TCP 910 [TCP Retransmission] 24405 → 443 [PSH, ACK] Seq=20332 Ack=51534 Win=1028 Len=856
9004 19:04:42,842682 1.3.3.243 → 8.8.8.8 QUIC 249 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9005 19:04:42,889730 1.3.3.243 → 8.8.8.8 UDP 1292 50292 → 443 Len=1250
9006 19:04:43,029098 1.3.3.243 → 162.125.21.2 TCP 1494 [TCP Retransmission] 50531 → 443 [PSH, ACK] Seq=9356 Ack=817 Win=1026 Len=1440
9007 19:04:43,199603 1.3.3.243 → 8.8.8.8 UDP 1292 50292 → 443 Len=1250
9008 19:04:43,323584 1.3.3.243 → 104.18.12.173 TCP 910 [TCP Retransmission] 24405 → 443 [PSH, ACK] Seq=20332 Ack=51534 Win=1028 Len=856
9009 19:04:43,432186 1.3.3.243 → 8.8.8.8 QUIC 75 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9010 19:04:43,432232 1.3.3.243 → 8.8.8.8 QUIC 77 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9011 19:04:43,432452 1.3.3.243 → 1.1.1.1 DNS 82 Standard query 0x2535 A femetrics.grammarly.io
9012 19:04:43,432554 1.3.3.243 → 1.1.1.1 DNS 82 Standard query 0x9c70 HTTPS femetrics.grammarly.io
9013 19:04:43,432586 1.3.3.243 → 8.8.8.8 QUIC 75 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9014 19:04:43,432603 1.3.3.243 → 8.8.8.8 QUIC 77 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9015 19:04:43,432653 1.3.3.243 → 8.8.8.8 QUIC 75 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9016 19:04:43,432667 1.3.3.243 → 8.8.8.8 QUIC 77 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9017 19:04:43,432779 1.3.3.243 → 1.1.1.1 DNS 89 Standard query 0xae59 A d27xxe7juh1us6.cloudfront.net
9018 19:04:43,432868 1.3.3.243 → 1.1.1.1 DNS 89 Standard query 0xfeb7 HTTPS d27xxe7juh1us6.cloudfront.net
9019 19:04:43,432897 1.3.3.243 → 8.8.8.8 QUIC 75 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9020 19:04:43,432913 1.3.3.243 → 8.8.8.8 QUIC 77 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9021 19:04:43,432968 1.3.3.243 → 104.18.12.173 TLSv1.2 89 Application Data
9022 19:04:43,432978 1.3.3.243 → 104.18.12.173 TLSv1.2 89 Application Data
9023 19:04:43,432985 1.3.3.243 → 104.18.12.173 TLSv1.2 89 Application Data
9024 19:04:43,432991 1.3.3.243 → 104.18.12.173 TLSv1.2 89 Application Data
9025 19:04:43,494191 1.3.3.243 → 131.253.33.239 TCP 55 [TCP Keep-Alive] 50533 → 443 [ACK] Seq=1 Ack=1 Win=1026 Len=1
9026 19:04:43,509858 1.3.3.243 → 8.8.8.8 QUIC 75 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9027 19:04:44,175854 1.3.3.243 → 8.8.8.8 QUIC 234 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9028 19:04:44,237336 1.3.3.243 → 162.125.21.2 TCP 1494 [TCP Retransmission] 50531 → 443 [PSH, ACK] Seq=9356 Ack=817 Win=1026 Len=1440
9029 19:04:44,454057 1.3.3.243 → 8.8.8.8 DNS 82 Standard query 0x4e4d A femetrics.grammarly.io
9030 19:04:44,454201 1.3.3.243 → 8.8.8.8 DNS 82 Standard query 0xbd3e HTTPS femetrics.grammarly.io
9031 19:04:44,454293 1.3.3.243 → 8.8.8.8 DNS 89 Standard query 0x86f4 A d27xxe7juh1us6.cloudfront.net
9032 19:04:44,454382 1.3.3.243 → 8.8.8.8 DNS 89 Standard query 0x4de4 HTTPS d27xxe7juh1us6.cloudfront.net
9033 19:04:44,531521 1.3.3.243 → 104.18.12.173 TCP 590 [TCP Retransmission] 24405 → 443 [PSH, ACK] Seq=20332 Ack=51534 Win=1028 Len=536
9034 19:04:44,699085 1.3.3.243 → 1.3.3.7 ICMP 74 Echo (ping) request id=0x0001, seq=14874/6714, ttl=128
9035 19:04:45,477212 1.3.3.243 → 8.8.8.8 DNS 82 Standard query 0x01a3 A femetrics.grammarly.io
9036 19:04:45,477352 1.3.3.243 → 1.1.1.1 DNS 82 Standard query 0x676f HTTPS femetrics.grammarly.io
9037 19:04:45,477447 1.3.3.243 → 1.1.1.1 DNS 89 Standard query 0xd1e1 A d27xxe7juh1us6.cloudfront.net
9038 19:04:45,477540 1.3.3.243 → 1.1.1.1 DNS 89 Standard query 0xe573 HTTPS d27xxe7juh1us6.cloudfront.net
9039 19:04:45,477598 1.3.3.243 → 8.8.8.8 QUIC 231 Protected Payload (KP0), DCID=ede5aaefa3d2237d
9040 19:04:45,738984 1.3.3.243 → 104.18.12.173 TCP 590 [TCP Retransmission] 24405 → 443 [PSH, ACK] Seq=20332 Ack=51534 Win=1028 Len=536
9041 19:04:46,639575 1.3.3.243 → 162.125.21.2 TCP 1494 [TCP Retransmission] 50531 → 443 [PSH, ACK] Seq=9356 Ack=817 Win=1026 Len=1440
9042 19:04:46,949464 1.3.3.243 → 104.18.12.173 TCP 1050 [TCP Retransmission] 24405 → 443 [PSH, ACK] Seq=20332 Ack=51534 Win=1028 Len=996
9043 19:04:47,168413 1.3.3.243 → 1.3.3.7 TCP 66 50606 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
And last, but not least I found this: " Archer C6 V2.0(EU) Packet Drop or Ping Loss Issue on Wireless and LAN clients" https://community.tp-link.com/us/home/forum/topic/236036
So, as suspected, definitely not caused by hcxdumptool.
You may have noticed that I changed the headline so that everyone recognizes immediately that hcxdumptool is not running DDoS attacks on ACCESS POINTs.
Nice, you have ignored everything that I said and you are absolutely dead wrong with your conclusions.
Your CLIENT produce heavy internet traffic between to internet addresses. That make the router going BUSY.
So, Yes, I'm sure the ROUTER was not down, but it is BUSY from your CLIENT.
This was not heavy traffic, not even close, this was typical windows 11 traffic with some basic stuff open. When I share Linux distro images I have hundreds more connections for torrents and everything is always stable.
Here you have the same exact thing, with clean Live Distro MX-Linux
Linux mx1 6.0.0-6mx-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.12-1~mx21+1 (2022-12-15) x86_64 GNU/Linux
Somewhere at 327
on desktop.pcapng, no connection.
cleanmxlinux.zip
Brand fresh out of the box, almost no traffic at all just pinging the router.
I could test other kernels and older distros but it is pointless when IMPORTANT PART BEING REPEATED FOURTH TIME RIGHT HERE: the same connectivity issue exists both on Windows and Linux and on every freaking other device in the entire network
It's worth noticing that when the connectivity is lost, dmesg is showing:
[ 2216.217757] r8169 0000:04:00.0 eth0: Link is Down
[ 2230.238233] r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 2240.911885] r8169 0000:04:00.0 eth0: Link is Down
[ 2245.638353] r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 2248.428127] r8169 0000:04:00.0 eth0: Link is Down
[ 2311.618648] r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
So maybe we were kinda both right, my best guess is that this router does something that crashes all the other connected interfaces when the new type of WiFi attack is taking place. I'm sure it is accidental, but it's still by its very definition, a DDoS hence all the other devices in the network can't connect to that router at this time.
Ps.I don't have any random packet drops
.
Ps2. All the security crap like ICMP flood on that router is turned off, and when security functions are triggered then I have alerts in logs, so this is also not the case, just to save you from other wrong conclusions and wasting more time, sir.
Why is local host unreachable?
370 17:02:09,419410543 127.0.0.1 127.0.0.1 ICMP 114 Destination unreachable (Port unreachable)
Why do we have a packet loss?
115 17:00:55,116380783 1.3.3.243 93.184.220.29 TCP 68 [TCP Previous segment not captured] 50768 → 80 [ACK] Seq=2 Ack=1 Win=501 Len=0 TSval=303317381 TSecr=2225880513
Your're absolutely right, hcxdumptool doesn't produce heavy traffic - only a few frames are transmitted:
"no_heavy_traffic_attacker.pcapng"
BTW:
hcxdumptool doesn't record the entire traffic. It only record important packets which are mandatory/useful to recover the PSK.
$ hcxpcapngtool no_heavy_traffic_attacker.pcapng
hcxpcapngtool 6.2.7-91-gedcb0aa reading from no_heavy_traffic_attacker.pcapng...
summary capture file
--------------------
file name................................: no_heavy_traffic_attacker.pcapng
version (pcapng).........................: 1.0
operating system.........................: Linux 6.0.0-kali6-amd64
application..............................: hcxdumptool 6.2.6
interface name...........................: wlan0
interface vendor.........................: 00c0ca
openSSL version..........................: 1.0
weak candidate...........................: 12345678
MAC ACCESS POINT.........................: 001761daa293 (incremented on every new client)
MAC CLIENT...............................: b025aaf89c33
REPLAYCOUNT..............................: 64900
ANONCE...................................: 7100ba3a47728d648eb306dd19627bd4f8b7604f0aa9d8187eda5c78c74a8eb0
SNONCE...................................: 454a0c9b19811800f07310f28fd434ecd4b371a741980ee7cb8538755a439e87
timestamp minimum (GMT)..................: 19.01.2023 18:00:22
timestamp maximum (GMT)..................: 19.01.2023 18:01:22
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11_RADIO (127)
endianess (capture system)...............: little endian
packets inside...........................: 20
frames with correct FCS..................: 20
packets received on 2.4 GHz..............: 20
ESSID (total unique).....................: 2
BEACON (total)...........................: 2
BEACON (SSID wildcard/unset).............: 2
PROBEREQUEST.............................: 2
PROBEREQUEST (directed)..................: 1
PROBERESPONSE (total)....................: 1
AUTHENTICATION (total)...................: 3
AUTHENTICATION (OPEN SYSTEM).............: 3
ASSOCIATIONREQUEST (total)...............: 1
ASSOCIATIONREQUEST (PSK).................: 1
EAPOL messages (total)...................: 8
EAPOL RSN messages.......................: 8
EAPOLTIME gap (measured maximum usec)....: 20195
EAPOL ANONCE error corrections (NC)......: not detected
EAPOL M1 messages (total)................: 5
EAPOL M2 messages (total)................: 1
EAPOL M3 messages (total)................: 1
EAPOL M4 messages (total)................: 1
EAPOL pairs (total)......................: 2
EAPOL pairs (best).......................: 1
EAPOL M32E2 (authorized).................: 1
frequency statistics from radiotap header (frequency: received packets)
-----------------------------------------------------------------------
2412: 4 2422: 10 2427: 6
Please run another test. This time use --silent option
$ sudo hcxdumptool -i INTERFACE --enable_status=63 --silent -o silent.dump
What happens on eth0, now?
I could test other kernels and older distros but it is pointless when
IMPORTANT PART BEING REPEATED FOURTH TIME RIGHT HERE:
the same connectivity issue exists both on Windows and Linux and on every freaking other device in the entire network
You're right, that is pointless, because it happens on the router.
So maybe we were kinda both right, my best guess is that this router does something that crashes all the other connected interfaces when the new type of WiFi attack is taking place.
Definitely not, because the ROUTER and the CLIENT establish a new connection!
17 17:01:22,755136 cc:32:e5:62:b7:57 b4:cd:27:4b:31:a1 802.11 110 Reassociation Response, SN=270, FN=0, Flags=........C
18 17:01:22,760094 cc:32:e5:62:b7:57 b4:cd:27:4b:31:a1 EAPOL 167 Key (Message 1 of 4)
The ROUTER transmit a REASSOCIATION repsonse after the attack, so it is alive. The ROUTER transmit an EAPOL M1 after the attack, so it is still alive.
Now I'll check the monitor dump file from Yesterday again.
The router is alive after the attack and there is traffic between the CLIENT and the ROUTER:
REASSOCIATION in progress: this was initiated by hcxdumptool
9756 19:08:07,498213340 cc:32:e5:62:b7:57 → b4:cd:27:4b:31:a1 802.11 134 Reassociation Response, SN=260, FN=0, Flags=........C
9757 19:08:07,498503843 → cc:32:e5:62:b7:57 (RA) 802.11 70 Acknowledgement, Flags=........C
4way handshake:
9758 19:08:07,499926451 cc:32:e5:62:b7:57 → b4:cd:27:4b:31:a1 EAPOL 191 Key (Message 1 of 4)
9759 19:08:07,500138785 → cc:32:e5:62:b7:57 (RA) 802.11 70 Acknowledgement, Flags=........C
9760 19:08:07,507755519 b4:cd:27:4b:31:a1 → cc:32:e5:62:b7:57 EAPOL 213 Key (Message 2 of 4)
9761 19:08:07,507985223 → b4:cd:27:4b:31:a1 (RA) 802.11 70 Acknowledgement, Flags=........C
9762 19:08:07,510734890 cc:32:e5:62:b7:57 → b4:cd:27:4b:31:a1 EAPOL 247 Key (Message 3 of 4)
9763 19:08:07,510884143 → cc:32:e5:62:b7:57 (RA) 802.11 70 Acknowledgement, Flags=........C
9764 19:08:07,525091705 b4:cd:27:4b:31:a1 → cc:32:e5:62:b7:57 EAPOL 191 Key (Message 4 of 4)
router confirmed M4 from CLIENT:
9765 19:08:07,525281684 → b4:cd:27:4b:31:a1 (RA) 802.11 70 Acknowledgement, Flags=........C
router transmit guest net beacon:
9766 19:08:07,543317793 d2:32:e5:62:b7:57 → ff:ff:ff:ff:ff:ff 802.11 302 Beacon frame, SN=3773, FN=0, Flags=........C, BI=100, SSID=Wildcard (Broadcast)
This is not your network:
9767 19:08:07,561351099 00:23:8e:e0:9c:3a → ff:ff:ff:ff:ff:ff 802.11 175 Beacon frame, SN=2923, FN=0, Flags=........C, BI=100, SSID="NETIA-E09C38"
router transmit beacon:
9768 19:08:07,594581886 cc:32:e5:62:b7:57 → ff:ff:ff:ff:ff:ff 802.11 302 Beacon frame, SN=1429, FN=0, Flags=........C, BI=100, SSID=Wildcard (Broadcast)
9769 19:08:07,596285790 00:20:67:94:1b:d6 → ff:ff:ff:ff:ff:ff 802.11 186 Beacon frame, SN=165, FN=0, Flags=........C, BI=1000, SSID="home"
client transmit data to the router
9770 19:08:07,608226787 b4:cd:27:4b:31:a1 → 33:33:ff:4b:31:a1 802.11 172 Data, SN=45, FN=0, Flags=.p.....TC
router confirmed that it received the data
9771 19:08:07,608447435 → b4:cd:27:4b:31:a1 (RA) 802.11 70 Acknowledgement, Flags=........C
client transmit data to the router
9772 19:08:07,609207023 b4:cd:27:4b:31:a1 → 33:33:ff:4b:31:a1 802.11 172 Data, SN=1430, FN=0, Flags=.p....F.C
client transmit data to the router
9773 19:08:07,625018648 b4:cd:27:4b:31:a1 → 33:33:00:00:00:16 802.11 184 Data, SN=46, FN=0, Flags=.p.....TC
router confirmed that it received the data
9774 19:08:07,625028808 → b4:cd:27:4b:31:a1 (RA) 802.11 70 Acknowledgement, Flags=........C
9775 19:08:07,625997778 b4:cd:27:4b:31:a1 → 33:33:00:00:00:16 802.11 184 Data, SN=1431, FN=0, Flags=.p....F.C
router transmit guest net beacon:
9776 19:08:07,645686357 d2:32:e5:62:b7:57 → ff:ff:ff:ff:ff:ff 802.11 302 Beacon frame, SN=3774, FN=0, Flags=........C, BI=100, SSID=Wildcard (Broadcast)
9777 19:08:07,663657534 00:23:8e:e0:9c:3a → ff:ff:ff:ff:ff:ff 802.11 175 Beacon frame, SN=2924, FN=0, Flags=........C, BI=100, SSID="NETIA-E09C38"
client transmit data to the router
9778 19:08:07,667079740 b4:cd:27:4b:31:a1 → ff:ff:ff:ff:ff:ff 802.11 458 Data, SN=47, FN=0, Flags=.p.....TC
router confirmed that it received the data
9779 19:08:07,667222574 → b4:cd:27:4b:31:a1 (RA) 802.11 70 Acknowledgement, Flags=........C
...
I don't think it necessary to comment more of the following packets...
Straight after the REASSOCIATION data traffic between the AP and the CLIENT is in progress as expected.
So maybe we were kinda both right, my best guess is that this router does something that crashes all the other connected
interfaces when the new type of WiFi attack is taking place. I'm sure it is accidental, but it's still by its very definition, a DDoS
hence all the other devices in the network can't connect to that router at this time.
The CLIENT is connected to the AP and there is data traffic in progress! BEACONs are transmitted by the AP Packets from the CLIENT are confirmed by the AP. Packets from the AP are confirmed by the CLIENT. There is neither an indication that the attack crashed the router nor that there is a DDoS attack.
And this is exactly what I see in the eth0 dump files: https://community.tp-link.com/us/home/forum/topic/236036
--silent
does no harm, no issues.
If you want, I can leave desktop-pc pinging my router for a night, and you won't see a single packet dropped.
Maybe I will check other modes for --enable_status
to nail the one that causes this.
The ROUTER transmit a REASSOCIATION repsonse after the attack, so it is alive.
Yeah but check the dmesg that I've posted
[ 2216.217757] r8169 0000:04:00.0 eth0: Link is Down
[ 2230.238233] r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 2240.911885] r8169 0000:04:00.0 eth0: Link is Down
[ 2245.638353] r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 2248.428127] r8169 0000:04:00.0 eth0: Link is Down
[ 2311.618648] r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Interface is going up and down again, I guess you should see it 3 times exactly and the connection should be stable only after the last one
I can't tell if there are more or less disconnections on windows pc, there is nothing like dmesg there, so maybe you should refer to the .pcapng from today with this.
If you still can't believe it, please add the WiFi key of your network to Wireshark settings and it will decrypt and show you the traffic after the REASSOCIATION: https://wiki.wireshark.org/HowToDecrypt802.11
Regarding this:
[ 2216.217757] r8169 0000:04:00.0 eth0: Link is Down
[ 2230.238233] r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 2240.911885] r8169 0000:04:00.0 eth0: Link is Down
[ 2245.638353] r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 2248.428127] r8169 0000:04:00.0 eth0: Link is Down
[ 2311.618648] r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
This might be helpful, too (looking similar to your comment): https://bbs.archlinux.org/viewtopic.php?id=160175 https://serverfault.com/questions/585442/eth0-nic-link-is-down-repeating-message-in-kernel-log https://ubuntuforums.org/showthread.php?t=1181691 https://community.nxp.com/t5/i-MX-Processors/Repeatedly-getting-quot-Link-is-Up-Link-is-Down-quot-with-L3-0/m-p/270236
Conclusion: The first reported problem is caused by Wireshark and NETLINK (confirmed by dmesg log). The second problem is possible caused by your router (https://community.tp-link.com/us/home/forum/topic/236036). The third problem is possible caused by your router (in this case not a cisco switch) (https://bbs.archlinux.org/viewtopic.php?id=160175).
Everything is pointing to the TP-Link Archer, but you still believe the trouble is caused by hcxdumptool running kind of a DDoS attack on the router.
In that case we have to do some more investigations. Please run an aircrack-ng/aireplay-ng attack on your router and we'll see what will happen.
Just did the old school attack with aircrack-ng without any issues:
airodump-ng -c3 --bssid CC:32:E5:62:B7:57 -w hash
aireplay-ng -0 1 -a CC:32:E5:62:B7:57 -c FF:FF:FF:FF:FF:FF
Hash captured, no packet dropped on other devices.
The first reported problem is caused by Wireshark and NETLINK (confirmed by dmesg log).
Part of it, yes, but remember we have already tested it on my old ralink too!
The second problem is possibly caused by your router (https://community.tp-link.com/us/home/forum/topic/236036).
No, no, there is nothing random about these disconnections. I play mutliplayer games with 5-10ms ping on this pc and this router.
The third problem is possible caused by your router (in this case not a cisco switch), network settings/board switch or a faulty cable (https://bbs.archlinux.org/viewtopic.php?id=160175).
Yes and no, I use high quality fine and expensive cables, they are all short so all my routers have to stand very close to each other, but I'm sure of these cables.
But what bugs me the most, is why it all occurs at once every time I use hcxdumptools with --enable_status=7
or 15
?
After so many tests, this would be the biggest coincidence known to mankind, and you are a strongly analytical person as far as I can tell, so you can't believe in such thing.
But you still believe the trouble is caused by hcxdumptool running kind of a DDoS attack on your router.
Well, potential DDoS is in the scope, we are talking about a bug, but someone may use it offensively too.
If you really don't believe me, and we can't figure out something else to prove that bug is legit here, then I can send you this router for the tests. I think I need a safer and more reliable router anyway. For me, the only thing that is in question here, is if it's the single case, like maybe something physically broken in that router, or if it's a case in every C6v2.
Let me know what do you think, If I can test it in some other ways and prove it to you somehow, or maybe you want your own hands on that router. Cheers.
I'm interesting to figure out what happened. It is not necessary that I have the router. Instead we're doing this: I'll add some debug prints to hcxdumptool and add the modified version here. You compile and run it and we possible get some more information. Now I'm going to prepare the source code for you.
hcxdumptool.c.zip Please donwload this source code Replace hcxdumptool by this version Compile and run it
This version will print an information that it will perform a REASSOCIATION attack, but it doesn't transmit the packets.
The old school attack (send a DEAUTHENTICATION like aircrack-ng) remains untouched on the modified version,
This are the changes of the modified hcxdumptool.c:
In case of WPA1
fprintf(stderr, "hcxdumptool will send REASSOCIATION attack WPA2, but it is disabled\n");
return;
In case of WPA2
fprintf(stderr, "hcxdumptool will send REASSOCIATION attack WPA1, but it is disabled\n");
return;
In case of a REQSSOCIATIONREQUEST of a CLIENT:
fprintf(stderr, "hcxdumptool will send REASSOCIATION RESPONSE attack WPA1/2, but it is disabled\n");
return;
This doesn't affect an AP. But we must be sure that neither a REASSOCIATIONREQUEST packet nor a REASSOCIATIONRESPONSE packet is transmitted over the air.
On all thre cases, hcxdumptool will enter the function of the attack. Than it print a message and return without executing the rest of the function.
--enable_status=7 or 15?
has only an effect which kind of action is displayed by the real time display.
--enable_status=63
will print all information.
hcxdumptool.c.zip If the ROUTER still crashed. Additional we deactivated all ASSOCIATIONREQUEST and ASSOCIATIONRESPONSES. PMKID attacks are now disabled, too.
hcxdumptool.c.zip This is the next step if the ROUTER still crashed. Additional we deactivated all AUTHENTICATIONREQUEST and AUTHENTICATION RESPONSES. Only DEAUTHENTICATION and DISASSOCIATION of a CLIENT is activated. We are now on the same level as aircrack-ng/aireplay-ng.
hcxdumptool.c.zip This is the next step if the ROUTER still crashed. Additional we deactivated all DEAUTHENTICATION and DISASSOCIATION packets.
We are now on the same level as an ACCESS POINT. We transmit BEACONs and we transmit PROBERESPONSEs as every ACCESS POINT. An ACCESS POINT should identify us as another ACCESS POINT on the channel and ignore us.
I am using ALFA AWUS036AC, router TP-Link Archer C6
Pardon me my lack of required knowledge, I'm just a noob trying to learn some wifi security in my home lab, and doing simply
Is causing my router to crash and reboot 8/10 times, I guess it's somewhere about 1673779734.092722 router_ddos.zip
I've noticed also some segfault in dmesg:
I'm not sure what to think about this, this new mode should be non-intrusive, right? Interface is in monitor mode just listening, so I should be kinda invisible to the router, so how can it derail my router so bad?