RTL8812AU driver (not recommended to be used in combination with hcxdumptool) crashed NETLINK and ETH0

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<PHONE_NUMBER>.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:<PHONE_NUMBER>000000 RBX: ffffb765ce39f9b0 RCX:<PHONE_NUMBER>25e720
[ 5595.350851] RDX:<PHONE_NUMBER>0009b4 RSI:<PHONE_NUMBER>25e720 RDI:<PHONE_NUMBER>000000
[ 5595.350853] RBP: ffff913e018b4b00 R08: ffff913c65ef7be8 R09: ffff913c65ef7ba8
[ 5595.350854] R10: ffff913c65d044d8 R11:<PHONE_NUMBER>00000e R12: ffff913c65d04000
[ 5595.350855] R13: ffffb765ce39f9b0 R14:<PHONE_NUMBER>000000 R15: ffff913c65d043a0
[ 5595.350857] FS:  00007fb28a538a80(0000) GS:ffff91434eb80000(0000) knlGS:0000000000000000
[ 5595.350859] CS:  0010 DS: 0000 ES: 0000 CR0:<PHONE_NUMBER>050033
[ 5595.350861] CR2: 00007fc2c24d8030 CR3:<PHONE_NUMBER>714000 CR4:<PHONE_NUMBER>350ee0
[ 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:<PHONE_NUMBER>00002e
[ 5595.351118] RAX: ffffffffffffffda RBX: 00005587d620de90 RCX: 00007fb28df299bd
[ 5595.351120] RDX:<PHONE_NUMBER>000000 RSI: 00007fff6d080000 RDI:<PHONE_NUMBER>00000d
[ 5595.351121] RBP: 00005587da026c50 R08:<PHONE_NUMBER>000000 R09:<PHONE_NUMBER>000000
[ 5595.351122] R10:<PHONE_NUMBER>000010 R11:<PHONE_NUMBER>000293 R12: 00005587d620dda0
[ 5595.351124] R13: 00007fff6d080000 R14:<PHONE_NUMBER>000003 R15: 00007fff6d0801d1
[ 5595.351127]  </TASK>
[ 5595.351128] ---[ end trace<PHONE_NUMBER>000000 ]---
[ 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?

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).
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 REQSSOCIATION 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 is 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 interact with this 2 APs.
Please notice that:
hcxdumptool still act as a passive dumper. If another AP transmit a 4way handshake, hcxdumptool will receive and show it
hcxdumptool also 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 watch 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.
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
$ 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
only frames that have this BSSID MAC in addr1, addr2 or addr3 are attacked

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

You pinged <IP_ADDRESS> and not the IP of your router.
After this query the router told you that the query to <IP_ADDRESS> (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: <IP_ADDRESS>, Dst: <IP_ADDRESS>
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 DISACCOCIATION 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)

Additional there is a successful attack on the CLIENT:
$ 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

Analysis of eth0 follow....

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

I also checked the timestamps of the BEACON field of the ROUTER.  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 (<IP_ADDRESS>) was connected to the ROUTER (<IP_ADDRESS>).
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	<IP_ADDRESS>	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	<IP_ADDRESS>	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?

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.........................:<PHONE_NUMBER>00 (incremented on every new client)
MAC CLIENT...............................:<PHONE_NUMBER>00
REPLAYCOUNT..............................: 0
ANONCE...................................:<PHONE_NUMBER>000000000000000000000000000000000000000000000000000000
SNONCE...................................:<PHONE_NUMBER>000000000000000000000000000000000000000000000000000000
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	<IP_ADDRESS>	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	<IP_ADDRESS>	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 router produced heavy traffic with a server in the internet:
It is mandatory to take a look at the entire sequence and not on a single packet:
packet 8980 to 8982 pning 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
Heavy internet traffic between the CLIENT and the addresses in internet.
Heavy internet traffic between the ROUTER and the addresses in internet.
So, Yes, I'm sure the ROUTER was not down. It looks like the the ROUTER doesn't have the time (or is too slow) to respond to pings.
 8980 19:04:39,853116    <IP_ADDRESS> → <IP_ADDRESS>      ICMP 74 Echo (ping) request  id=0x0001, seq=14872/6202, ttl=128
 8981 19:04:39,853320      <IP_ADDRESS> → <IP_ADDRESS>    ICMP 74 Echo (ping) reply    id=0x0001, seq=14872/6202, ttl=64 (request in 8980)
 8982 19:04:40,860714    <IP_ADDRESS> → <IP_ADDRESS>      ICMP 74 Echo (ping) request  id=0x0001, seq=14873/6458, ttl=128
 8983 19:04:41,805545    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 199 Application Data
 8984 19:04:41,805573    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 5046 Application Data
 8985 19:04:42,115091    <IP_ADDRESS> → <IP_ADDRESS> TCP 1494 [TCP Retransmission] 50531 → 443 [PSH, ACK] Seq=13053 Ack=817 Win=1026 Len=1440
 8986 19:04:42,163216    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 109 Application Data
 8987 19:04:42,163245    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 109 Application Data
 8988 19:04:42,163254    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 213 Application Data
 8989 19:04:42,163261    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 213 Application Data
 8990 19:04:42,169903    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 109 Application Data
 8991 19:04:42,169923    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 109 Application Data
 8992 19:04:42,169934    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 213 Application Data
 8993 19:04:42,169941    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 213 Application Data
 8994 19:04:42,239626    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 247 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 8995 19:04:42,239705    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 248 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 8996 19:04:42,239741    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 249 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 8997 19:04:42,239772    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 250 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 8998 19:04:42,332358    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 247 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 8999 19:04:42,409608    <IP_ADDRESS> → <IP_ADDRESS> TCP 910 [TCP Retransmission] 24405 → 443 [PSH, ACK] Seq=20332 Ack=51534 Win=1028 Len=856
 9000 19:04:42,425233    <IP_ADDRESS> → <IP_ADDRESS> TCP 1494 [TCP Retransmission] 50531 → 443 [PSH, ACK] Seq=9356 Ack=817 Win=1026 Len=1440
 9001 19:04:42,502318    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 248 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9002 19:04:42,579176    <IP_ADDRESS> → <IP_ADDRESS>      UDP 1292 50292 → 443 Len=1250
 9003 19:04:42,717899    <IP_ADDRESS> → <IP_ADDRESS> TCP 910 [TCP Retransmission] 24405 → 443 [PSH, ACK] Seq=20332 Ack=51534 Win=1028 Len=856
 9004 19:04:42,842682    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 249 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9005 19:04:42,889730    <IP_ADDRESS> → <IP_ADDRESS>      UDP 1292 50292 → 443 Len=1250
 9006 19:04:43,029098    <IP_ADDRESS> → <IP_ADDRESS> TCP 1494 [TCP Retransmission] 50531 → 443 [PSH, ACK] Seq=9356 Ack=817 Win=1026 Len=1440
 9007 19:04:43,199603    <IP_ADDRESS> → <IP_ADDRESS>      UDP 1292 50292 → 443 Len=1250
 9008 19:04:43,323584    <IP_ADDRESS> → <IP_ADDRESS> TCP 910 [TCP Retransmission] 24405 → 443 [PSH, ACK] Seq=20332 Ack=51534 Win=1028 Len=856
 9009 19:04:43,432186    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 75 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9010 19:04:43,432232    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 77 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9011 19:04:43,432452    <IP_ADDRESS> → <IP_ADDRESS>      DNS 82 Standard query 0x2535 A femetrics.grammarly.io
 9012 19:04:43,432554    <IP_ADDRESS> → <IP_ADDRESS>      DNS 82 Standard query 0x9c70 HTTPS femetrics.grammarly.io
 9013 19:04:43,432586    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 75 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9014 19:04:43,432603    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 77 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9015 19:04:43,432653    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 75 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9016 19:04:43,432667    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 77 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9017 19:04:43,432779    <IP_ADDRESS> → <IP_ADDRESS>      DNS 89 Standard query 0xae59 A d27xxe7juh1us6.cloudfront.net
 9018 19:04:43,432868    <IP_ADDRESS> → <IP_ADDRESS>      DNS 89 Standard query 0xfeb7 HTTPS d27xxe7juh1us6.cloudfront.net
 9019 19:04:43,432897    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 75 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9020 19:04:43,432913    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 77 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9021 19:04:43,432968    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 89 Application Data
 9022 19:04:43,432978    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 89 Application Data
 9023 19:04:43,432985    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 89 Application Data
 9024 19:04:43,432991    <IP_ADDRESS> → <IP_ADDRESS> TLSv1.2 89 Application Data
 9025 19:04:43,494191    <IP_ADDRESS> → <IP_ADDRESS> TCP 55 [TCP Keep-Alive] 50533 → 443 [ACK] Seq=1 Ack=1 Win=1026 Len=1
 9026 19:04:43,509858    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 75 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9027 19:04:44,175854    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 234 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9028 19:04:44,237336    <IP_ADDRESS> → <IP_ADDRESS> TCP 1494 [TCP Retransmission] 50531 → 443 [PSH, ACK] Seq=9356 Ack=817 Win=1026 Len=1440
 9029 19:04:44,454057    <IP_ADDRESS> → <IP_ADDRESS>      DNS 82 Standard query 0x4e4d A femetrics.grammarly.io
 9030 19:04:44,454201    <IP_ADDRESS> → <IP_ADDRESS>      DNS 82 Standard query 0xbd3e HTTPS femetrics.grammarly.io
 9031 19:04:44,454293    <IP_ADDRESS> → <IP_ADDRESS>      DNS 89 Standard query 0x86f4 A d27xxe7juh1us6.cloudfront.net
 9032 19:04:44,454382    <IP_ADDRESS> → <IP_ADDRESS>      DNS 89 Standard query 0x4de4 HTTPS d27xxe7juh1us6.cloudfront.net
 9033 19:04:44,531521    <IP_ADDRESS> → <IP_ADDRESS> TCP 590 [TCP Retransmission] 24405 → 443 [PSH, ACK] Seq=20332 Ack=51534 Win=1028 Len=536
 9034 19:04:44,699085    <IP_ADDRESS> → <IP_ADDRESS>      ICMP 74 Echo (ping) request  id=0x0001, seq=14874/6714, ttl=128
 9035 19:04:45,477212    <IP_ADDRESS> → <IP_ADDRESS>      DNS 82 Standard query 0x01a3 A femetrics.grammarly.io
 9036 19:04:45,477352    <IP_ADDRESS> → <IP_ADDRESS>      DNS 82 Standard query 0x676f HTTPS femetrics.grammarly.io
 9037 19:04:45,477447    <IP_ADDRESS> → <IP_ADDRESS>      DNS 89 Standard query 0xd1e1 A d27xxe7juh1us6.cloudfront.net
 9038 19:04:45,477540    <IP_ADDRESS> → <IP_ADDRESS>      DNS 89 Standard query 0xe573 HTTPS d27xxe7juh1us6.cloudfront.net
 9039 19:04:45,477598    <IP_ADDRESS> → <IP_ADDRESS>      QUIC 231 Protected Payload (KP0), DCID=ede5aaefa3d2237d
 9040 19:04:45,738984    <IP_ADDRESS> → <IP_ADDRESS> TCP 590 [TCP Retransmission] 24405 → 443 [PSH, ACK] Seq=20332 Ack=51534 Win=1028 Len=536
 9041 19:04:46,639575    <IP_ADDRESS> → <IP_ADDRESS> TCP 1494 [TCP Retransmission] 50531 → 443 [PSH, ACK] Seq=9356 Ack=817 Win=1026 Len=1440
 9042 19:04:46,949464    <IP_ADDRESS> → <IP_ADDRESS> TCP 1050 [TCP Retransmission] 24405 → 443 [PSH, ACK] Seq=20332 Ack=51534 Win=1028 Len=996
 9043 19:04:47,168413    <IP_ADDRESS> → <IP_ADDRESS>      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 a problem of the router.

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

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	<IP_ADDRESS>	<IP_ADDRESS>	ICMP	114	Destination unreachable (Port unreachable)
Why do we have a packet loss?
115	17:00:55,116380783	<IP_ADDRESS>	<IP_ADDRESS>	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 neither produce heavy traffic nor it record the entire traffic:
"no_heavy_traffic_attacker.pcapng"
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

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

That doesn't make sense, 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:
 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)
 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 trasnmit 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

