Dell 3440 laptop, with iwlwifi, Intel AX211. Installing 14.0-RC4 from the disc1 image. After 5s of scanning the installer reports "No wireless networks were found. Rescan?". Choosing <Yes> again scans for 5s and reports the same. Switching to a shell vty (Ctrl-Alt-F4) and running "wpa_cli scan" followed by "wpa_cli scan_results" a few seconds later times out with no output. Running "ifconfig wlan0 scan" does report SSIDs.
This works with a USB device supported by if_rtwn.
If you can switch to the shell, do we log anything for wpa? What do the logs show? Is the interface UP the first time we scan from the installer? Instead of running ifconfig wlan0 scan what does ifconfig wlan0 list scan show (i.e., did we have scan results already and wpa didn't get them)?
(In reply to Bjoern A. Zeeb from comment #2) Is this new? I use wpa_cli regularly but after a full VM update to main Nov 3 I do see it too now. I definitively used scan and scan_results a lot a while ago (around 3f382eb23b9f). Selected interface 'wlan0' Interactive mode > scan_results 'SCAN_RESULTS' command timed out. Nov 10 00:46:19 bhyve-freebsd wpa_supplicant[801]: CTRL_IFACE monitor attached /tmp/wpa_ctrl_901-... Nov 10 00:46:19 bhyve-freebsd wpa_supplicant[801]: wlan0: Control interface command 'LIST_CREDS' Nov 10 00:46:19 bhyve-freebsd wpa_supplicant[801]: wlan0: Control interface command 'LIST_NETWORKS' Nov 10 00:46:21 bhyve-freebsd wpa_supplicant[801]: wlan0: Control interface command 'SCAN_RESULTS' Nov 10 00:46:21 bhyve-freebsd wpa_supplicant[801]: wlan0: ctrl_iface sendto failed: 40 - Message too long I've not seen this error before. Time to ktrace?
(In reply to Bjoern A. Zeeb from comment #3) 787 wpa_supplicant RET select 1 787 wpa_supplicant CALL recvfrom(0x8,0x37f2f0b3b000,0x2001,0,0x12caf2c84fc0,0x12caf2c84fbc) 787 wpa_supplicant GIO fd 8 read 12 bytes "SCAN_RESULTS" 787 wpa_supplicant STRU struct sockaddr { AF_LOCAL, /tmp/wpa_ctrl_889-1 } 787 wpa_supplicant RET recvfrom 12/0xc 787 wpa_supplicant CALL __sysctl(0x12caf2c80900,0x2,0x12caf2c84a10,0x12caf2c808f8,0,0) 787 wpa_supplicant SCTL "kern.hostname" 787 wpa_supplicant RET __sysctl 0 787 wpa_supplicant CALL getpid 787 wpa_supplicant RET getpid 787/0x313 787 wpa_supplicant CALL sendto(0x3,0x12caf2c82a10,0x8c,0,0,0) 787 wpa_supplicant GIO fd 3 wrote 140 bytes "<31>1 2023-11-10T00:55:16.443663+00:00 bhyve-freebsd.<reducted> wpa_supplicant 787 - - wlan0: Control interface command 'SCAN_RESULTS'" 787 wpa_supplicant RET sendto 140/0x8c 787 wpa_supplicant CALL sendto(0x8,0x37f2f0a1d000,0x999,0,0x12caf2c84fc0,0x6a) 787 wpa_supplicant STRU struct sockaddr { AF_LOCAL, /tmp/wpa_ctrl_889-1 } 787 wpa_supplicant RET sendto -1 errno 40 Message too long
(In reply to Bjoern A. Zeeb from comment #2) > Instead of running ifconfig wlan0 scan what does ifconfig wlan0 list scan show > (i.e., did we have scan results already and wpa didn't get them)? Following up for posterity, it's awkward trying to reproduce this via the installer (which does not get around to configuring the network until after disk setup. From the installed system I tried wpa_cli scan followed by wpa_cli scan_results which timed out. ifconfig wlan0 list scan does show all of the expected networks. > Is this new? I use wpa_cli regularly but after a full VM update to main Nov 3 I do see > it too now. I definitively used scan and scan_results a lot a while ago (around > 3f382eb23b9f). This is a new machine I just purchased for FreeBSD bring-up, and the 14.0-RC4 installer is the first time I've tried FreeBSD on it. Moving on from scanning and attempting to use the configured network: iwlwifi0: WRT: Invalid buffer destination iwlwifi0: WFPM_UMAC_PD_NOTIFICATION: 0x20 iwlwifi0: WFPM_LMAC2_PD_NOTIFICATION: 0x1f iwlwifi0: WFPM_AUTH_KEY_0: 0x90 iwlwifi0: CNVI_SCU_SEQ_DATA_DW9: 0x0 iwlwifi0: RFIm is deactivated, reason = 4 iwlwifi0: RFIm is deactivated, reason = 4 wlan0: Ethernet address: XX:XX:XX:XX:XX:XX lo0: link state changed to UP wlan0: link state changed to UP wlan0: link state changed to DOWN iwlwifi0: Not associated and the session protection is over already... wlan0: link state changed to UP wlan0: link state changed to DOWN lo0: link state changed to DOWN iwlwifi0: WRT: Invalid buffer destination iwlwifi0: WFPM_UMAC_PD_NOTIFICATION: 0x20 iwlwifi0: WFPM_LMAC2_PD_NOTIFICATION: 0x1f iwlwifi0: WFPM_AUTH_KEY_0: 0x90 iwlwifi0: CNVI_SCU_SEQ_DATA_DW9: 0x0 iwlwifi0: RFIm is deactivated, reason = 4 iwlwifi0: RFIm is deactivated, reason = 4 wlan0: Ethernet address: XX:XX:XX:XX:XX:XX lo0: link state changed to UP wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost iwlwifi0: lkpi_iv_newstate: error -5 during state transition 2 (AUTH) -> 1 (SCAN) WARNING vif_link->ap_sta_id != 0xFF failed at /usr/src/sys/contrib/dev/iwlwifi/mvm/mld-sta.c:612 iwlwifi0: Microcode SW error detected. Restarting 0x0. iwlwifi0: Start IWL Error Log Dump: iwlwifi0: Transport status: 0x0000004B, valid: 6 iwlwifi0: Loaded firmware version: 83.e8f84e98.0 so-a0-gf-a0-83.ucode iwlwifi0: 0x00000071 | NMI_INTERRUPT_UMAC_FATAL iwlwifi0: 0x00008210 | trm_hw_status0 iwlwifi0: 0x00000000 | trm_hw_status1 iwlwifi0: 0x004DB338 | branchlink2 iwlwifi0: 0x004D119A | interruptlink1 iwlwifi0: 0x004D119A | interruptlink2 iwlwifi0: 0x0000B75A | data1 iwlwifi0: 0x00000010 | data2 iwlwifi0: 0x00000000 | data3 iwlwifi0: 0x00000000 | beacon time iwlwifi0: 0x00D8C66D | tsf low iwlwifi0: 0x00000000 | tsf hi iwlwifi0: 0x00000000 | time gp1 iwlwifi0: 0x00DA0A07 | time gp2 iwlwifi0: 0x00000001 | uCode revision type iwlwifi0: 0x00000053 | uCode version major iwlwifi0: 0xE8F84E98 | uCode version minor iwlwifi0: 0x00000370 | hw version iwlwifi0: 0x00480002 | board version iwlwifi0: 0x802DFC01 | hcmd iwlwifi0: 0x24020000 | isr0 iwlwifi0: 0x01000000 | isr1 iwlwifi0: 0x48F00002 | isr2 iwlwifi0: 0x00C2000C | isr3 iwlwifi0: 0x00200000 | isr4 iwlwifi0: 0x0A01001C | last cmd Id iwlwifi0: 0x0000B75A | wait_event iwlwifi0: 0x000000D4 | l2p_control iwlwifi0: 0x00010034 | l2p_duration iwlwifi0: 0x00000007 | l2p_mhvalid iwlwifi0: 0x00000000 | l2p_addr_match iwlwifi0: 0x00000009 | lmpm_pmg_sel iwlwifi0: 0x00000000 | timestamp iwlwifi0: 0x0000C8F4 | flow_handler iwlwifi0: Start IWL Error Log Dump: iwlwifi0: Transport status: 0x0000004B, valid: 7 iwlwifi0: 0x20101F05 | ADVANCED_SYSASSERT iwlwifi0: 0x00000000 | umac branchlink1 iwlwifi0: 0x80471ABC | umac branchlink2 iwlwifi0: 0x010A4346 | umac interruptlink1 iwlwifi0: 0x00000000 | umac interruptlink2 iwlwifi0: 0x00000000 | umac data1 iwlwifi0: 0x00000003 | umac data2 iwlwifi0: 0xDEADBEEF | umac data3 iwlwifi0: 0x00000053 | umac major iwlwifi0: 0xE8F84E98 | umac minor iwlwifi0: 0x00DA0A01 | frame pointer iwlwifi0: 0xC0886BEC | stack pointer iwlwifi0: 0x00440308 | last host cmd iwlwifi0: 0x00000000 | isr status reg iwlwifi0: IML/ROM dump: iwlwifi0: 0x00000B03 | IML/ROM error/state iwlwifi0: 0x000080C5 | IML/ROM data1 iwlwifi0: 0x00000090 | IML/ROM WFPM_AUTH_KEY_0 iwlwifi0: Fseq Registers: iwlwifi0: 0x60000000 | FSEQ_ERROR_CODE iwlwifi0: 0x803E0003 | FSEQ_TOP_INIT_VERSION iwlwifi0: 0x00190003 | FSEQ_CNVIO_INIT_VERSION iwlwifi0: 0x0000A652 | FSEQ_OTP_VERSION iwlwifi0: 0x00000003 | FSEQ_TOP_CONTENT_VERSION iwlwifi0: 0x4552414E | FSEQ_ALIVE_TOKEN iwlwifi0: 0x00080400 | FSEQ_CNVI_ID iwlwifi0: 0x00401410 | FSEQ_CNVR_ID iwlwifi0: 0x00080400 | CNVI_AUX_MISC_CHIP iwlwifi0: 0x00401410 | CNVR_AUX_MISC_CHIP iwlwifi0: 0x00009061 | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM iwlwifi0: 0x00000061 | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR iwlwifi0: 0x00190003 | FSEQ_PREV_CNVIO_INIT_VERSION iwlwifi0: 0x003E0003 | FSEQ_WIFI_FSEQ_VERSION iwlwifi0: 0xAF793790 | FSEQ_BT_FSEQ_VERSION iwlwifi0: 0x000001D6 | FSEQ_CLASS_TP_VERSION iwlwifi0: UMAC CURRENT PC: 0x80493890 iwlwifi0: LMAC1 CURRENT PC: 0xd0 iwlwifi0: WRT: Collecting data: ini trigger 4 fired (delay=0ms). iwlwifi0: FW error in SYNC CMD MAC_CONFIG_CMD #0 0xffffffff80daa3bb at linux_dump_stack+0x1b #1 0xffffffff83673783 at iwl_trans_txq_send_hcmd+0x3f3 #2 0xffffffff8360f29e at iwl_trans_send_cmd+0xce #3 0xffffffff83652329 at iwl_mvm_send_cmd_pdu+0x49 #4 0xffffffff83655d56 at iwl_mvm_mld_mac_ctx_send+0x316 #5 0xffffffff83656f55 at iwl_mvm_mld_link_info_changed+0x3c5 #6 0xffffffff80d9d576 at lkpi_sta_assoc_to_run+0x2a6 #7 0xffffffff80da3f5a at lkpi_iv_newstate+0x39a #8 0xffffffff80cd463a at ieee80211_newstate_cb+0x17a #9 0xffffffff80ba5922 at taskqueue_run_locked+0x182 #10 0xffffffff80ba6bb2 at taskqueue_thread_loop+0xc2 #11 0xffffffff80afdb0f at fork_exit+0x7f #12 0xffffffff80fe488e at fork_trampoline+0xe iwlwifi0: Failed to send MAC_CONFIG_CMD (action:2): -5 iwlwifi0: failed to update MAC ... iwlwifi0: failed to update power mode iwlwifi0: mcast filter cmd error. ret=-5 iwlwifi0: Failed to synchronize multicast groups update WARNING iwl_mvm_enable_beacon_filter(mvm, vif, 0) failed at /usr/src/sys/contrib/dev/iwlwifi/mvm/mac80211.c:3806 iwlwifi0: Failed to send MAC_CONFIG_CMD (action:2): -5 iwlwifi0: Failed to send MAC_CONFIG_CMD (action:2): -5 iwlwifi0: failed to update MAC ... wlan0: link state changed to UP iwlwifi0: Failed to send flush command (-5) iwlwifi0: flush request fail iwlwifi0: Failed to send flush command (-5) iwlwifi0: flush request fail iwlwifi0: Couldn't send the SESSION_PROTECTION_CMD iwlwifi0: iwl_trans_wait_txq_empty bad state = 0 iwlwifi0: iwl_trans_wait_txq_empty bad state = 0 iwlwifi0: Failed to trigger RX queues sync (-5) wlan0: link state changed to DOWN iwlwifi0: Failed to synchronize multicast groups update iwlwifi0: Failed to send MAC_CONFIG_CMD (action:2): -5 iwlwifi0: failed to update MAC ... iwlwifi0: Failed to send flush command (-5) iwlwifi0: Failed to send MAC_CONFIG_CMD (action:2): -5 iwlwifi0: failed to update MAC ... iwlwifi0: Failed to send LINK_CONFIG_CMD (action:2): -5 iwlwifi0: PHY ctxt cmd error. ret=-5 iwlwifi0: Scan failed! ret -5 iwlwifi0: ERROR: lkpi_ic_scan_start: hw_scan returned -5 iwlwifi0: Scan failed! ret -5 iwlwifi0: ERROR: lkpi_ic_scan_start: hw_scan returned -5 iwlwifi0: Scan failed! ret -5 iwlwifi0: ERROR: lkpi_ic_scan_start: hw_scan returned -5 iwlwifi0: Scan failed! ret -5 iwlwifi0: ERROR: lkpi_ic_scan_start: hw_scan returned -5
(In reply to Ed Maste from comment #5) How did you try to "configure" your network? Was there a service netif restart involved because even your lo0 went DOWN? Everything that follows there is described in 271979 now, just given you are on stable the KASSERT won't trigger and you see a later follow-up. We should leave this PR to the wpa problem; I added cy@ to Cc: yesterday on the PR. Given I didn't see any updates and WiFi hasn't changed since before RC1 I still wonder if other kernel changes are a problem here? I'll start a bisect.
(In reply to Bjoern A. Zeeb from comment #6) > How did you try to "configure" your network? Yes this output was after `service netif restart`. > We should leave this PR to the wpa problem; I added cy@ to Cc: yesterday on the PR. OK - sounds good.
(In reply to Ed Maste from comment #7) Can you try before calling wpa_cli: sysctl net.local.dgram.maxdgram=8192 Also if you do: ifconfig wlan0 list scan | wc -l how many do you see? For me 27 BSSIDs visible here are above the default 2k limit. No guarantees that it is the same problem for you but that is what maked it timeout here and return Message too long.
(In reply to Bjoern A. Zeeb from comment #8) > Can you try before calling wpa_cli: > > sysctl net.local.dgram.maxdgram=8192 Ah, yes it is the same issue and wpa_cli scan_results is successful after making that change. # wpa_cli scan_results | wc -l 72
(In reply to Ed Maste from comment #9) Good. That's why some people see and some don't. Also explains why over summer I did not see. Too silent neighbourhood. Should we update the kernel maximum as adjusting the sysctl probably doesn't do users much good? Do you want to drive that?
(In reply to Bjoern A. Zeeb from comment #10) > Good. That's why some people see and some don't. Also explains why over summer I did > not see. Too silent neighbourhood. I'm somewhat surprised I see this many APs where I am (not in a condo or apartment building). > Should we update the kernel maximum as adjusting the sysctl probably doesn't do users > much good? > > Do you want to drive that? I can take a look at that, but I think wpa_supplicant needs to be able to handle the case where the scan results don't fit in a single dgram (either because the user has lowered it from whatever the default becomes, or because there are just a very large number of APs visible).
(In reply to Ed Maste from comment #11) Yes, the number of BSSIDs surprised me too. You probably can best say if they seem legit. Removing iwlwifi from the subject and blocking as it seems unrelated. The possible fix for wpa is assumed to be here: https://reviews.freebsd.org/D42558 once the SO_SNDBUF regression is fixed.
Can you try wpa_supplicant with the -dd option?
(In reply to Cy Schubert from comment #13) @cy; see comment #9 and the review in comment #12. Should really assign this to glebius@ by now.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=60c99d3a93081cc603e104c0e6c9fe389e774657 commit 60c99d3a93081cc603e104c0e6c9fe389e774657 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2023-11-29 16:16:49 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2023-11-29 16:18:11 +0000 security/wpa_supplicant*: ctrl_iface set sendbuf size In order to avoid running into the default net.local.dgram.maxdgram of 2K currently when calling sendto(2) try to set the sndbuf size to the maximum ctrl message size. The problem occured, e.g., when the scan_list result had enough BSSIDs so the text output would exceed 2048 bytes. Written by: bz PR: 274990 Obtained from: https://reviews.freebsd.org/D42558 security/wpa_supplicant-devel/Makefile | 1 + ...patch-wpa__supplicant_ctrl__iface__unix.c (new) | 36 ++++++++++++++++++++++ security/wpa_supplicant/Makefile | 2 +- ...patch-wpa__supplicant_ctrl__iface__unix.c (new) | 36 ++++++++++++++++++++++ 4 files changed, 74 insertions(+), 1 deletion(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=be7c095ac99ad29fd72b780c7d58949a38656c66 commit be7c095ac99ad29fd72b780c7d58949a38656c66 Author: Gleb Smirnoff <glebius@FreeBSD.org> AuthorDate: 2023-12-01 23:37:29 +0000 Commit: Gleb Smirnoff <glebius@FreeBSD.org> CommitDate: 2023-12-01 23:37:29 +0000 unix/dgram: bump maximum datagram size limit to 8k This is important for wpa_supplicant operation on a crowded network. Note: we actually need an API to increase maximum datagram size on a socket. Previously SO_SNDBUF magically acted like that, but that was an undocumented "feature". Also move the comment to the proper line. Previously it was the receive buffer that imposed the limit. Now notion of buffer size and maximum datagram are separate. Reviewed by: bz, tuexen, karels Differential Revision: https://reviews.freebsd.org/D42830 PR: 274990 sys/kern/uipc_usrreq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=1edc20b76953d9ef571b0bcf89b206b98ed13d9b commit 1edc20b76953d9ef571b0bcf89b206b98ed13d9b Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2023-11-12 20:33:41 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2023-12-02 20:37:36 +0000 wpa: ctrl_iface set sendbuf size In order to avoid running into the default net.local.dgram.maxdgram of 2K currently when calling sendto(2) try to set the sndbuf size to the maximum ctrl message size. While on 14 and 15 this does not actually raise the limit anymore (and be7c095ac99ad29fd72b780c7d58949a38656c66 raised it for syslogd and this), FreeBSD 13 still requires this change and it will work as expected there. In addition we always ensure a large enough send buffer this way independent of kernel defaults. The problem occured, e.g., when the scan_list result had enough BSSIDs so the text output would exceed 2048 bytes. Sponsored by: The FreeBSD Foundation MFC after: 3 days PR: 274990 Reviewed by: cy, adrian (with previous comment) Differential Revision: https://reviews.freebsd.org/D42558 contrib/wpa/wpa_supplicant/ctrl_iface_unix.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ac84975e4a1f89a608a3c6ba8f8322b19a83421e commit ac84975e4a1f89a608a3c6ba8f8322b19a83421e Author: Gleb Smirnoff <glebius@FreeBSD.org> AuthorDate: 2023-12-01 23:37:29 +0000 Commit: Gleb Smirnoff <glebius@FreeBSD.org> CommitDate: 2024-01-09 00:26:38 +0000 unix/dgram: bump maximum datagram size limit to 8k This is important for wpa_supplicant operation on a crowded network. Note: we actually need an API to increase maximum datagram size on a socket. Previously SO_SNDBUF magically acted like that, but that was an undocumented "feature". Also move the comment to the proper line. Previously it was the receive buffer that imposed the limit. Now notion of buffer size and maximum datagram are separate. Reviewed by: bz, tuexen, karels Differential Revision: https://reviews.freebsd.org/D42830 PR: 274990 (cherry picked from commit be7c095ac99ad29fd72b780c7d58949a38656c66) sys/kern/uipc_usrreq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
^Triage: assign to one of the committers that resolved. Does this need either an EN for 14.0, or a MFC to 13?
Assign to Bjoern as he has the entire picture. I just committed one of the changes.
> Does this need either an EN for 14.0, or a MFC to 13? IMO we should try to MFC all of this to stable/13 in advance of 13.3. For 14 I imagine it will just arrive in 14.1.
(In reply to Ed Maste from comment #21) the unix/dgram changes should not be needed in 13. wpa needs to go all way. I am still sorting through things but it'll go with the other mfc-candidates in one go.
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=97186b5cf5aa1d97f1a4e8e1b811315a39fb163d commit 97186b5cf5aa1d97f1a4e8e1b811315a39fb163d Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2023-11-12 20:33:41 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2024-02-19 08:01:59 +0000 wpa: ctrl_iface set sendbuf size In order to avoid running into the default net.local.dgram.maxdgram of 2K currently when calling sendto(2) try to set the sndbuf size to the maximum ctrl message size. While on 14 and 15 this does not actually raise the limit anymore (and be7c095ac99ad29fd72b780c7d58949a38656c66 raised it for syslogd and this), FreeBSD 13 still requires this change and it will work as expected there. In addition we always ensure a large enough send buffer this way independent of kernel defaults. The problem occured, e.g., when the scan_list result had enough BSSIDs so the text output would exceed 2048 bytes. Sponsored by: The FreeBSD Foundation PR: 274990 Reviewed by: cy, adrian (with previous comment) Differential Revision: https://reviews.freebsd.org/D42558 (cherry picked from commit 1edc20b76953d9ef571b0bcf89b206b98ed13d9b) contrib/wpa/wpa_supplicant/ctrl_iface_unix.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
A commit in branch releng/13.3 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4a646242c37f59d18cadb0ef0bb92860846d2db8 commit 4a646242c37f59d18cadb0ef0bb92860846d2db8 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2023-11-12 20:33:41 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2024-02-19 16:06:34 +0000 wpa: ctrl_iface set sendbuf size In order to avoid running into the default net.local.dgram.maxdgram of 2K currently when calling sendto(2) try to set the sndbuf size to the maximum ctrl message size. While on 14 and 15 this does not actually raise the limit anymore (and be7c095ac99ad29fd72b780c7d58949a38656c66 raised it for syslogd and this), FreeBSD 13 still requires this change and it will work as expected there. In addition we always ensure a large enough send buffer this way independent of kernel defaults. The problem occured, e.g., when the scan_list result had enough BSSIDs so the text output would exceed 2048 bytes. Approved by: re (cperciva) Sponsored by: The FreeBSD Foundation PR: 274990 Reviewed by: cy, adrian (with previous comment) Differential Revision: https://reviews.freebsd.org/D42558 (cherry picked from commit 1edc20b76953d9ef571b0bcf89b206b98ed13d9b) (cherry picked from commit 97186b5cf5aa1d97f1a4e8e1b811315a39fb163d) contrib/wpa/wpa_supplicant/ctrl_iface_unix.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
Ed, I believe this problem is fixed one way at least now. I'll close given all MFCs are done. Please anyone re-open in case you run into this from 13.3-RC1 / 14 /15 onward.