Created attachment 233540 [details]
I've spent a few days reading _a lot_ of documentation and experimenting with getting FreeBSD running on my Framework Laptop on 13.0-RELEASE, 13.1-RC4, and 14-CURRENT (just to see how far all of the branches are working on it - although originally I wanted to just run 13.1 since that's the next RELEASE but I was getting too many issues and crashes with it.. and I've been avoiding jumping into STABLE/CURRENT, but c'est la vie haha). I've definitely noticed a bunch of issues that either already got fixed, or still remain (but I've yet gathered exact repro scenarios). However, for this particular issue (and I'm not sure if it's 100% related but I think it might be), the Intel AX210 card on the framework laptop seems to associate with my AP properly, but no DHCPOFFERS are received. I think there was only one time a few days ago on an older build of CURRENT that I was able to get it to get an IP, but I haven't been able to replicate that working state.
Also, this is on the sources for 14-CURRENT (for both world and kernel) as of today 2022-04-27. I'm motivated to help any of the devs test any code needed to get, not only this issue, but really anything regarding the framework laptop as an actual desktop productivity machine. I'm not a FreeBSD pro, but have been using it on my home server for the past 2~ years. So apologies if there any particular concepts or things I don't yet know, feel free to point me in the right direction though :).
I've attached various parts of my system config and dmesg output to help debug this.
I've noticed that I sometimes get the following errors as well (I've also looked at what the Linux community said about those errors and it seems they were fixed in 5.13):
iwlwifi0: iwl_trans_send_cmd bad_state = 0
iwlwifi0: Failed to remove MAC context: -5
Given the above situation where the system started up the wlan0 interfaced (parent: iwlwifi0) and was associated to the AP but did not receive any DHCP offers:
1. ifconfig wlan0 down
2. ifconfig wlan0 192.168.1.105/24 netmask 255.255.255.0
> The command will trigger, and a few seconds later it will hard crash. I've attached a camera shot of this. But something relevant may be the following:
iwlwifi0: Failed to send binding (action:1): -5
iwlwifi0: PHY ctxt cmd error. ret=-5
iwlwifi0: lkpi_iv_newstate: error -5 during state transition 1 (SCAN) -> 2 (AUTH)
iwlwifi0: No queue was found. Dropping TX
iwlwifi0: Failed to trigger RX queues sync (-5)
panic: lkpi_sta_auth_to_scan: lsta 0xfffff8012f0c5800 state not NONE: 0, nstate 1 arg 1
Overall, this laptop seems to have slowly gotten better support so that's definitely encouraging and I also read the recent news about FreeBSD and the work going on to improve Framework Laptop support. The wifi issues caused hard reboots on 13.1-RC4 current (It would just shut off, I believe the "firmware dying in a fire" that Kyle Evans mentioned here: https://lists.freebsd.org/archives/freebsd-wireless/2021-October/000099.html might have been what he meant by that). This may or may not be the same bug that I'm experiencing here, but maybe since I'm running -CURRENT now with the default debug configuration, "hard crash reboots" turn into "hard crash - do not reboot" situations?
Anyways, let me know if anything and I can further help debug.
Created attachment 233541 [details]
Created attachment 233542 [details]
Created attachment 233543 [details]
Created attachment 233544 [details]
Created attachment 233545 [details]
camera photo of crash
Created attachment 233548 [details]
rtwn0 external usb 2.0 wifi adapter info
I just tested an external USB 2.0 Wifi adapter that I had and it is detected by FreeBSD, lights up, and is able to associate, but didn't receive an IP. This could indicate that maybe I've just misconfigured something somewhere (I did follow all of the Advance Wireless Configuration steps in the handbook) when in comes to the IP association part. However, the hard crash that I detected is still a bug. Attaching output for the 'rtwn0' wifi adapter.
(In reply to Jonathan Vasquez from comment #2)
Not sure if it matters. But in my case. I need to blacklist
then I add if_iwlwifi to my kld_list.
Maybe this might help?
I don't crash. :-)
Thanks for that :). So I've been playing around with the system for the whole day today trying to understand the behavior of this machine in conjunction with FreeBSD and its drivers. There's just too many variables to explain everything but the good news is that with Chris' suggestion, DHCP now works on the iwlwifi0 adapter. DHCP doesn't work on the rwtn0 device though (I'm testing both to further test the interaction of the drivers and the hardware). All the devices are working on Linux from the last time I tested them. Static IP assignment still crashes the iwlwifi0 device, and I was able to get Static IP working in the rwtn0 device but it doesn't consistently work across -immediate- reboots (I haven't tested more cold scenario since as I said, I was playing around with it for the whole day lol). Sometimes it takes 15 seconds for it to work, sometimes it takes 45+ seconds, and something it just doesn't work.
There were also some other settings I was missing during static ip assignment, specifically setting the: defaultrouter="<ip>" field. I was able to test this through /etc/rc.conf + service netif restart, and I also tried to manually construct the device and see if it worked. It basically yielded the above results.
ifconfig wlan0 create wlandev rwtn0
ifconfig wlan0 up
ifconfig wlan0 scan (Shows the AP)
wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
On another terminal (tmux):
ifconfig wlan0 inet 192.168.1.101 netmask 255.255.255.0
route add default 192.168.1.1
echo "nameserver 192.168.1.1" > /etc/resolv.conf
ping 192.168.1.1 (No response, non-deterministic as above results described)
netstat -rn and arp -a showed what you would expect in a correct working network (like the default gateway being set to 192.168.1.1 and the iface it used as wlan0).
So yea, lots of different interactions here. I also noticed sometimes if I left the "ifconfig_ue0="DHCP" in the file, sometimes I wouldn't get a DHCP request on the wireless card side.. but after many hours later I tried leaving both of them enabled and it was still working fine.. so it could have just been some weirdness. I even rebooted my router just to make sure (even though everything was working, including multiple other machines connected to the same router).
this is my current /etc/rc.conf for further info
root@leslie:~ # cat /etc/rc.conf
create_args_wlan0="regdomain FCC country US"
#ifconfig_wlan0="inet 192.168.1.101 netmask 255.255.255.0 ssid Summerland WPA"
Either way, at least we were able to find another bug (the static ip assignment on the iwlwifi0 card causes a crash).
(1) For the AX210 iwm(4) blocklisting should make zero difference as the IDs won't be in the driver and so it'll not probe or try to attach. Something else funky is going on and it highly smells like "timing".
(2) The ifconfig wlan0 down is currently known to leave state behind on iwlwifi which will then in the follow-up result in the SW crash; I was hoping I could fix that while I was on the road but will try to do so when I am back in the office next week.
(3) I'd highly appreciate if the bug report could not be convoluted with too many different issuesas it'll be hard for me to follow otherwise.
(4) If DHCP is an issue ifconfig list scan showing the AP doesn't mean you are associated. You need to check for the "status: associated" in ifconfig wlan0 or otherwise possibly in wpa. Likewise for manual configuration.
Thanks for taking a look into this.
1. Yup that may be the case.
2. Sounds good.
3. I only posted particular pieces of information (all networking related) that I thought may affect this particular PR. So it's done primarily for the sake of completeness to make sure everything is accounted for. I know the FreeBSD community is highly RTFM so I wanted to make sure I covered as much as I could regarding the networking situation.
4. Yup I'm aware of that. My posts mentioned that ifconfig wlan0 scan displayed the ssid since previous instructions I've read mentioned to check if your wifi adapter even displays the ssid in the first place (or any wifi networks at all). If you check my ifconfig output, it will display that it is in fact associated.
Let me know if there is anything else you want me to test out in the meantime that can further assist you.
I just retested again without having the devlist_blacklist="if_iwm" and also without "if_iwlwifi" in kld_list. It seems to have no effect now (as you said Bjoern). I noticed the 'if_iwlwifi' get autoloaded a bit before the firmware is used either way so that line probably doesn't have much effect in this case.
This is probably related to this but I noticed that if I did multiple reboots in sequence, the ability for the wifi card to re-establish a connection diminished. I'm guessing this maybe regarding the state, but not OS state, but firmware state, I'm guessing there may be some sort of SRAM chip in there that is maintaining the previous state of the multiple and subsequent reboots. This may explain why if I wait a bit (I kinda have to right lol) it eventually is able to connect again.