There is no indication that the attack crashed the router and there is no indication of 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.

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 ok only after the last one

I can't tell if there are more or less disconnections on windows pc, there are nothing like dmesg there, so maybe you should refer to the .pcapng from today with this.

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 the firmware of your router (link attached above).
The third problem is caused by network settings /board switch or a faulty cable (links attached above).
But you still believe the trouble is caused by hcxdumptool running kind of a DDoS attack on your router.

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

hcxdumptool will enter the function of the attack. Than it print a message and return without executing the rest of the function:
create attack packet
transmit attack packet

--enable_status=7 or 15?
has only an effect which kind of action is displayed by the real time display.

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.
Now only DEAUTHENTICATION and DISASSOCIATION of a CLIENT is activated.

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.

All good at first shot, no crash.
phase1.zip
└─$ sudo ./hcxdumptool -i wlan1 --active_beacon --enable_status=63 --bpfc=attack.bpf -o phase1.pcapng
initialization of hcxdumptool 6.2.7-45-g9bb7542 (depending on the capabilities of the device, this may take some time)...

start capturing (stop with ctrl+c)
NMEA 0183 PROTOCOL........: N/A
PHYSICAL INTERFACE........: phy3
INTERFACE NAME............: wlan1
INTERFACE PROTOCOL........: unassociated
INTERFACE TX POWER........: 0 dBm (lowest value reported by the device)
INTERFACE HARDWARE MAC....: 00c0cab018d5 (not used for the attack)
INTERFACE VIRTUAL MAC.....: 00c0cab018d5 (not used for the attack)
DRIVER....................: rtl88XXau (this driver is not recommended - expect driver errors)
DRIVER VERSION............: 6.0.0-kali6-amd64
DRIVER FIRMWARE VERSION...:
openSSL version...........: 1.0
ERRORMAX..................: 100 errors
BPF code blocks...........: 60
FILTERLIST ACCESS POINT...: 0 entries
FILTERLIST CLIENT.........: 0 entries
FILTERMODE................: unused
WEAK CANDIDATE............: 12345678
ESSID list................: 0 entries
ACCESS POINT (ROGUE)......: 0025df45d32b (BROADCAST WILDCARD used for the attack)
ACCESS POINT (ROGUE)......: 0025df45d32c (BROADCAST OPEN used for the attack)
ACCESS POINT (ROGUE)......: 0025df45d32d (used for the attack and incremented on every new client)
CLIENT (ROGUE)............: e00db9a67887

