Archer C6 V2.0(EU) Packet Drop or Ping Loss Issue on Wireless and LAN clients [possible bug in router firmware]

ZerBea / hcxdumptool

Small tool to capture packets from wlan devices.

MIT License

1.82k stars 395 forks source link

Archer C6 V2.0(EU) Packet Drop or Ping Loss Issue on Wireless and LAN clients [possible bug in router firmware] #246

Closed 108806 closed 1 year ago

108806 commented 1 year ago

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

sudo hcxdumptool -o00 router_ddos.pcap -i wlan0 --active_beacon --enable_status=15
(OR)
sudo hcxdumptool -o test.pcapng -i wlan0 --enable_status=1

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:

[ 5595.350634] WARNING: CPU: 14 PID: 63499 at net/wireless/nl80211.c:3722 nl80211_send_chandef+0x179/0x190 [cfg80211]
[ 5595.350687] Modules linked in: nfnetlink_queue nfnetlink_log nfnetlink bluetooth jitterentropy_rng sha512_ssse3 sha512_generic drbg ansi_cprng ecdh_generic ecc nvidia_uvm(PO) btrfs blake2b_generic xor raid6_pq zstd_compress ufs qnx4 hfsplus hfs cdrom minix msdos jfs xfs libcrc32c qrtr sunrpc binfmt_misc nls_ascii nls_cp437 vfat snd_hda_codec_realtek fat snd_hda_codec_generic snd_hda_codec_hdmi 88XXau(O) snd_hda_intel intel_rapl_msr snd_intel_dspcfg intel_rapl_common snd_usb_audio snd_intel_sdw_acpi snd_usbmidi_lib snd_hda_codec snd_rawmidi cfg80211 edac_mce_amd snd_seq_device snd_hda_core mc snd_hwdep kvm_amd snd_pcm eeepc_wmi joydev asus_wmi snd_timer platform_profile battery kvm snd sparse_keymap irqbypass ccp soundcore ledtrig_audio sp5100_tco rfkill sg rng_core watchdog rapl video k10temp pcspkr evdev wmi_bmof acpi_cpufreq vmwgfx drm_ttm_helper ttm nvidia_drm(PO) drm_kms_helper nvidia_modeset(PO) ipmi_devintf ipmi_msghandler nvidia(PO) drm fuse efi_pstore configfs efivarfs ip_tables
[ 5595.350756]  x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt dm_mod hid_generic crc32_pclmul usbhid uas crc32c_intel usb_storage hid sd_mod nvme ghash_clmulni_intel nvme_core t10_pi ahci r8169 xhci_pci libahci realtek aesni_intel xhci_hcd crypto_simd crc64_rocksoft_generic mdio_devres libata crc64_rocksoft cryptd i2c_piix4 crc_t10dif crct10dif_generic scsi_mod libphy usbcore crct10dif_pclmul crc64 scsi_common usb_common crct10dif_common wmi gpio_amdpt gpio_generic button
[ 5595.350794] CPU: 14 PID: 63499 Comm: wireshark Tainted: P        W  O       6.0.0-kali6-amd64 #1  Debian 6.0.12-1kali1
[ 5595.350797] Hardware name: ASUS System Product Name/TUF GAMING B450-PLUS II, BIOS 3211 08/10/2021
[ 5595.350799] RIP: 0010:nl80211_send_chandef+0x179/0x190 [cfg80211]
[ 5595.350844] Code: 00 00 be a1 00 00 00 48 89 ef 89 44 24 04 e8 ee 0b 87 cb 85 c0 0f 84 77 ff ff ff 41 bc 97 ff ff ff e9 6c ff ff ff 31 c0 eb a7 <0f> 0b 41 bc ea ff ff ff e9 5b ff ff ff e8 f5 68 d0 cb 0f 1f 44 00
[ 5595.350847] RSP: 0018:ffffb765ce39f958 EFLAGS: 00010246
[ 5595.350849] RAX: 0000000000000000 RBX: ffffb765ce39f9b0 RCX: 000000000025e720
[ 5595.350851] RDX: 00000000000009b4 RSI: 000000000025e720 RDI: 0000000000000000
[ 5595.350853] RBP: ffff913e018b4b00 R08: ffff913c65ef7be8 R09: ffff913c65ef7ba8
[ 5595.350854] R10: ffff913c65d044d8 R11: 000000000000000e R12: ffff913c65d04000
[ 5595.350855] R13: ffffb765ce39f9b0 R14: 0000000000000000 R15: ffff913c65d043a0
[ 5595.350857] FS:  00007fb28a538a80(0000) GS:ffff91434eb80000(0000) knlGS:0000000000000000
[ 5595.350859] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 5595.350861] CR2: 00007fc2c24d8030 CR3: 0000000335714000 CR4: 0000000000350ee0
[ 5595.350863] Call Trace:
[ 5595.350866]  <TASK>
[ 5595.350869]  nl80211_send_iface+0x7fe/0x840 [cfg80211]
[ 5595.350915]  ? __kmalloc_node_track_caller+0x152/0x3b0
[ 5595.350920]  ? __alloc_skb+0xec/0x1c0
[ 5595.350925]  nl80211_get_interface+0x4b/0xa0 [cfg80211]
[ 5595.350970]  genl_family_rcv_msg_doit+0x100/0x160
[ 5595.350975]  genl_rcv_msg+0xee/0x1e0
[ 5595.350978]  ? nl80211_dump_interface+0x1e0/0x1e0 [cfg80211]
[ 5595.351021]  ? nl80211_send_iface+0x840/0x840 [cfg80211]
[ 5595.351064]  ? genl_get_cmd+0xe0/0xe0
[ 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
[ 5595.351079]  sock_sendmsg+0x5f/0x70
[ 5595.351083]  ____sys_sendmsg+0x267/0x2b0
[ 5595.351086]  ? copy_msghdr_from_user+0x7d/0xc0
[ 5595.351090]  ___sys_sendmsg+0x9a/0xe0
[ 5595.351098]  __sys_sendmsg+0x76/0xc0
[ 5595.351103]  do_syscall_64+0x3a/0xc0
[ 5595.351107]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 5595.351111] RIP: 0033:0x7fb28df299bd
[ 5595.351113] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 9a ac f7 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 ee ac f7 ff 48
[ 5595.351115] RSP: 002b:00007fff6d07ffa0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
[ 5595.351118] RAX: ffffffffffffffda RBX: 00005587d620de90 RCX: 00007fb28df299bd
[ 5595.351120] RDX: 0000000000000000 RSI: 00007fff6d080000 RDI: 000000000000000d
[ 5595.351121] RBP: 00005587da026c50 R08: 0000000000000000 R09: 0000000000000000
[ 5595.351122] R10: 0000000000000010 R11: 0000000000000293 R12: 00005587d620dda0
[ 5595.351124] R13: 00007fff6d080000 R14: 0000000000000003 R15: 00007fff6d0801d1
[ 5595.351127]  </TASK>
[ 5595.351128] ---[ end trace 0000000000000000 ]---
[ 5628.811846] r8169 0000:04:00.0 eth0: Link is Down
[ 5643.007013] r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 5654.873337] r8169 0000:04:00.0 eth0: Link is Down
[ 5655.074695] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 5659.656442] r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 5660.328093] r8169 0000:04:00.0 eth0: Link is Down
[ 5723.958939] r8169 0000:04:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 5825.911405] device eth0 entered promiscuous mode
[ 5825.951535] device eth0 left promiscuous mode
[ 7243.509387] systemd-journald[10083]: Time jumped backwards, rotating.
[ 7245.592935] time-admin[123990]: segfault at 8 ip 000055fb68b4a9d0 sp 00007ffdf8274f08 error 4 in time-admin[55fb68b43000+d000]
[ 7245.592965] Code: 40 00 48 89 ef e8 80 f4 ff ff 48 89 ef 4c 89 e6 e8 05 fb ff ff 48 83 c4 08 4c 89 e7 5d 41 5c e9 c6 9e ff ff 66 0f 1f 44 00 00 <f2> 0f 10 47 08 f2 0f 11 06 f2 0f 10 47 10 f2 0f 11 02 c3 66 66 2e
[ 7381.633644] systemd-journald[10083]: Time jumped backwards, rotating.

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?

