The base is a Lenovo E450 notebook running recent 13/STABLE: FreeBSD 13.0-STABLE #54 stable/13-n248811-2572b6bd6bf: Sun Jan 2 22:46:43 CET 2022 amd64 [...] CPU microcode: updated from 0x25 to 0x28 CPU: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz (2494.37-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x7fdafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> AMD Features2=0x21<LAHF,ABM> Structured Extended Features=0x27ab<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG> Structured Extended Features3=0x9c000600<MCUOPT,MD_CLEAR,IBPB,STIBP,L1DFL,SSBD> XSAVE Features=0x1<XSAVEOPT> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16502960128 (15738 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: <LENOVO TP-J9 > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. Security policy loaded: MAC/ntpd (mac_ntpd) Security policy loaded: TrustedBSD MAC/BSD Extended (mac_bsdextended) ioapic0 <Version 2.0> irqs 0-23 Launching APs: 1 3 2 random: entropy device external interface kbd1 at kbdmux0 efirtc0: <EFI Realtime Clock> efirtc0: registered as a time-of-day clock, resolution 1.000000s aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS> acpi0: <LENOVO TP-J9> acpi_ec0: <Embedded Controller: GPE 0x17, ECDT> port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) [...] The WiFi NIC is a Intel i7260: iwm0@pci0:5:0:0: class=0x028000 rev=0x73 hdr=0x00 vendor=0x8086 device=0x08b2 subvendor=0x8086 subdevice=0x4262 vendor = 'Intel Corporation' device = 'Wireless 7260' class = network bar [10] = type Memory, range 64, base rxf1c00000, size 8192, enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[40] = PCI-Express 2 endpoint max data 128(128) FLR RO NS max read 128 link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ClockPM enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 .... ecap 0018[14c] = LTR 1 ecap 000b[154] = Vendor [1] ID cafe Rev 1 Length 20 First observation: With different networks and access points, the WiFi NIC results very often in loosing network connection, it is more a freezing, since ifconfig reports still IP and wpa_cli shows still some association to the AP, but there is no packet flow anymore. I reported in this issue recently on freebsd-wireless and got the advice to wait for the if_iwlwifi driver. Since this driver seems to be quite far from ready to be used and with the above mentioned OS version unusable (no FW is loaded), I'll report this issue in. I have no clue why and how the connection of the i7260 WiFi NIC gets broken, but it seems to be somehow related to the number of networks on the 2,4 GHz band, but this observation is not accurate. Second observation: Since a couple of years for now I compile the if_iwm driver statically as well as the (supposedly correct) firmware via device iwm device iwmfw into the kernel. This procedure results in the above observed dropouts. With the upcoming if_iwlwifi at hand I started loading (exclusive) either iwm or iwlwifi via /boot/loader.conf.local into the kernel. Loading the if_iwm driver this way results in a unusable state: very often and reproducable a ping reaches latencies larger than 5000 - 6000 ms, with the result of a corruption of the connections made and rapidly with the finale state as observed and reported above - the frozen state.
I observed a strange behaviour with this WiFi NIC and 13/STABLE and do a followup on my initial PR: when the signal strength of the 2,4 GHz access point is around 55% and below and if the channel is populated, FreeBSD's if_iwm (Intel WiFi i7260, see above) starts showing up really weird ping latencies, see below. In the same spot, same AP, same network, same time I tried to run on the very same notebook Xubuntu 21.10 from an USB flash drive on the very same hardware gives a complete unspectacular picture with approx 20 - 25 ms ping latency to the same remote host - which let me conclude that the issue is with FreeBSD and its if_iwm driver on that hardware. FreeBSD 12.3 and FreeBSD 13.0-p6 doesn't work either, the connection drops are even worse. The funny part on the 10k ms ping latencies is that the subsequent answer is delayed by approx 1 to 2 sec, but not > 10 secs as the value of time=14349.755 ms might suggest - or I'm confused in what is measured here. [...] 64 bytes from 193.99.144.80: icmp_seq=7488 ttl=244 time=134.382 ms 64 bytes from 193.99.144.80: icmp_seq=7489 ttl=244 time=20.596 ms 64 bytes from 193.99.144.80: icmp_seq=7490 ttl=244 time=18.228 ms 64 bytes from 193.99.144.80: icmp_seq=7491 ttl=244 time=163.518 ms 64 bytes from 193.99.144.80: icmp_seq=7492 ttl=244 time=19.130 ms 64 bytes from 193.99.144.80: icmp_seq=7493 ttl=244 time=116.665 ms 64 bytes from 193.99.144.80: icmp_seq=7494 ttl=244 time=30.127 ms 64 bytes from 193.99.144.80: icmp_seq=7495 ttl=244 time=27.886 ms 64 bytes from 193.99.144.80: icmp_seq=7496 ttl=244 time=100.026 ms 64 bytes from 193.99.144.80: icmp_seq=7497 ttl=244 time=102.516 ms 64 bytes from 193.99.144.80: icmp_seq=7498 ttl=244 time=66.973 ms 64 bytes from 193.99.144.80: icmp_seq=7499 ttl=244 time=425.427 ms 64 bytes from 193.99.144.80: icmp_seq=7500 ttl=244 time=664.293 ms 64 bytes from 193.99.144.80: icmp_seq=7501 ttl=244 time=3988.030 ms 64 bytes from 193.99.144.80: icmp_seq=7502 ttl=244 time=4833.482 ms 64 bytes from 193.99.144.80: icmp_seq=7503 ttl=244 time=5243.759 ms 64 bytes from 193.99.144.80: icmp_seq=7504 ttl=244 time=5403.003 ms 64 bytes from 193.99.144.80: icmp_seq=7505 ttl=244 time=5945.360 ms 64 bytes from 193.99.144.80: icmp_seq=7506 ttl=244 time=5938.943 ms 64 bytes from 193.99.144.80: icmp_seq=7507 ttl=244 time=7571.142 ms 64 bytes from 193.99.144.80: icmp_seq=7508 ttl=244 time=7958.211 ms 64 bytes from 193.99.144.80: icmp_seq=7509 ttl=244 time=7406.198 ms 64 bytes from 193.99.144.80: icmp_seq=7514 ttl=244 time=18349.734 ms 64 bytes from 193.99.144.80: icmp_seq=7515 ttl=244 time=18305.794 ms 64 bytes from 193.99.144.80: icmp_seq=7516 ttl=244 time=17721.662 ms 64 bytes from 193.99.144.80: icmp_seq=7517 ttl=244 time=18304.380 ms 64 bytes from 193.99.144.80: icmp_seq=7518 ttl=244 time=18754.385 ms 64 bytes from 193.99.144.80: icmp_seq=7519 ttl=244 time=18177.343 ms 64 bytes from 193.99.144.80: icmp_seq=7520 ttl=244 time=17414.787 ms 64 bytes from 193.99.144.80: icmp_seq=7521 ttl=244 time=16533.082 ms 64 bytes from 193.99.144.80: icmp_seq=7522 ttl=244 time=15685.028 ms 64 bytes from 193.99.144.80: icmp_seq=7523 ttl=244 time=14987.974 ms 64 bytes from 193.99.144.80: icmp_seq=7524 ttl=244 time=14349.755 ms 64 bytes from 193.99.144.80: icmp_seq=7525 ttl=244 time=13542.414 ms 64 bytes from 193.99.144.80: icmp_seq=7526 ttl=244 time=12709.539 ms 64 bytes from 193.99.144.80: icmp_seq=7527 ttl=244 time=11928.034 ms 64 bytes from 193.99.144.80: icmp_seq=7528 ttl=244 time=11214.344 ms 64 bytes from 193.99.144.80: icmp_seq=7529 ttl=244 time=11036.179 ms 64 bytes from 193.99.144.80: icmp_seq=7530 ttl=244 time=10765.792 ms
I am currently not sure what to do with this; given it was fairly recent, can you still reproduce the issue so we could debug it?