EAPOLTIMEOUT..............: 20000 usec
EAPOLEAPTIMEOUT...........: 2500000 usec
REPLAYCOUNT...............: 62794
ANONCE....................:<PHONE_NUMBER>b706fae3f75b943c0d83d687e1296bd5c60ccbc703dd38f6e7c2fe
SNONCE....................: 0adca86200b7687086141b945ecc7c850109d50fa2db416f43a3981b45f93fc9

TIME     FREQ/CH  MAC_DEST     MAC_SOURCE   ESSID [FRAME TYPE]
23:39:15 2412/1   ffffffffffff d232e562b757 [WILDCARD BEACON]
23:39:15 2412/1   ffffffffffff cc32e562b757 [WILDCARD BEACON]
23:39:50 2421/2   daa1191ce829 0025df45d32e /'"''' [ROGUE PROBERESPONSE]
23:39:50 2421/2   daa1191ce829 cc32e562b757 /'"''' [PROBERESPONSE]
hcxdumptool will send REASSOCIATION attack WPA2, but it is disabled
hcxdumptool will send REASSOCIATION attack WPA2, but it is disabled
hcxdumptool will send REASSOCIATION attack WPA2, but it is disabled
23:40:02 2424/3   b4cd274b31a1 cc32e562b757 /'"''' [ROGUE PROBERESPONSE]
23:40:02 2424/3   b4cd274b31a1 cc32e562b757 /'"''' [AUTHENTICATION]
23:40:02 2424/3   b4cd274b31a1 cc32e562b757 /'"''' [ASSOCIATION]
23:40:02 2424/3   b4cd274b31a1 cc32e562b757 /'"''' [EAPOL:M1M2ROGUE EAPOLTIME:3128 RC:62794 KDV:2]
23:40:02 2424/3   b4cd274b31a1 cc32e562b757 /'"''' [EAPOL:M1M2 EAPOLTIME:16459 RC:1 KDV:2]
23:40:02 2424/3   b4cd274b31a1 cc32e562b757 /'"''' [EAPOL:M2M3 EAPOLTIME:1928 RC:2 KDV:2]
23:40:02 2424/3   b4cd274b31a1 cc32e562b757 /'"''' [EAPOL:M3M4ZEROED EAPOLTIME:2916 RC:2 KDV:2]
hcxdumptool will send REASSOCIATION attack WPA2, but it is disabled
hcxdumptool will send REASSOCIATION attack WPA2, but it is disabled
23:40:14 2427/4   b4cd274b31a1 cc32e562b757 /'"''' [EAPOL:M1M2 EAPOLTIME:16545 RC:1 KDV:2]
23:40:14 2427/4   b4cd274b31a1 cc32e562b757 /'"''' [EAPOL:M2M3 EAPOLTIME:11352 RC:2 KDV:2]
23:40:14 2427/4   b4cd274b31a1 cc32e562b757 /'"''' [EAPOL:M3M4ZEROED EAPOLTIME:3066 RC:2 KDV:2]

Also no issues with enable_status=15, but i'm a bit lost in that huge wall of code so idk why it is not printing any debug msg, I see changes at lines 1600, 1655, 1705, but I don't see how it affects mode 15 differently than 63, or maybe I'm just too tired today, anyway:
$ sudo ./hcxdumptool -i wlan1 --active_beacon --enable_status=15 --bpfc=attack.bpf -o phase1_m15.pcapng
initialization of hcxdumptool 6.2.7-45-g9bb7542 (depending on the capabilities of the device, this may take some time)...

start capturing (stop with ctrl+c)
NMEA 0183 PROTOCOL........: N/A
PHYSICAL INTERFACE........: phy3
INTERFACE NAME............: wlan1
INTERFACE PROTOCOL........: unassociated
INTERFACE TX POWER........: 0 dBm (lowest value reported by the device)
INTERFACE HARDWARE MAC....: 00c0cab018d5 (not used for the attack)
INTERFACE VIRTUAL MAC.....: 00c0cab018d5 (not used for the attack)
DRIVER....................: rtl88XXau (this driver is not recommended - expect driver errors)
DRIVER VERSION............: 6.0.0-kali6-amd64
DRIVER FIRMWARE VERSION...:
openSSL version...........: 1.0
ERRORMAX..................: 100 errors
BPF code blocks...........: 60
FILTERLIST ACCESS POINT...: 0 entries
FILTERLIST CLIENT.........: 0 entries
FILTERMODE................: unused
WEAK CANDIDATE............: 12345678
ESSID list................: 0 entries
ACCESS POINT (ROGUE)......: 0418b6b1743b (BROADCAST WILDCARD used for the attack)
ACCESS POINT (ROGUE)......: 0418b6b1743c (BROADCAST OPEN used for the attack)
ACCESS POINT (ROGUE)......: 0418b6b1743d (used for the attack and incremented on every new client)
CLIENT (ROGUE)............: e00db92fcff3
EAPOLTIMEOUT..............: 20000 usec
EAPOLEAPTIMEOUT...........: 2500000 usec
REPLAYCOUNT...............: 64354
ANONCE....................: 456909bcf4a43c3139d683d18683327452dfc64d8f511666283584fd61fd1c8c
SNONCE....................: 38e769727316a41a2566c7535a721af75dda9c3b71cc03cebc2b878b8294f1ed