ZerBea commented 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:

Broadcom (neither monitor mode nor frame injection)
Intel PRO/Wireless (several driver issues and NETLINK dependency)
Realtek (driver chaos - some drivers working, some not, monitor mode and frame injection mostly only on third party drivers, often no ioctl() system call support, NETLINK dependency)
Atheros (some driver problems on older kernels) [/code]

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

ZerBea commented 1 year ago

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

ZerBea commented 1 year ago

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

108806 commented 1 year ago

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.

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

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

108806 commented 1 year ago

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?

ZerBea commented 1 year ago

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

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

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

108806 commented 1 year ago

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

ZerBea commented 1 year ago

Looks like you're not the only one having a problem on 6.0.0-kali6-amd64.

108806 commented 1 year ago

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.

ZerBea commented 1 year ago

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

ZerBea commented 1 year ago

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

ZerBea commented 1 year ago

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.

108806 commented 1 year ago

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.

ZerBea commented 1 year ago

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.

108806 commented 1 year ago

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.

ZerBea commented 1 year ago

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

ZerBea commented 1 year ago

BTW: Can you please comment the command line and the content of filterlist_ap you have used?

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

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.

108806 commented 1 year ago

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!

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

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

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

You may have noticed that I changed the headline so that everyone recognizes immediately that hcxdumptool is not running DDoS attacks on ACCESS POINTs.

108806 commented 1 year ago

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.

ZerBea commented 1 year ago

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?

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

And this is exactly what I see in the eth0 dump files: https://community.tp-link.com/us/home/forum/topic/236036

108806 commented 1 year ago

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

108806 commented 1 year ago

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

108806 commented 1 year ago

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.

ZerBea commented 1 year ago

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

ZerBea commented 1 year ago

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

ZerBea commented 1 year ago

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.

108806 commented 1 year ago

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.

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

The old school attack (send a DEAUTHENTICATION like aircrack-ng) remains untouched on the modified version,

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

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

ZerBea commented 1 year ago

hcxdumptool.c.zip If the ROUTER still crashed. Additional we deactivated all ASSOCIATIONREQUEST and ASSOCIATIONRESPONSES. PMKID attacks are now disabled, too.

ZerBea commented 1 year ago

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.

ZerBea commented 1 year ago

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.