Which ath(4) cards are currently supported?
OK I (mistakenly) picked up an Atheros 11ac mini-pcie card for a new laptop I picked up. But 80211ac isn't yet supported. :-( OK so what IS supported? ;-) I installed 13.1 and consulted RELEASE Hardware notes[1] which indicates: The ath(4) driver supports all Atheros Cardbus and PCI cards, except those that are based on the AR5005VL chipset. Which I think must be completely incorrect. As far as I can tell, with the exception of some hard work by bz@, FreeBSD WiFi is anywhere from 9-15yrs out. No 11ac or 11ax. WiFi-7 is also available, just not supported on FBSD. I not attempting to take shots here. Just trying to point out the fact that ath(4) doesn't cover all their chip-models as the RELEASE NOTES indicate. Does anyone have/provide a list? Does the SYNOPSIS in ath_hal(4) cover the entire list? Thank you for all your time, and consideration. 1. https://www.freebsd.org/releases/13.0R/hardware/ P.S. Mad props to Bjoern for his hard work on this! :-) --Chris 0xBDE49540.asc Description: application/pgp-keys
Re: Which ath(4) cards are currently supported?
On 2022-04-04 11:17, Freddie Cash wrote: On Mon, Apr 4, 2022 at 11:01 AM Chris wrote: OK I (mistakenly) picked up an Atheros 11ac mini-pcie card for a new laptop I picked up. But 80211ac isn't yet supported. :-( OK so what IS supported? ;-) I installed 13.1 and consulted RELEASE Hardware notes[1] which indicates: The ath(4) driver supports all Atheros Cardbus and PCI cards, except those that are based on the AR5005VL chipset. Note: PCI means PCI, not PCIe. :) The ath(4) driver supports the old PCI and CardBus adapters. It doesn't support PCIe, USB, M.2, or other formfactor adapters. While slightly ambiguous, the hardware notes are technically correct. Sure OK. I simply moved down to the "Wireless Network Interfaces" to see if I could discover exactly *which* Atheros numbers I could safely buy to use FreeBSD effectively on my new laptop. You know; like: Atheros m.2. Which I could then compare to those indicated by FreeBSD as being supported. Oh well. I guess I'm stuck with the numbers given on the ath_hal(4) man page. Maybe that's the complete list? Thanks for taking the time to reply, Freddie! :-) --Chris 0xBDE49540.asc Description: application/pgp-keys
iwlwifi on a 7260
I just received an Intel 7260 m.2 adapter yesterday. So gave the work on iwlwifi a test drive today... FreeBSD 13.1-BETA3 FreeBSD 13.1-BETA3 releng/13.1-n250010-ca2b1e3480b GENERIC amd64 If I don't insist on iwlwifi, the following defaults to iwm iwlwifi0@pci0:3:0:0: class=0x028000 rev=0xc3 hdr=0x00 vendor=0x8086 device=0x08b2 subvendor=0x8086 subdevice=0xc270 vendor = 'Intel Corporation' device = 'Wireless 7260' class = network The following entries in rc.conf(5) kld_list="if_iwlwifi" wlans_iwlwifi0="wlan0" ifconfig_wlan0="WPA SYNCDHCP" Produce: wlan0: flags=8843 metric 0 mtu 1500 ether 10:4a:7d:bf:e6:31 inet 192.168.1.8 netmask 0xff00 broadcast 192.168.1.255 groups: wlan ssid My-5Ghz-SSID channel 157 (5785 MHz 11a) bssid 50:6a:03:af:d2:2a regdomain FCC country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 23 bmiss 7 mcastrate 6 mgmtrate 6 scanvalid 60 wme roaming MANUAL parent interface: iwlwifi0 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11a status: associated nd6 options=29 The AP I connect to is 80211.ac supporting 2.4 && 5Ghz Thanks for your time and work on this! I'm going to blow away the 13.1b3 and replace it with rc2 to see what develops. I'm available to do any sort of testing you might be interested in. Thanks again. l8r, Chris 0xBDE49540.asc Description: application/pgp-keys
Re: 8265 / 9560 problems
On 2022-04-08 18:45, Tomoaki AOKI wrote:
On Fri, 8 Apr 2022 11:24:30 + (UTC)
"Bjoern A. Zeeb" wrote:
On Fri, 8 Apr 2022, Bjoern A. Zeeb wrote:
> On Fri, 8 Apr 2022, Eirik 〓verby wrote:
>
>> On Fri, 2022-04-08 at 12:48 +0200, J.R. Oldroyd wrote:
>>> On Thu, 7 Apr 2022 17:14:26 + (UTC) "Bjoern A. Zeeb"
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have reports from at least three people saying that atfer the March 27
>>>> update associating has become hard and they see firmware crashes.
>>>>
>>>> These were on 8265 / 9560 chipsets. Some of you tried to gather data
>>>> for me as well, testing out patches without a positive outcome.
>>>> I've been able to reproduce this in the lap with a freshly installed
>>>> 8265.
>>>> Just wanted to give you that update that I am looking into it.
>>>>
>>>> I hope I'll have a further update soon.
>>>>
>>>> Bjoern
>>>>
>>>
>>> I was one of those people reporting this. I have an 8265.
>>>
>>> For me, applying Bjoern's rssi patch AND also making sure that iwm does
>>> not load first by using in rc.conf:
>>>devmatch_blacklist="if_iwm.ko"
>>> solves the firmware crash and allows iwlwifi to load and associate cleanly
>>> on boot.
>>>
>>
>> I'll be testing this - can you point me to the patch in question (I
>> think I missed it..?)
>
> It'll be in main in the next hour or so. I'll post a cherry-pick line
> for people on stable as soon as it is.
If you are on main, you can simply update. If you are on stable/13
you want or wait until I'll MFC:
git cherry-pick -x 170acccf1e191ae28571845ad6f0b5a2fbf0effc
And many thanks to JR for his work on this!
While this seems to have helped, I can still crash on my 8265 but I
have probably learnt to twist knobs to do that in the last weeks with
AX200.
I'll be very happy to hear if this helps you (and others on more
modern chipsets).
Later,
Bjoern
--
Bjoern A. Zeeb r15:7
Thanks. Seems we have advanced!
But unfortunately, it seems to be somehow racy on initialization.
Tried both
stable/13 at git 44c69c0a3172b1af1211d7afd72d68deca1099b2 with
cherry-picking git 170acccf1e191ae28571845ad6f0b5a2fbf0effc
and
main at git fcaf016796cc0272a8c239850fa87244eebefe13, which is after
git 170acccf1e191ae28571845ad6f0b5a2fbf0effc.
each of which has devmatch_blacklist="if_iwm.ko" in /etc/rc.conf.
*Maybe devmatch_blacklist="${devmatch_blacklist} if_iwm.ko"
would be safer.
Sometimes fairly initialized and associated, but sometime not,
regardless cold boot or warm restart.
Switching to wired (em0) connection and back to wlan0 (iwlwifi0)
sometimes work but sometime not (firmware crash just as before).
I can confirm this also happens with a 7260 on 13.1-RC2. I can NOT
get it to work on warm or cold boot. I use devmatch_blacklist="if_iwm.ko"
However. After login, if I send a
service netif restart
everything works as intended. I know this is a 7260 and not 8265 / 9560.
But thought it still might be useful to know.
Thanks in advance!
Thanks,
Chris
0xBDE49540.asc
Description: application/pgp-keys
Re: 8265 / 9560 problems + 7260 + AX200
On 2022-04-14 11:12, Bjoern A. Zeeb wrote: On Mon, 11 Apr 2022, Chris wrote: I can confirm this also happens with a 7260 on 13.1-RC2. I can NOT get it to work on warm or cold boot. I use devmatch_blacklist="if_iwm.ko" However. After login, if I send a service netif restart everything works as intended. I know this is a 7260 and not 8265 / 9560. But thought it still might be useful to know. Thanks Chris. I thought that something with all the pre-22000 cards is likely not flying well, until I got a firmware crash on AX200 last night. Sadly dumping after the follow-up panic did not work so I was left if the last bits of console lines I could recover. I have a lot more trouble to reproduce this now so I might send out a script and instructions for you all (with the problem) to run and gather data to help me. I'll let you know once I am confident that it'll collect all I hope to need. I'll make the time for it. Thanks! Bjoern Chris 0xBDE49540.asc Description: application/pgp-keys
athp / ath10k or the Atheros QCA6174
It appears that many chips like the Atheros/Qualcomm QCA6174 are supported on FreeBSD by the athp or the ath10k. But in some 7 years now, neither of those drivers have come to fruition. Are there any plans to complete either of these? Or is there a different option for these chips? Thank you for all your time and consideration. --chris 0xBDE49540.asc Description: application/pgp-keys
Re: PLEASE TEST (all drivers) sta/ap mode
On 2024-02-14 11:53, Bjoern A. Zeeb wrote: Hi, can I ask everyone who has a spare cycle to test main on/after 0936c648ad0ee5152dc19f261e77fe9c1833fe05 (commit went in a minute ago). Will a freebsd-update install fetch any of these changes? Or will this require building from src on or after 0936c648ad0ee5152dc19f261e77fe9c1833fe05? The last changes include "band-aid" hacks to net80211 which will affect all drivers and sta/ap mode. While the commit messages hint at the problem I'll try to write a longer summary probably next week so we'll have the actual problems in the archives and others can chime in. Thanks, /bz No. Thank *you*. :) --Chris
Re: PLEASE TEST (all drivers) sta/ap mode
On 2024-02-14 13:23, Bjoern A. Zeeb wrote: On Wed, 14 Feb 2024, Chris wrote: On 2024-02-14 11:53, Bjoern A. Zeeb wrote: Hi, can I ask everyone who has a spare cycle to test main on/after 0936c648ad0ee5152dc19f261e77fe9c1833fe05 (commit went in a minute ago). Will a freebsd-update install fetch any of these changes? Or will this require building from src on or after 0936c648ad0ee5152dc19f261e77fe9c1833fe05? There is no freebsd-update support for main (CURRENT) to my best knowledge, so you would have to do this from git. If you are not on main (CURRENT) then for 14 and 13 you'd probably also have to do this from git; for the upcoming 13.3 I would hope that by RC1 the changes will have made it there (likely to miss BETA3). I'm sorry. I *knew* that. But forgot in my enthusiasm to get started. I'll pull down a copy of src and get started. Thanks! --Chris
Re: PLEASE TEST (all drivers) sta/ap mode
On 2024-02-14 11:53, Bjoern A. Zeeb wrote: Hi, can I ask everyone who has a spare cycle to test main on/after 0936c648ad0ee5152dc19f261e77fe9c1833fe05 (commit went in a minute ago). The last changes include "band-aid" hacks to net80211 which will affect all drivers and sta/ap mode. While the commit messages hint at the problem I'll try to write a longer summary probably next week so we'll have the actual problems in the archives and others can chime in. Thanks, /bz I can happily report that your modifications have (at least) prevented a lockup or reboot following a: service netif restart. Prior to your work, this was never possible. It also cleanly associates w/o struggle. Association more often than not failed or struggled repeatedly attempting to connect properly. In an effort to limit any unique variables, I built a completely GENERIC kernel. # uname -a FreeBSD fbsd15 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n268292-70617458676e: Thu Feb 15 13:42:46 PST 2024 root@fbsd15:/usr/obj/usr/src/amd64.amd64/sys/LENO15 amd64 Thank you! --Chris
Re: PLEASE TEST (all drivers) sta/ap mode
On 2024-02-16 07:32, Bjoern A. Zeeb wrote: On Thu, 15 Feb 2024, Chris wrote: On 2024-02-14 11:53, Bjoern A. Zeeb wrote: Hi, can I ask everyone who has a spare cycle to test main on/after 0936c648ad0ee5152dc19f261e77fe9c1833fe05 (commit went in a minute ago). The last changes include "band-aid" hacks to net80211 which will affect all drivers and sta/ap mode. While the commit messages hint at the problem I'll try to write a longer summary probably next week so we'll have the actual problems in the archives and others can chime in. Thanks, /bz I can happily report that your modifications have (at least) prevented a lockup or reboot following a: service netif restart. Prior to your work, this was never possible. It also cleanly associates w/o struggle. Association more often than not failed or struggled repeatedly attempting to connect properly. In an effort to limit any unique variables, I built a completely GENERIC kernel. Thanks Chris; and for the records, I assume this was iwlwifi too. Sorry. Yes. Intel AX201. Thanks again! --Chris # uname -a FreeBSD fbsd15 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n268292-70617458676e: Thu Feb 15 13:42:46 PST 2024 root@fbsd15:/usr/obj/usr/src/amd64.amd64/sys/LENO15 amd64 Thank you! --Chris
Re: WARNING !ht_cap.ht_supported failed at...
Just an update to let you know that after some 5 days of struggling to build/install a new world/kernel (long boring story) that worked. I succeeded. Which gave me the opportunity to test all your hard work... kernel: 15.0-CURRENT #1 main-n276516-65d8491719bb: Mon Apr 21 12:39:46 PDT 2025 root@fbsd15:/usr/obj/usr/src/amd64.amd64/sys/LENOIP15ND amd64 ports revision: commit 79c842114f11e2151d873f1f069b542271f20e1a (HEAD -> main, freebsd/main, freebsd/HEAD) Author: Christos Chatzaras Date: Wed Apr 16 00:16:39 2025 +0200 ifconfig wlan0 (rc.conf): wlans_iwlwifi0="wlan0" ifconfig_wlan0="WPA SYNCDHCP up" ifconfig_wlan0_ipv6="inet6 accept_rtadv" ifconfig wlan0: wlan0: flags=8843 metric 0 mtu 1500 options=0 ether 3c:e9:f7:ec:63:d7 inet 192.168.1.3 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::3ee9:f7ff:feec:63d7%wlan0 prefixlen 64 scopeid 0x2 groups: wlan ssid HighwayToHell channel 157 (5785 MHz 11a vht/80+) bssid 10:0c:6b:4d:44:27 regdomain FCC country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 17 bmiss 7 mcastrate 6 mgmtrate 6 scanvalid 60 -ampdutx ampdurx ampdulimit 64k ampdudensity 4 -amsdutx amsdurx shortgi -ldpctx ldpcrx -uapsd vht vht40 vht80 vht160 -vht80p80 wme roaming MANUAL parent interface: iwlwifi0 media: IEEE 802.11 Wireless Ethernet VHT mode 11ac status: associated nd6 options=23 For reference, this is on an AX201. From my perspective. It works extremely well Thank you! :) I do see this (from dmesg.boot): iwlwifi0: lkpi_sta_a_to_a:2437: lvif 0xfe01200a4000 vap 0xfe01200a4010 iv_bss 0xfe01203ae000 lvif_bss 0xf8000483c800 lvif_bss->ni 0xfe00f5be9000 synched 0 iwlwifi0: lkpi_iv_newstate: error 95 during state transition 2 (AUTH) -> 2 (AUTH) iwlwifi0: lkpi_sta_auth_to_assoc:2348: lvif 0xfe01200a4000 vap 0xfe01200a4010 iv_bss 0xfe01203ae000 lvif_bss 0xf8000483c800 lvif_bss->ni 0xfe00f5be9000 synched 0 iwlwifi0: lkpi_iv_newstate: error 95 during state transition 2 (AUTH) -> 3 (ASSOC) iwlwifi0: Not associated and the session protection is over already... iwlwifi0: linuxkpi_ieee80211_connection_loss: vif 0xfe01200a4ec0 vap 0xfe01200a4010 state AUTH Anything I need concern myself with? All the best to you, Bjoren! --Chris -- sent from hardware written from and running on FreeBSD 0xE512722F.asc Description: application/pgp-keys
Re: WARNING !ht_cap.ht_supported failed at...
On 2025-04-21 20:43, Chris wrote: Just an update to let you know that after some 5 days of struggling to build/install a new world/kernel (long boring story) that worked. I succeeded. Which gave me the opportunity to test all your hard work... kernel: 15.0-CURRENT #1 main-n276516-65d8491719bb: Mon Apr 21 12:39:46 PDT 2025 root@fbsd15:/usr/obj/usr/src/amd64.amd64/sys/LENOIP15ND amd64 ports revision: commit 79c842114f11e2151d873f1f069b542271f20e1a (HEAD -> main, freebsd/main, freebsd/HEAD) Author: Christos Chatzaras Date: Wed Apr 16 00:16:39 2025 +0200 ifconfig wlan0 (rc.conf): wlans_iwlwifi0="wlan0" ifconfig_wlan0="WPA SYNCDHCP up" ifconfig_wlan0_ipv6="inet6 accept_rtadv" ifconfig wlan0: wlan0: flags=8843 metric 0 mtu 1500 options=0 ether 3c:e9:f7:ec:63:d7 inet 192.168.1.3 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::3ee9:f7ff:feec:63d7%wlan0 prefixlen 64 scopeid 0x2 groups: wlan ssid HighwayToHell channel 157 (5785 MHz 11a vht/80+) bssid 10:0c:6b:4d:44:27 regdomain FCC country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 17 bmiss 7 mcastrate 6 mgmtrate 6 scanvalid 60 -ampdutx ampdurx ampdulimit 64k ampdudensity 4 -amsdutx amsdurx shortgi -ldpctx ldpcrx -uapsd vht vht40 vht80 vht160 -vht80p80 wme roaming MANUAL parent interface: iwlwifi0 media: IEEE 802.11 Wireless Ethernet VHT mode 11ac status: associated nd6 options=23 For reference, this is on an AX201. From my perspective. It works extremely well Thank you! :) I do see this (from dmesg.boot): iwlwifi0: lkpi_sta_a_to_a:2437: lvif 0xfe01200a4000 vap 0xfe01200a4010 iv_bss 0xfe01203ae000 lvif_bss 0xf8000483c800 lvif_bss->ni 0xfe00f5be9000 synched 0 iwlwifi0: lkpi_iv_newstate: error 95 during state transition 2 (AUTH) -> 2 (AUTH) iwlwifi0: lkpi_sta_auth_to_assoc:2348: lvif 0xfe01200a4000 vap 0xfe01200a4010 iv_bss 0xfe01203ae000 lvif_bss 0xf8000483c800 lvif_bss->ni 0xfe00f5be9000 synched 0 iwlwifi0: lkpi_iv_newstate: error 95 during state transition 2 (AUTH) -> 3 (ASSOC) iwlwifi0: Not associated and the session protection is over already... iwlwifi0: linuxkpi_ieee80211_connection_loss: vif 0xfe01200a4ec0 vap 0xfe01200a4010 state AUTH Anything I need concern myself with? Oh, and for good measure (sorry too many irons in the fire): ifconfig -v wlan0: wlan0: flags=8843 metric 0 mtu 1500 options=0 ether 3c:e9:f7:ec:63:d7 inet 192.168.1.3 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::3ee9:f7ff:feec:63d7%wlan0 prefixlen 64 scopeid 0x2 groups: wlan ssid HighwayToHell channel 157 (5785 MHz 11a vht/80+) bssid 10:0c:6b:4d:44:27 regdomain FCC country US anywhere -ecm authmode WPA2/802.11i -wps -tsn privacy ON deftxkey UNDEF AES-CCM 2:128-bit powersavemode OFF powersavesleep 100 txpower 17 txpowmax 50.0 -dotd rtsthreshold 2346 fragthreshold 2346 bmiss 7 11a ucast NONEmgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11b ucast NONEmgmt 1 Mb/s mcast 1 Mb/s maxretry 6 11g ucast NONEmgmt 1 Mb/s mcast 1 Mb/s maxretry 6 11naucast NONEmgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11ngucast NONEmgmt 1 Mb/s mcast 1 Mb/s maxretry 6 11acucast NONEmgmt 6 Mb/s mcast 6 Mb/s maxretry 6 scanvalid 60 -bgscan bgscanintvl 300 bgscanidle 250 roam:11a rssi7dBm rate 12 Mb/s roam:11b rssi7dBm rate 1 Mb/s roam:11g rssi7dBm rate 5 Mb/s roam:11narssi7dBm MCS 1 roam:11ngrssi7dBm MCS 1 roam:11acrssi7dBm MCS 1 -pureg protmode CTS ht htcompat -ampdutx ampdurx ampdulimit 64k ampdudensity 4 -amsdutx amsdurx shortgi htprotmode RTSCTS -puren -smps -rifs stbc -ldpctx ldpcrx -uapsd vht vht40 vht80 vht160 -vht80p80 wme -burst -dwds roaming MANUAL bintval 100 AC_BE cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm ack cwmin 0 cwmax 0 aifs 0 txopLimit 0 -acm AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm AC_VI cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm ack cwmin 0 cwmax 0 aifs 0 txopLimit 0 -acm AC_VO cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ack cwmin 0 cwmax 0 aifs 0 txopLimit 0 -acm parent interface: iwlwifi0 media: IEEE 802.11 Wireless Ethernet VHT mode 11ac status: associated nd6 options=23 drivername: wlan0 sysctl compat.linuxkpi: compat.linuxkpi.iwlwifi_mvm_power_scheme: 1 compat.linuxkpi.iwlwifi_disable_11be: 1 compat.linuxkpi.iwlwifi_disable_11ax: 1 compat.linuxkpi.iwlwifi_remove_when_gone: 0 compat.linuxkpi.iwlwifi_disable_1
Re: WARNING !ht_cap.ht_supported failed at...
On 2025-04-16 14:42, Bjoern A. Zeeb wrote: On Wed, 16 Apr 2025, Chris wrote: Hi Chris, Well I just built and installed the net/wifi-firmware-iwlwifi-kmod on a year old world/kernel. Just to be clear: your world and kernel are still a year old or did you update them too afterwards? If not, please do if you want to test iwlwifi becasue there's no support for a year old current iwlwifi and LinuxKPI here anymore, especially if you want to try VHT. Otherwise the next you'll report is year old bugs. Sorry. In my humble defense, from our last conversation: And the iwlwifi/rtw88/rtw89 firmware is not tied to the kernel build anymore given it's a plain firmware file and no kernel module, so it can be built as a normal port/package. With a year old current it should still be fine to build it upfront. ;) To be clear. I deleted the previous kernel drivers supplied by my last kernel build. Then proceeded to /usr/ports/net/wifi-firmware-iwlwifi-kmod and did a make install clean. Stupidly forgetting about using a flavor. :/ But upon reboot (among other things) got the following: I told you to install the respective flavour only but hey... Yep. I forgot to choose a flavor. :( If this is an AX201 you did not install a recent port/package. Your tunables are not reflecting what should be set. Did you update your ports tree before building? Yes. What does % pkg info | grep wifi-firmware-iwlwifi say? wifi-firmware-iwlwifi-kmod-20241017.1500018_2 Firmware modules for the iwlwifi (iwlwifi) WiFi NIC driver What does fwget -n suggest? % fwget -n -v Trying to match device 0x46b3 in class video and vendor intel with pci_video_intel Trying to match device 0x51f0 in class network and vendor intel with pci_network_intel Needed firmware packages: 'gpu-firmware-intel-kmod-alderlake gpu-firmware-intel-kmod-tigerlake' this is fwget(8) from my old kernel. Would a make -C /usr/src/usr.sbin/fwget install clean be enough? Or is a new kernel/world mandatory? WARNING !ht_cap.ht_supported failed at /usr/src/sys/contrib/dev/iwlwifi/iwl-nvm-parse.c:855 I'm guessing I need to build a new world/kernel. This is on current. Right and you mean on a year old current. Please update. The line now looks like ;-) 855 }, dmesg(8) returns: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x370 loader.conf(5) contains: compat.linuxkpi.iwlwifi_disable_11ac=0 compat.linuxkpi.iwlwifi_disable_11ax=0 Right. Please just install the firmware package and stop trying to set random things yourself. There's multiple correct samples in the last 7 weeks of wireless list archives if you don't trust what the package would do for you. Right. I installed the firmware from a git up of ports done yesterday. I got "compat.linuxkpi.iwlwifi_disable_11ac=0" from a recent message on the list. "compat.linuxkpi.iwlwifi_disable_11ax=0" was a hopeful shot in the dark. Now removed. (a) it is unclear if you have hw_crypto set? sysctl compat.linuxkpi.80211.hw_crypto % sysctl compat.linuxkpi.80211.hw_crypto sysctl: unknown oid 'compat.linuxkpi.80211.hw_crypto' (b) you have 11n disabled: iwlwifi_11n_disable=1 but 11ac/11ax on and thus you get a warning. This is not what the package would do. I made no changes to iwlwifi_11n_disable. I guess nothing was done. (c) if you enable 11ax you are on your own. Understood. I'll stop doing that. (d) what does cat /boot/loader.conf.d/iwlwifi-22000.conf say? If nothing, is there any file there? ls -l /boot/loader.conf.d/iwlwifi-*.conf If not then we are back to the beginning that the firmware is not recent. Start by installing a recent firmware package and then Right. Both return nothing. So a new kernel/world appears required. do your kernel/world update. Headed to /usr/src/ after this reply. :) Hope this helps, Immensely! Sorry for all the bother. Bjoern --Chris -- sent from hardware written from and running on FreeBSD 0xE512722F.asc Description: application/pgp-keys
Re: Experimental regdomain.xml update
On 2025-04-27 11:26, Bjoern A. Zeeb wrote: Hi Bjoern. Thanks for all the work you're doing here! I have the time to devote to this to perform a complete rewrite for you. So as to free some of your time for other things. Would you consider the Linux wireless-regdb to be the defacto on this? Or should other sources also be considered to better reconcile? Thanks again. --Chris Hi, after having done multiple countries by hand I sat down and wrote the hack of a perl script and used the Linux wireless-regdb db.txt file as input. This "explodes" the regdomain to countries only so there's no more FCC or ETSI in there; there's also some other bits missing as I only did 2.4Ghz and 5Ghz bands so far. SKUs are also gone. The DEBUG entry is missing. I have no idea if or how much I got it right. I tried to resolve AUTO-BW for larger channel widths (so that we do not lose a few 160Mhz channels) but I am sure I missed subtleties. You can fetch an initial experimental snapshot at: https://people.freebsd.org/~bz/wireless/regdomain-20250427.xml (md5: f3a6497490ae8bd615e1d536e941a2f6) Please review your country data and give it a try; especially if you are in a country which wasn't updated in a decade or longer... After manually putting the file in as /etc/regdomain.xml (make a copy of the original first!) you will need to (1) ifconfig wlan0 down (2) ifconfig wlan0 country <00> regdomain <00> (3) ifconifg wlan0 up Then you can check: ifconfig -v wlan0 list countries ifconfig -v wlan0 list regdomain ifconfig -v wlan0 list channels Lots of health, Bjoern FAQ: Q: This is great! How can I keep it? A: By manually making sure you re-install it or not overwriting it with etcupdate. A: Also make sure to make your regdomain/country entries permanent (in rc.conf or wpa_supplicant.conf). Q: is this going to be the new format? A: no, this is likely not going to solve all our problems, like the original db.txt also cannot represent everything. Q: Things no longer work. What do I do? A: First install the regdomain.xml you saved a copy of or grab one from the freebsd repository source tree and do the down/up dance again. A: The please email me with the output of the above ifconfig commands and a detailed description of your problem, Q: Regulatory information is wrong for my country. What do I do? A: Check upstream first. If it is correct there let me know as that means I need to fix the hack of a perl script. A: Otherwise? Good question. In theory we should get it fixed upstream but there is no worklfow yet given this is experimental. Let us know and if you want please also submit it upstream yourself as you are more likely to understand legal documents in your language. Q: my country name changed - why? It's not correct! A: This is based on the UN list as quoted in the top comment of the file. I did not review it for anything but the three problems I hit. Please don't start a flame war. Just drop me a private email and I'll put the old entry back in for now. -- sent from hardware written from and running on FreeBSD 0xE512722F.asc Description: application/pgp-keys
Re: WARNING !ht_cap.ht_supported failed at...
On 2025-04-22 16:33, Bjoern A. Zeeb wrote: On Mon, 21 Apr 2025, Chris wrote: Comments inline... Hi, Just an update to let you know that after some 5 days of struggling to build/install a new world/kernel (long boring story) that worked. I succeeded. Which gave me the opportunity to test all your hard work... kernel: 15.0-CURRENT #1 main-n276516-65d8491719bb: Mon Apr 21 12:39:46 PDT 2025 root@fbsd15:/usr/obj/usr/src/amd64.amd64/sys/LENOIP15ND amd64 ports revision: commit 79c842114f11e2151d873f1f069b542271f20e1a (HEAD -> main, freebsd/main, freebsd/HEAD) Author: Christos Chatzaras Date: Wed Apr 16 00:16:39 2025 +0200 ifconfig wlan0 (rc.conf): wlans_iwlwifi0="wlan0" ifconfig_wlan0="WPA SYNCDHCP up" ifconfig_wlan0_ipv6="inet6 accept_rtadv" ifconfig wlan0: wlan0: flags=8843 metric 0 mtu 1500 options=0 ether 3c:e9:f7:ec:63:d7 inet 192.168.1.3 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::3ee9:f7ff:feec:63d7%wlan0 prefixlen 64 scopeid 0x2 groups: wlan ssid HighwayToHell channel 157 (5785 MHz 11a vht/80+) bssid 10:0c:6b:4d:44:27 regdomain FCC country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 17 bmiss 7 mcastrate 6 mgmtrate 6 scanvalid 60 -ampdutx ampdurx ampdulimit 64k ampdudensity 4 -amsdutx amsdurx shortgi -ldpctx ldpcrx -uapsd vht vht40 vht80 vht160 -vht80p80 wme roaming MANUAL parent interface: iwlwifi0 media: IEEE 802.11 Wireless Ethernet VHT mode 11ac status: associated nd6 options=23 For reference, this is on an AX201. From my perspective. It works extremely well Thank you! :) Hopefully we'll make it work even better... I do see this (from dmesg.boot): iwlwifi0: lkpi_sta_a_to_a:2437: lvif 0xfe01200a4000 vap 0xfe01200a4010 iv_bss 0xfe01203ae000 lvif_bss 0xf8000483c800 lvif_bss->ni 0xfe00f5be9000 synched 0 iwlwifi0: lkpi_iv_newstate: error 95 during state transition 2 (AUTH) -> 2 (AUTH) iwlwifi0: lkpi_sta_auth_to_assoc:2348: lvif 0xfe01200a4000 vap 0xfe01200a4010 iv_bss 0xfe01203ae000 lvif_bss 0xf8000483c800 lvif_bss->ni 0xfe00f5be9000 synched 0 iwlwifi0: lkpi_iv_newstate: error 95 during state transition 2 (AUTH) -> 3 (ASSOC) The above is a result of how net80211 works internally. Something to attack the next months ... However it also means you lost connection or didn't make it ... see next... iwlwifi0: Not associated and the session protection is over already... iwlwifi0: linuxkpi_ieee80211_connection_loss: vif 0xfe01200a4ec0 vap 0xfe01200a4010 state AUTH That is more of a concern as it means association didn't finish in time. Too much noise? No good signal? Something else? The AP is some 15 feet from this laptop. Aside from a TV remote, no. Thanks for all the information, Bjoern. --Chris -- sent from hardware written from and running on FreeBSD 0xE512722F.asc Description: application/pgp-keys
Re: Watch out for 850Mbit/s WiFi
On 2025-04-10 18:43, Bjoern A. Zeeb wrote: Hi, I had a bit of fun tonight after all and figured out what prevented me from enabling VHT80P80 and VHT160 since January for testing. Patches to come to review tomorrow (well that is today here). Turns out I cannot test VHT80P80 currently. This is likely the first VHT/160 assoc on FreeBSD so I thought I'd send the email. And I ran the simple silly iperf3 test. Not much more than VHT80 but I am also sure I am starting to hit other limits in this test setup. It goes from the AX210 in a bhyve instance to AP to a small 4 port switch and back into em0 on the same laptop just the base system running the iperf3 server. Down there is UDP TX from the wifi set to 960Mbit/s target rate. Don't expect that with single stream TCP. Yet another thing to debug ;) Keep in mind we are still copying the full frame incl. data from skb to mbuf or vice versa depending on direction and other fun bits to optimize one day. I guess I'll try to find an AP supporting 11BE and SFP+ for 10G DAC or fiber for christmas this year... until then it'll be other things to get us stable first. Try it our yourself please -- even with VHT80! I'm in! :) Where do I get all this magic? I'm also on an AX210 in an ideapad. I'm on current that's about a year out (kernel/world). So as I perform the world/kernel dance I want to get the right driver setup. Sorry for all the questions. But the WiFi page is a year out of date. You indicated fwget(8) as the procedure. But I build *everything*. So not an option. It seems it'd also be hard for a first time install where you (as yet) have no connectivity. :) Anyway. Is it enough to add net/wifi-firmware-iwlwifi-kmod to PORTS_MODULES in src.conf? Thanks, and thank you very much for all the work you put into this! --Chris Lots of joy Bjoern -- sent from a device written from and running on FreeBSD