TIME     FREQ/CH  MAC_DEST     MAC_SOURCE   ESSID [FRAME TYPE]
23:46:01 2412/1   ffffffffffff cc32e562b757 [WILDCARD BEACON]
23:46:01 2412/1   ffffffffffff d232e562b757 [WILDCARD BEACON]
23:46:10 2414/1   daa119aaa7b2 cc32e562b757 /'"''' [PROBERESPONSE]
23:46:21 2417/2   b4cd274b31a1 cc32e562b757 /'"''' [AUTHENTICATION]
23:46:21 2417/2   b4cd274b31a1 cc32e562b757 /'"''' [ASSOCIATION]
23:46:21 2417/2   b4cd274b31a1 cc32e562b757 /'"''' [EAPOL:M1M2ROGUE EAPOLTIME:1628 RC:64354 KDV:2]
23:46:22 2417/2   b4cd274b31a1 cc32e562b757 /'"''' [EAPOL:M2M3 EAPOLTIME:4229 RC:2 KDV:2]

Ok, thanks.
enable_status doesn't have any effect. It only print less or more messages.
The debug messages going to stderr and are always print.
The REASSOCIATION attack is divided into 2 parts:
REASSOCIATION using BROADCAST address
REASSOCIATION using AP MAC
I'll add some new code to narrow it down.

hcxdumptool.c.zip
Ok, inside the phase 1 dumpfile I can't see a REASSOCIATIONRESPONSE coming from your router. That is expected, because we disabled it.
Now we enable the REASSOCIATION attack as follows:
if(memcmp(zeiger->ap, mac_broadcast, 6) == 0)
	{
	fprintf(stderr, "hcxdumptool will send REASSOCIATIONREQUEST to broadcast - but it is not transmitted\n");
	}
else fprintf(stderr, "hcxdumptool now transmit a REASSOCIATIONREQUEST using the MAC ADDRESS of the AP\n");

Do not transmit REASSOCIATIONREQUESTs using a BRADCAST MAC as source address (ffffffffffff)
but transmit REASSOCIATIONREQUESTs using the AP MAC as source address
Explanation:
Usually absolutely no ACCESS POINT should accept packets coming from a BROADCAST MAC.
If it doesn't disregard this packets, we found a firmware bug inside the ROUTER firmware, which hcxdumptool will use to force a handshake. I've never seen this before. But exactly this is hcxdumptool designed for: Analysis and detection of weak points.
All messages are printed to stderr, enable_status has no affect on them.

hcxdumptool.c.zip
This is vice versa.
if(memcmp(zeiger->client, mac_broadcast, 6) != 0)
	{
	fprintf(stderr, "hcxdumptool will send REASSOCIATIONREQUEST using CLIENT MAC as source address - but it is not transmitted\n");
	return;
	}
else fprintf(stderr, "hcxdumptool now transmit a REASSOCIATIONREQUEST using BROADCAST MAC as source address\n");

Now hcxdumptool transmit a REASSOCIATION using the BROADCAST MAC.
If the ROUTER crashed, it is a firmware bug - APs should disregard packets coming from BROADCAST.

I changed the headline again.
In the meantime I tested some other ACCESSPOINTs.
case 1: REASSOCIATION frames coming from BRAODCAST MAC ffffffffffff
some ACCESS POINTs ignore them
some ACCESS POINTs respond, but set BRAODCAST MAC ffffffffffff to non BROADCAST MAC efffffffffff
case2: REASSOCIATION frames coming from MAC CLIENT
all tested ACCESS POINTs respond with REASSOCIATIONRESPONSE and initiated 4way handshake
none of them became inaccessible
Perhaps we discovered a bug in the firmware which possible caused this:
https://community.tp-link.com/us/home/forum/topic/236036
For me it looks like the router disconnect and reconnect all CLIENTs if it received a REASSOCIATIONREQUEST. That lead to a timeout and/or a packet drop/packet loss.
We can see that in all logs. Also you should notice that when pinging the router:
"request timeout" or "destination unreachable/network unreachable"
Everything should be fine, after all CLIENTs are reconnected by the router.
BTW:
Discovering weak points and analyzing them is the main purpose of hcxdumptool/hcxtools. Therefore it is designed.

A got two more APs:
TP-Link TD-W8961NB
D-Link Dl-624+
Both off them respond to a REASSOCIATIONREQUEST but they will not crash.

I commented this on hashcat forum, too:
https://hashcat.net/forum/thread-11212-post-57419.html#pid57419
Maybe somebody can confirm this behavior on other models, too.

I got the first response:
TP-Link AX5400 Wi-Fi 6 Router -> no such observations

I received some more links regarding this problem:
https://forums.tomshardware.com/threads/tplink-archer-c6-us-internet-issues.3715199/
https://www.reddit.com/r/HomeNetworking/comments/kozwah/packet_loss_with_new_router_but_family_says_it/
https://www.reddit.com/r/apexlegends/comments/hdkz8x/is_there_a_fix_for_tplink_router_high_latency_and/
https://www.techpowerup.com/forums/threads/solved-2-4ghz-ping-spikes-packet-loss-on-tp-link-archer-c5-v2-ac1200-router.230722/
https://forums.tomshardware.com/threads/tp-link-archer-c80-router-with-internet-drops.3715809/

BTW:
If we can confirm that hcxdumptool caused this, it would be great (not a bug), because the tool did exactly what it has been designed for (README.md main section):
Small tool to capture packets from wlan devices and to discover potential weak points within own WiFi networks
We got a new weak point!

I received some more responds reporting ACCESS POINTs that are not affected, e.g. this linksy ACCESS POINT:
https://hashcat.net/forum/thread-11212-post-57422.html#pid57422
Before we proceed with the next steps (I'm still interested in what caused that exactly), may I ask a question (because I don't know how to handle your bug report):
You ran a penetration tool (that is merciless able to discover weak points) against your ACCESS POINT.
That tool discovered a potential vulnerability (if we can confirm this by the next steps), because that's what it was made for.
You reported a hcxdumptool bug (because the tool made exactly what it was made for).
What do you now expect me to do - shall I unarm hcxdumptool so that it is no longer able to detect such weak points?

