FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2026-03-08T13:50:02Z 2026-03-08T13:50:02Z Bjoern A. Zeeb bz@FreeBSD.org 2026-03-08T00:57:33Z urn:sha1:6cfd2b93e68061c7831016b91c2e308d01658764 Depending on the base channel ni_vht_chan2 - ni_vht_chan1 can be negative. Apply abs() as indicated in the comments right above | CCFS1 - CCFS0 | = 8 or > 16 in order to fix the channel width selection. Sponsored by: The FreeBSD Foundation PR: 293645 Fixes: 4bf049bfeefd9 MFC after: 3 days Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D55717 2026-03-05T13:44:00Z Bjoern A. Zeeb bz@FreeBSD.org 2026-03-02T10:33:53Z urn:sha1:9b03cc2a70e4b6354c5f5b90e4c51b850b6b1dd2 Rather than using the status != 0 check use the way more descriptive status != IEEE80211_STATUS_SUCCESS definition. This makes it a lot more clear what is checked here. While here add a comment in case aof the (Re)Assoc Resp failure as we do not update state in that case but rely on a timeout which will bounce us back to State 1 (cf. 802.11-2024, Figure 11-23) which means SCAN in our case, rather than possibly moving us back to AUTH. We will likely have to revisit this when SAE hits the tree. Sponsored by: The FreeBSD Foundation MFC after: 3 days Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D55643 2026-02-11T06:02:49Z Adrian Chadd adrian@FreeBSD.org 2025-12-15T03:45:36Z urn:sha1:7a5288a023baeac2f0c3128506178f89fda3cc0d There's at least one place where the time comparison is wrong, leading to some bad beahaviour around deciding to try and establish/reestablish AMPDU TX sessions. Start addressing these! Differential Revision: https://reviews.freebsd.org/D54390 2026-02-09T21:40:47Z Bjoern A. Zeeb bz@FreeBSD.org 2026-01-20T13:43:51Z urn:sha1:840f478eed2ab18abd1088aa12587bb708a46b56 While everything else uses vprintf() and net80211_vap_printf() vlog() the debug output of wlandebug sessions can be weird. For consistency use vprintf() everywhere to have homogeneous logging. Sponosred by: The FreeBSD Foundation MFC after: 3 days Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D54795 2026-01-21T18:31:07Z Bjoern A. Zeeb bz@FreeBSD.org 2026-01-20T18:57:19Z urn:sha1:5f7b5dde10518d4436e1ec07a76873bf31d28425 Add more EHT definitions used by at least iwlwifi. Sponsored by: The FreeBSD Foundation MFC after: 3 days 2026-01-20T15:45:58Z Bjoern A. Zeeb bz@FreeBSD.org 2026-01-20T13:48:11Z urn:sha1:c670af3725d0bb5494caf0846994ae6997175cb6 We used to return the result of (*ic_send_action) directly but ieee80211_ampdu_request() returns 1 on success and 0 on error, which is contrary to the result of (*ic_send_action). Deal with that accordingly and update the documentation of the function. Sponsored by: The FreeBSD Foundation MFC after: 3 days Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D54794 2026-01-14T18:51:11Z Yichen Chai yichen.chai@gmail.com 2026-01-14T18:44:08Z urn:sha1:75556c7e999e9095ce71558ae61f49c1ba61a192 Fix the arguments to the debug statement. (slightly adjusted from the original submission by bz) PR: 286448 MFC after: 3 days 2026-01-10T18:56:19Z Gleb Smirnoff glebius@FreeBSD.org 2026-01-10T18:56:19Z urn:sha1:509a185dd9405141df4d304d7805019b40e736cf PR: 292337 Fixes: 8774a990ee4094f16d596d4b78e0f3239e5d0c88 2025-12-15T20:50:35Z Gleb Smirnoff glebius@FreeBSD.org 2025-12-15T20:50:35Z urn:sha1:8774a990ee4094f16d596d4b78e0f3239e5d0c88 Imagine that bpf(9) tapping can happen at any point in the network stack, not necessarily at interface transmit or receive. To achieve that we need a thin layer of abstraction defined by struct bif_methods, that defines how generic bpf layer works with a tap point of this kind. Implement ifnet(9) specific methods in a separate file bpf_ifnet.c. At this point there is 100% compatibility for all existing interfaces, there is no KPI change, yet. The legacy attaching KPI is layered over new ifnet agnostic KPI. The new KPI may change though, as we can implement multiple DLTs per single tap point in a prettier fashion. The new abstraction layer allows us to move all the 802.11 radio injection hacks out of bpf.c into ieee80211_radiotap.c, so do that immediately as a good proof of concept. Reviewed by: bz Differential Revision: https://reviews.freebsd.org/D53872 2025-11-11T16:06:29Z Adrian Chadd adrian@FreeBSD.org 2025-09-24T15:30:47Z urn:sha1:77b1e4f32f31b219c238c81b726d079a003b465c Add some accessors to the key data, key length and MIC data. Document exactly what these mean. There's at least a couple of drivers that access the key data field directly and assume that the TX/RX MIC is available directly after the data pointer, which bakes in the "key size is 128 bits" in subtle ways. The goal here is to migrate the drivers and net80211 code to use these methods rather than accessing wk_key directly and making assumptions about wk_key and the copied key length (which the ioctl path definitely does.) Once that's done, it should be a lot easier to change the key API for larger keys. Differential Revision: https://reviews.freebsd.org/D52711 Reviewed by: thj