After upgrade to stable/13-n250369-2315d1fd10e wpa_supplicant from the base cannot be used in WPA2 secured network: Apr 13 21:45:11 bsdondell kernel: pid 4012 (wpa_supplicant), jid 0, uid 0: exited on signal 11 (core dumped) The tool from ports works fine. Previous build: stable/13-n250049-9f600a260a7 was running without issues.
Can you open the core in gdb or lldb and paste the backtrace here? e.g. $ lldb /usr/sbin/wpa_supplicant -c wpa_supplicant.core ... (lldb) bt
Yes, please provide a backtrace using lldb or gdb. Also please provide, - uname -a output - build options from make.conf & src.conf - options passed to wpa_supplicant
$ lldb /usr/sbin/wpa_supplicant -c wpa_supplicant.core (lldb) target create "/usr/sbin/wpa_supplicant" --core "wpa_supplicant.core" Core file '/home/agrajag9/4wifi/wpa_supplicant.core' (x86_64) was loaded. (lldb) bt This version of LLDB has no plugin for the language "assembler". Inspection of frame variables will be limited. * thread #1, name = 'wpa_supplicant', stop reason = signal SIGSEGV * frame #0: 0x00000008016ee8ef libc.so.7`memcpy at memmove.S:314 frame #1: 0x00000000011468e3 wpa_supplicant`wpabuf_alloc_copy [inlined] wpabuf_put_data(buf=0x0000000802a00dc0, data=0x0000000801e680e8, len=3595206685) at wpabuf.h:170:3 frame #2: 0x00000000011468bf wpa_supplicant`wpabuf_alloc_copy(data=0x0000000801e680e8, len=3595206685) at wpabuf.c:164:3 frame #3: 0x00000000010cbeff wpa_supplicant`wpa_supplicant_rx_eapol(ctx=0x0000000801e39000, src_addr="l\xae\xf6Ӎf\x88\x8e\U00000002\U00000003", buf=<unavailable>, len=3595206685) at wpa_supplicant.c:5037:29 frame #4: 0x00000000010ff5c8 wpa_supplicant`l2_packet_receive(sock=<unavailable>, eloop_ctx=0x0000000801e28be0, sock_ctx=<unavailable>) at l2_packet_freebsd.c:102:2 frame #5: 0x0000000001143bd3 wpa_supplicant`eloop_run [inlined] eloop_sock_table_dispatch(fds=0x0000000801e64780) at eloop.c:603:4 frame #6: 0x0000000001143b81 wpa_supplicant`eloop_run at eloop.c:1233:3 frame #7: 0x00000000010cf7cc wpa_supplicant`wpa_supplicant_run(global=<unavailable>) at wpa_supplicant.c:7470:2 frame #8: 0x00000000010b164a wpa_supplicant`main(argc=<unavailable>, argv=<unavailable>) at main.c:391:14 frame #9: 0x0000000001086bbd wpa_supplicant`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7 /usr/sbin/wpa_supplicant -s -B -i wlan99 -c /etc/wpa_supplicant.conf -D bsd -P / $ uname -a FreeBSD framework.a9development.com 13.1-STABLE FreeBSD 13.1-STABLE #0 stable/13-n250372-7ae00874e5c: Sun Apr 10 14:25:09 UTC 2022 toor@ptmc.a9development.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 $ cat /etc/make.conf DEFAULT_VERSIONS+= java=11 mysql=10.5m php=8.0 python=3.8 python3=3.8 llvm=13 No src.conf
what type of WPA AP are you attempting to associate with? WPA key management PSK or EAP? Using CCMP? TKIP? MSCHAPV2? Can you please list the wpa_supplicant.conf entry, without SSID, passwords, BSSID or any other identifying information?
network={ ssid="MyNetwork" psk=SECRET priority=1 } PSK with CCMP
This may be related to iwlwifi as well - I can still connect with a rtwn.
Interesting. (I use iwn(4), rtwn_usb(4) (RTL8188EU & RTL8192EU), and ath(4) here.) Type in: frame select 3 Type in: p buf Type: p len For giggles, type: p *buf Maybe it might be easier if you sent me a copy of the core file or put it somewhere.
(lldb) frame select 3 frame #3: 0x00000000011468d5 wpa_supplicant`wpabuf_alloc_copy [inlined] wpabuf_put_data(buf=0x0000000802a00dc0, data=0x0000000801e680e8, len=3595206685) at wpabuf.h:170:3 167 size_t len) 168 { 169 if (data) -> 170 os_memcpy(wpabuf_put(buf, len), data, len); 171 } 172 173 static inline void wpabuf_put_buf(struct wpabuf *dst, (lldb) p buf (wpabuf *) $0 = 0x0000000802a00dc0 (lldb) p len (size_t) $1 = 3595206685 (lldb) p *buf (wpabuf) $2 = (size = 3595206685, used = 3595206685, buf = "", flags = 0)
Created attachment 233206 [details] Pointer to a pointer instead. This should fix it. The second argument is a pointer to a pointer.
Another backtrace: [bsdondell] /tmp% lldb /usr/sbin/wpa_supplicant -c wpa_supplicant.4012.core (lldb) target create "/usr/sbin/wpa_supplicant" --core "wpa_supplicant.4012.core" Core file '/tmp/wpa_supplicant.4012.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'wpa_supplicant', stop reason = signal SIGSEGV * frame #0: 0x0000000001145990 wpa_supplicant`_wpa_hexdump(level=1, title=<unavailable>, buf="\U00000001\U00000003", len=3860075389, show=1, only_syslog=0) at wpa_debug.c:340:10 frame #1: 0x0000000001145900 wpa_supplicant`wpa_hexdump(level=<unavailable>, title=<unavailable>, buf=<unavailable>, len=<unavailable>) at wpa_debug.c:387:2 [artificial] frame #2: 0x00000000010cc4cc wpa_supplicant`wpa_supplicant_rx_eapol(ctx=0x0000000801e39000, src_addr="\xa0c\x91\xd1ݚ\x88\x8e\U00000001\U00000003", buf="\U00000001\U00000003", len=3860075389) at wpa_supplicant.c:4997:2 frame #3: 0x00000000010ffee8 wpa_supplicant`l2_packet_receive(sock=<unavailable>, eloop_ctx=0x0000000801e28be0, sock_ctx=<unavailable>) at l2_packet_freebsd.c:102:2 frame #4: 0x00000000011442f4 wpa_supplicant`eloop_run [inlined] eloop_sock_table_dispatch(fds=0x0000000801e6c180) at eloop.c:603:4 frame #5: 0x00000000011442a1 wpa_supplicant`eloop_run at eloop.c:1233:3 frame #6: 0x00000000010cff9c wpa_supplicant`wpa_supplicant_run(global=<unavailable>) at wpa_supplicant.c:7470:2 frame #7: 0x00000000010b1979 wpa_supplicant`main(argc=<unavailable>, argv=0x00007fffffffebb0) at main.c:391:14 frame #8: 0x0000000001086e4d wpa_supplicant`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7 (lldb)
(In reply to Cy Schubert from comment #9) Thanks for the patch. It seems to fix the issue for me.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=1e0ca65a3bb5798a80eccaae58d863f1f08b9ae8 commit 1e0ca65a3bb5798a80eccaae58d863f1f08b9ae8 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2022-04-14 01:45:49 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2022-04-14 13:16:45 +0000 wpa: Correctly call pcap_next_ex() The second argument to pcap_next_ex() is a pointer to a pointer. Not a pointer. This fixes a wpa_supplicent SIGSEGV. PR: 263266 Reported by: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> Fixes: 6e5d01124fd4dd57899ddd9260c76dbb43543aa7 MFC: immediately contrib/wpa/src/l2_packet/l2_packet_freebsd.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d7365cc80c6532973e529195bddf9dbf7f35c239 commit d7365cc80c6532973e529195bddf9dbf7f35c239 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2022-04-14 01:45:49 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2022-04-14 13:48:11 +0000 wpa: Correctly call pcap_next_ex() The second argument to pcap_next_ex() is a pointer to a pointer. Not a pointer. This fixes a wpa_supplicent SIGSEGV. PR: 263266 Reported by: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> Fixes: 6e5d01124fd4dd57899ddd9260c76dbb43543aa7 (cherry picked from commit 1e0ca65a3bb5798a80eccaae58d863f1f08b9ae8) contrib/wpa/src/l2_packet/l2_packet_freebsd.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=6def5bc64cb9b97b4978b5fa6fa8d9ba36deddd8 commit 6def5bc64cb9b97b4978b5fa6fa8d9ba36deddd8 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2022-04-14 01:45:49 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2022-04-14 13:48:39 +0000 wpa: Correctly call pcap_next_ex() The second argument to pcap_next_ex() is a pointer to a pointer. Not a pointer. This fixes a wpa_supplicent SIGSEGV. PR: 263266 Reported by: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> Fixes: 6e5d01124fd4dd57899ddd9260c76dbb43543aa7 (cherry picked from commit 1e0ca65a3bb5798a80eccaae58d863f1f08b9ae8) contrib/wpa/src/l2_packet/l2_packet_freebsd.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
Thanks for testing. The patch has been committed and MFCed.
Thank you for the expedited fix Cy; Ed, Dan - thanks for helping.