enable_status doesn't have any effect. It only print less or more messages.

I thought it has some effect like capturing some additional frames cause I had more crashes with 15, but after double-checking  all statusout in the code I guess you were right and it was just an accident in my testing.
Also, when it downs to your code, just cause of curiosity - why do you prefer 0b0000000000100000 instead of 0x20 or 1 << 5 ? In the Linux Kernel mostly I see  1 << y, and in some other, older drivers it is almost always hex, I think I've never seen binary literals in such a high quality code yet.
What do you now expect me to do - shall I unarm hcxdumptool so that it is no longer able to detect such weak points?

I think I've consumed enough of your time already.
From hcxdumptool I could only expect info if router somehow crashed, or if some sort of disconnection happened and clients aren't anymore connected to the AP, but It may be hard of even impossible to implement. I guess stupid simple way to do the first one would be just anything to stdout or even stderr if the router went down during the test and it is not transmitting any new frames, but the thing with info about router disconnecting all the clients may be a very tricky thing.
My goal here was basically just to learn from that and maybe report it to the Tp-Link. I keep learning something new with every your next post so I'm very thankful for all your responses, and at this point you can just recommend me some good books about wireless protocols or and its security or just something to help me troubleshooting that issue further on my own and leave me with it, or you can plan some next tests so we can collect all the results in your way and then inform Tp-Link with a solid case.

It is possible a bug inside the firmware. There are a lot of reports regarding this problem, but no one has found the true cause.
It could be possible that only this model drop all CLIENTs if it received a REASSOCIATION frame.
Problem is that it is hard to detect that the router went down.
There was still traffic between the CLIENT and the ACCESS POINT after the REASSOCIATION was successful done.
We can see this in the monitor dump file:
https://github.com/ZerBea/hcxdumptool/issues/246#issuecomment-1397421336
Some good links are here:
https://github.com/aircrack-ng/aircrack-ng/discussions/2381#discussioncomment-4742189
Most of 802.11 frames are explained on:
https://mrncciew.com/
and
802.11 Wireless Networks: The Definitive Guide, O'Reilly
You may have noticed that hcxdumptool/hcxtool is a little bit different to other tools. Running default options it tries everything possible to find a vulnerability as quickly as possible. But there is no "AI" inside to analyze it. Coding this is far beyond my scope.
That makes it mandatory to take a closer look at the log files, taken during the attack, as we did it.
We don't have the proprietary firmware to figure out what went wrong. Maybe the TP-Link forum is a better place to get more information, because you can talk directly to the developer.

I mentioned above that an impact on the target is not a hcxdumptool bug. Based on you report, hcxdumptool now print a message to inform the user about that, immediately after starting the program.
To discuss something like this (impacts on target) I opened discussions:
https://github.com/ZerBea/hcxdumptool/discussions


Heatmaps

Adds support for a heatmap visualization type.
Upgrades GL JS to v0.41.0
Updates Readme
Adds a new helper util function to create heatmap-weight stops
Adds heatmap to example notebook

TO DO

[x] Add tests for heatmap class
[x] Add tests for create_weight_stops util function
[x] PR review @perrygeo

https://github.com/mapbox/mapboxgl-jupyter/pull/16/commits/dde580c6183419cd1c899a54f6b1a7ffc225c8b3#diff-2df5c621fb5e45191036ab5f82a59f9bR60
I could probably abstract this function to apply to both radius stops and weight stops without creating a new utility function.

Thanks for the review @perrygeo!


Automatically create CAs / Subordinate CAs if they do not already exist

For ease of use, allow the Issuer to create CAs inside a Google Cloud project if they don't already exist

I wonder if this is reasonable in the V1 API. There's so many required options that I'm not sure we could come up with reasonable defaults.
Also if someone typos a name they might be surprised when we use a newly created CA rather than the one they created.
If we can find a good way to do this then I do think an easier first use experience would be good.


Toolbar.Focusable failed test with RTL and Jest

Bug report
What is the current behavior?
Can't create the renderer tree to make tests.
Error log:
TypeError: _this.getElement(...).closest is not a function

      7 | describe('toolbar', () => {
      8 |   it('renders correctly', () => {
   > 9 |     const tree= renderer.create(<MyToolbar />).toJSON()
        |                          ^
     10 |     expect(tree).toMatchSnapshot()
     11 |   });
     12 | })

     at ToolbarFocusableComponent.getToolbar (node_modules/reakit/lib/Toolbar.js:110:44)
     at ToolbarFocusableComponent.getFocusables (node_modules/reakit/lib/Toolbar.js:117:18)
     at ToolbarFocusableComponent.componentDidMount (node_modules/reakit/lib/Toolbar.js:198:35)
     at commitLifeCycles (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:9411:22)
     at commitAllLifeCycles (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:10808:7)
     at HTMLUnknownElement.callCallback (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:2377:14)
     at invokeEventListeners (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:193:27)
     at HTMLUnknownElementImpl._dispatch (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:119:9)
     at HTMLUnknownElementImpl.dispatchEvent (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:82:17)
     at HTMLUnknownElementImpl.dispatchEvent (node_modules/jsdom/lib/jsdom/living/nodes/HTMLElement-impl.js:30:27)
     at HTMLUnknownElement.dispatchEvent (node_modules/jsdom/lib/jsdom/living/generated/EventTarget.js:157:21)
     at Object.invokeGuardedCallbackDev (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:2427:16)
     at invokeGuardedCallback (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:2480:31)
     at commitRoot (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:11020:7)
     at node_modules/react-test-renderer/cjs/react-test-renderer.development.js:12471:5
     at Object.unstable_runWithPriority (node_modules/react-test-renderer/node_modules/scheduler/cjs/scheduler.development.js:255:12)
     at completeRoot (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:12470:13)
     at performWorkOnRoot (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:12399:9)
     at performWork (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:12307:7)
     at performSyncWork (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:12281:3)
     at requestWork (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:12150:5)
     at scheduleWork (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:11965:5)
     at scheduleRootUpdate (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:12564:3)
     at updateContainerAtExpirationTime (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:12592:10)
     at updateContainer (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:12603:10)
     at Object.create (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:13036:5)
     at Object.create (src/components/__tests__/toolbar.js:9:26)

If the current behavior is a bug, please provide the steps to reproduce.
Test file:
import React from 'react'
import renderer from 'react-test-renderer'
import { Toolbar } from 'reakit'

const MyToolbar = () => (
  <Toolbar>
    <Toolbar.Content whiteSpace="nowrap">
      <Toolbar.Focusable>Im focusable</Toolbar.Focusable>

Im not

      <Toolbar.Focusable>Use arrow keys</Toolbar.Focusable>
    </Toolbar.Content>
  </Toolbar>
)

describe('toolbar', () => {
  it('renders correctly', () => {
    const tree = renderer.create(<MyToolbar />).toJSON()
    expect(tree).toMatchSnapshot()
  });
})

What is the expected behavior?
It should create the tree in order to able unit testing.

Other relevant information:
{
    "reakit": "0.16.0",
    "babel-jest": "24.5.0",
    "jest": "24.5.0",
    "react-test-renderer": "16.8.4"
}

Hi @luizcieslak
Could you please run yarn why jsdom (or an npm equivalent)?

sure!
yarn why jsdom
yarn why v1.13.0
[1/4] Why do we have the module "jsdom"...?
[2/4] Initialising dependency graph...
[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found<EMAIL_ADDRESS>info Reasons this module exists
   - "jest#jest-cli#jest-config#jest-environment-jsdom" depends on it
   - Hoisted from "jest#jest-cli#jest-config#jest-environment-jsdom#jsdom"
Done in 26.13s.

by the way, I'm using gatsby and was reproduced this unit testing guide

Hmm, according to https://github.com/jsdom/jsdom/issues/1555#issuecomment-413995713, it seems that support for Element.prototype.closest was added in v11.12.0 (which is the one you have installed).
I'd try to upgrade jsdom just in case. You can either use jest-environment-jsdom-thirteen or yarn resolutions:
// in package.json
"resolutions": {
  "jsdom": "14.0.0"
}

same error :/
yarn why jsdom
yarn why v1.13.0
[1/4] Why do we have the module "jsdom"...?
[2/4] Initialising dependency graph...
warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found<EMAIL_ADDRESS>info Reasons this module exists
   - "jest#jest-cli#jest-config#jest-environment-jsdom" depends on it
   - Hoisted from "jest#jest-cli#jest-config#jest-environment-jsdom#jsdom"
Done in 1.90s.

Could you reproduce the error? Idk if it is something specific to this project.

I can't. We also have tests on this component and everything works fine.

Cleaning up issues. Closing this as we can't reproduce it. If someone has this problem and can come up with a repo or sandbox reproducing the problem, please comment here or open a new issue so we can find a solution.


Fix .babelrc to match README

As titled. This seems to have been fixed in the README, but not in the actual babel rc file.

Thanks


babel support for create-react-app

babel support for applications generated with create-react-app

I think we should have given @steffenagger a chance to review it also, since he is the original creator of this exact part, but he'll just have to chip in if there is anything that looks out of the ordinary.

@kasperkronborg alright, I will keep that in mind next time 😅

👍


feat: change log

Checklist

[x] npm test passes
[x] tests and/or benchmarks are included
[x] commit message follows commit guidelines

Description of change

Pull Request Test Coverage Report for Build 427354165

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.07%) to 93.467%

Totals

Change from base Build 427211788:
0.07%

Covered Lines:
10676

Relevant Lines:
11078

💛  - Coveralls


fix: Exception when trying to override FluentDialogFooter in a FluentDialog

🐛 Bug Report
An exception occurs when trying to override FluentDialogFooter in a FluentDialog.
System.InvalidOperationException: This FluentDialog already contains a FluentDialogFooter    at Microsoft.Fast.Components.FluentUI.FluentDialog.SetDialogFooter(FluentDialogFooter footer) in /_/src/Core/Components/Dialog/FluentDialog.razor.cs:line 252    at Microsoft.Fast.Components.FluentUI.FluentDialogFooter.OnInitialized() in /_/src/Core/Components/Dialog/FluentDialogFooter.razor.cs:line 44    at Microsoft.AspNetCore.Components.ComponentBase.RunInitAndSetParametersAsync()
Overriding FluentDialogHeader and FluentDialogBody works correctly
💻 Repro or Code Sample
This dialog crashes:
<FluentDialog @ref="_dialog" @bind-Hidden="DialogHidden" Modal="true" @ondialogdismiss="OnDialogDismiss">

    <FluentDialogHeader ShowDismiss="true">
        Header
    </FluentDialogHeader>
    <FluentDialogBody>
        This is the body
    </FluentDialogBody>

    <FluentDialogFooter>
        Crash if present, works when commented out
    </FluentDialogFooter>

</FluentDialog>

Working example without FluentDialogFooter:
<FluentDialog @ref="_dialog" @bind-Hidden="DialogHidden" Modal="true" @ondialogdismiss="OnDialogDismiss">

    <FluentDialogHeader ShowDismiss="true">
        Header
    </FluentDialogHeader>
    <FluentDialogBody>
        This is the body
    </FluentDialogBody>

</FluentDialog>

A repository showcasing the problem: link
On the home page there is a working example.
On the page /crash there is the same component but with FluentDialogFooter provided as a child.
🤔 Expected Behavior
The component should not crash.
😯 Current Behavior
The component throws an InvalidOperationException when providing a FluentDialogFooter
💁 Possible Solution
🔦 Context
I was trying to show a modal WITHOUT a dialog service.
🌍 Your Environment

OS & Device: Windows
Browser: Firefox
.NET7

FluentDialogFooter.Initialize is being called twice.

Thank you for your comments. This issue has been resolved in PR #920 and will be published in the next version.

I still get this error after updating to 3.4.0 :/ Has this only been fixed for 4.0.0?

Yup, we forgot to include this in 3.4.0. Will be in the next (3.4.1) update.


[TRACKING] Lazy loading roadmap

Lazy loading roadmap
As #2602 was merged and #421 closed, we will use this new issue to track the remaining steps for a broader lazy loading (LL) support.

[x] Initial implementation using the lz.n backend (https://github.com/nix-community/nixvim/pull/2602)
[ ] Add top-level documentation (https://github.com/nix-community/nixvim/pull/2630)
[ ] Advertise the feature on the README
[ ] Migrate all relevant packages to mkNeovimPlugin to have more plugins supporting LL.
[ ] Remove "experimental" warnings (once stability[^1] is confirmed)
[ ] Support the lazy.nvim backend (https://github.com/nix-community/nixvim/pull/2620)
[ ] Enable lazy loading by default on supported plugins ?
-> Not sure about this one. Again, Nixvim is not a distribution. It should not do much OOTB (i.e. behind your back).

Feel free to propose additional goals !
Thanks @trueNAHO for the idea
[^1]: Note: "stability" refers to both the feature itself behaving as expected, and also our API being stable enough that we should not need to make breaking changes

I feel like it should be default because it would be a pain to enable lazyloading for every single plugin.
An example, before lazyloading you have 50-100+ plugins that you have enabled and want lazy loading on all of them, it would be a pain to go ahead and enable lazyloading for all of them.
I feel like there should be a seprate option to enable lazyloading for all plugins by default on but users can turn it off if it's annoying. So an example of this could be:
programs.nixvim.plugins = {
   lazyloading = true; # false if you want to only select specific plugins

   # with the main lazyloading
   noice-nvim.enable = true;

   # Manually specifying plugins that you want lazyloading on
   noice-nvim = {
    enable = true;
    lazyloading = false; # This should still work if lazyloading is enabled in plugins as well as specifically affecting that plugin.
  }
};

I get this might sound complicated, but it could solve the lazy loading by default on plugins problem.

I feel like it should be default because it would be a pain to enable lazyloading for every single plugin.

I'm going to assume you mean the per-plugin plugins.*.lazyload.enable option should default to true. Having lazyloading itself globally enabled by default is not something nixvim will do, because everything in a nixvim config should come from the end-user explicitly deciding to do something.
The issue with having plugins.*.lazyload.enable default to true, is deciding what triggers individual plugins to be loaded. That is why it currently defaults to "whether plugins.*.lazyload.settings contains a non-null attr"[^1].
See the documentation for more detail.
If it is set to true without any sensible config in plugins.*.lazyload.settings, then the plugin will simply never load. For lazy loading to make sense, you need to decide which keybinds, filetypes, autocmd events, etc should trigger loading.
[^1]: default = lib.any (x: x != null) (builtins.attrValues config.settings)

I feel like it should be default because it would be a pain to enable lazyloading for every single plugin.

I'm going to assume you mean the per-plugin plugins.*.lazyload.enable option should default to true.
No, Just please have a look at the example provided below.

I'm going to assume you mean the per-plugin plugins.*.lazyload.enable option should default to true.

No, Just please have a look at the example provided below.

I'm sorry, the example doesn't make sense because nowhere is it specified when the plugin should be loaded.
See the rest of my comment above, but as a TL;DR: lazyloading requires you to decide what "event(s)" should cause the plugin to load.

Also, as a side-note: your example doesn't match how we currently have the options structured:

You're using plugins.*.lazyload as a boolean, but it is actually an attrset containing an enable and settings options.
You have a "global" plugins.lazyload option, however we expect this to be configured as plugins.lz-n.enable.

I will look into make a POC pr and it will hopefully make sense.

I don't making lazy-loading enabled by default is good. Not all plugins should be lazy-loaded, in fact, many plugins can break if you lazy-load them. Plus, not everyone even likes lazy-loading, for them, lazy-loading by default would just feel like an unnecessary hassle.
Another issue is figuring out when plugins should load. If the triggers (like keybindings or filetypes) aren’t set up right, some plugins might never load at all. That’s a confusing problem to deal with, especially for new users.
I think the current way of enabling lazy-loading, only if the user passes specific configuration, is the right way. It ensures lazy-loading is only applied when the user explicitly sets it up

I don't making lazy-loading enabled by default is good. Not all plugins should be lazy-loaded, in fact, many plugins can break if you lazy-load them. Plus, not everyone even likes lazy-loading, for them, lazy-loading by default would just feel like an unnecessary hassle.
Another issue is figuring out when plugins should load. If the triggers (like keybindings or filetypes) aren’t set up right, some plugins might never load at all. That’s a confusing problem to deal with, especially for new users.

I agree with this. I think it shouldn't but there should be a global way and when you use the lazyloading option in the plugin it overrides the global like I said above.

I think the current way of enabling lazy-loading, only if the user passes specific configuration, is the right way. It ensures lazy-loading is only applied when the user explicitly sets it up

I still think there could be a couple improvements like adding a global option to enable it for all plugins and make it to so if you modify the plugin option it overrides what the global option does. I will make a pr of it soon!

I agree with this, I think it shouldn't be default after just now thinking, but there should be a global way and when you use the lazyloading option in the plugin it overrides the global like I said above.

I don’t think having a global lazy-loading option is a good idea either. The main problem is that you’d need to set up the lazy-loading triggers in a way that works for most plugins, which is nearly impossible. Plugins usually need specific configurations to determine when they should load, like on a command, a keymap, an event, or something else.
And if you try to apply the same global lazy-loading configuration to all plugins, they’d all end up with the same trigger unless overridden. And at that point, you’re back to square one, either not actually lazy-loading most plugins or needing to override so many of them that the global option becomes pointless.
Lazy-loading really needs to be done plugin by plugin to make sense. It’s better to stick with the current approach where the user explicitly sets it up when and how it’s needed.

I agree with this, I think it shouldn't be default after just now thinking, but there should be a global way and when you use the lazyloading option in the plugin it overrides the global like I said above.

I don’t think having a global lazy-loading option is a good idea either. The main problem is that you’d need to set up the lazy-loading triggers in a way that works for most plugins, which is nearly impossible. Plugins usually need specific configurations to determine when they should load, like on a command, a keymap, an event, or something else.
And if you try to apply the same global lazy-loading configuration to all plugins, they’d all end up with the same trigger unless overridden. And at that point, you’re back to square one, either not actually lazy-loading most plugins or needing to override so many of them that the global option becomes pointless.
Lazy-loading really needs to be done plugin by plugin to make sense. It’s better to stick with the current approach where the user explicitly sets it up when and how it’s needed.

I get that but that's why I mentioned there is a possibility of overriding it but just to enable lazy loading. Not settings as settings for how it will be loaded I just want a globalEnable option so you don't have to do for every single plugin plugins.*.lazyloading.enable = true;

I get that but that's why I mentioned there is a possibility of overriding it but just to enable lazy loading. Not settings as settings for how it will be loaded I just want a globalEnable option so you don't have to do for every single plugin plugins.*.lazyloading.enable = true;

You don’t need to set plugins.*.lazyLoad.enable explicitly for every plugin. The way it works now, lazy-loading is automatically enabled as long as you pass the lazy-loading settings. For example, you can just set something like:
plugins.which-key.lazyLoad.settings.event = "VimEnter";

I get that but that's why I mentioned there is a possibility of overriding it but just to enable lazy loading. Not settings as settings for how it will be loaded I just want a globalEnable option so you don't have to do for every single plugin plugins.*.lazyloading.enable = true;

You don’t need to set plugins.*.lazyLoad.enable explicitly for every plugin. The way it works now, lazy-loading is automatically enabled as long as you pass the lazy-loading settings. For example, you can just set something like:
plugins.which-key.lazyLoad.settings.event = "VimEnter";

But still I don't want to have to do that for every plugin that I want lazily loaded.

The way it works now, lazy-loading is automatically enabled as long as you pass the lazy-loading settings. For example, you can just set something like:
 plugins.which-key.lazyLoad.settings.event = "VimEnter";

But still I don't want to have to do that for every plugin that I want lazily loaded.

I don't see a sensible alternative.

Therefore you need to decide for yourself what events will cause that plugin to load.
If you don't do that, we can't really guess for you. Because while you might want to load on VimEnter, someone else might want to load on something entirely different. Or they may want the plugin eagerly loaded.

In theory, nixvim could maintain bespoke sane defaults for every plugin. However this is impractical because we have way too many plugins and we don't want to increase our already high per-plugin maintenance cost.
Even if nixvim did maintain per-plugin defaults, it still seems likely that many users would disagree with our choices. It'd actually be more work for them to "undo" our choices instead of starting from a blank slate.


Private Endpoint limitation in Az Managed Grafana

Added below at the last line -
"Private Endpoint is not available in Azure Managed Grafana."

Learn Build status updates of commit b6dfbe8:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/managed-grafana/known-limitations.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@maud-lv
Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Hello @Court72  @maud-lv
If time permits, please update
Awaiting for your response!!!
Many Thanks
Regards,
Arindam Mitra

Hi @arindam0310018, sorry for the delay. You're correct, private endpoints aren't available in Azure Managed Grafana at the moment. I will include your note in the doc.

PR pulled into the private repo and merged.

#please-close


Radio group value depending on something

Question
My case is simple, i want the value of a radio group depending on the value of another radio group.
For example, when i select option 3 of radio group 1, i want option 4 of radio group 2 selected by default.
radio group 1:
    - option 1
    - option 2
    - **option 3**. (is selected by the user)

radio group 2:
    - option 1
    - option 2
    - option 3
    - **option 4** (is selected by default)

I 'm pretty sur that i have to use expressionProperties, but in my case, my formly config is in JSON format. It's seems like i can't use arrow fonction in it.
As i can see here, https://formly.dev/examples/other/json-powered, this is working.
"expressionProperties": {
      "templateOptions.label": "'Why did you choose ' + model.color + '?'"
    },

but i want something more like this.
"expressionProperties": {
      "valueOfMyRadioGroup": "() => { if something then do something}"
    },

Is it possible ? Am i wrong or missing something ?

"expressionProperties": {
  "model.radio2": "model.radio1 === 3 ? model.radio1 : model.radio2"
},

Hello, thank's it's working !
But i have that common issue when i click on radio button:
ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. Previous value: 'mat-radio-disabled: true'. Current value: 'mat-radio-disabled: false'.
I read that it only occur on debug, i don't realy know how to fix it or prevent it.
Anyway, thanks for your help and for your work.

Could you please provide a reproduction example? Thanks!


MP Config and OpenTracing 2.0

Includes #13836 (MP Config) and #13855 (OpenTracing)
MP Config fails without OT, and the OT CI has just begun so I am combining the two

Closing since I merged the individual #13836 (MP Config) and #13855 (OpenTracing) PRs

Closing since I merged the individual #13836 (MP Config) and #13855 (OpenTracing) PRs


remove class that prevents special chars

Description

removed class="disallowSpecialCharacters" to prevent url encoding

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Screenshots (if appropriate):
How Has This Been Tested?

@blueorangutan package

doing it here because of local db problems :(

moved to master

see https://github.com/apache/cloudstack/pull/3260


Add node upgrade instructions to docs

A few users running into issues with older node versions!

Also add note about installing node for the first time

Closed by #122


react-native-paper works on web too

See https://callstack.github.io/react-native-paper/using-on-the-web.html

Thanks @ferrannp !


Parameters Binding Order [Documentation]

Hello @muak,
I really enjoy those controls. One thing what could be helpfull would be to mention that parameters (binding ones) must be declared in a correct order.

ItemTapCommand
ItemSource

If you set the property ItemTapCommand after Itemsource, it wont works as there is no ItemCommandPropertyChanged.
Anyway those are essentials controls which could be part of Xamarin.Forms, thanks for the work you achieve.

@predalpha
Thank you for reporting the issue.
I will try to reproduce this issue and fix it as soon as possible.
Please waitng for some time.


RichText issue with IE10 rendering

Bug: RichText component is not rendering on IE with the version 10.
I've installed @pnp/spfx-controls-react of version 1.16.0. The RichText control works as expected on all the browsers except IE 10 or lower. In IE 10 or lower it throws an exception of Invalid component and with a exception stack details.
As soon as I remove the import reference and  component from the code, component loads as expected.
Any help will be appreciated.
Thanks!

@hugoabernier,
I believe you're the author of RichText.
Could you please help with this one?

Closing as IE10 support has ended: https://learn.microsoft.com/en-us/lifecycle/announcements/internet-explorer-10-end-of-support


Ert names ops

About the PR

ERT, CBURN and deadsquad operatives now will have new last names, mostly it's names of stars and constellations
Why / Balance

looks cool
Technical details

Media

[ ] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

its too personal, these aren't characters the same way a regular player is. it also doesnt make sense militarily because you wont be referred to with your full name

it also doesn't make sense to give them special last names because these are regular people, not a deviant art users special OC dont steal

its too personal, these aren't characters the same way a regular player is. it also doesnt make sense militarily because you wont be referred to with your full name

all of the first names are just "Corporal", "Sargeant", "Commander", etc. i think it's fine personally.

being called by your rank and last name makes the most sense for a military, which the ERT is similar to


Update css-case-insensitive.json

Selectors 4 was re-published as Working Draft with the case-insensitive attribute selector included in it.

Thanks!


Add groups to Button and BaseButton to reduce inspector clutter

The inspector is too disorganized for buttons and takes so much space it's not possible to view all important properties on a screen like mine. So I tried to organize it a little by grouping things up.

Text Behavior

Alignment
Text overrun behavior
Clip text

Icon behavior

Icon Alignment
Expand Icon

Shortcut

Shortcut
Shortcut Feedback
Shortcut in Tooltip

Thanks!