Bug 273696 - security/wpa_supplicant from ports in 14.0-CURRENT does not associate
Summary: security/wpa_supplicant from ports in 14.0-CURRENT does not associate
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Cy Schubert
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-09-10 12:03 UTC by Matthias Apitz
Modified: 2023-09-15 14:09 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (cy)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Apitz 2023-09-10 12:03:42 UTC
security/wpa_supplicant compiled from ports does not associate with my
AP, the one from base system works fine.

Below are the details

	matthias

pkg info wpa_supplicant

wpa_supplicant-2.10_6
Name           : wpa_supplicant
Version        : 2.10_6
Installed on   : Sat Sep  9 12:57:45 2023 CEST
Origin         : security/wpa_supplicant
Architecture   : FreeBSD:14:amd64
Prefix         : /usr/local
Categories     : security net
Licenses       : BSD3CLAUSE
Maintainer     : cy@FreeBSD.org
WWW            : https://w1.fi/wpa_supplicant/
Comment        : Supplicant (client) for WPA/802.1x protocols
Options        :
	AKA            : off
	AKA_PRIME      : off
	BSD            : on
	DBUS           : on
	DEBUG_FILE     : off
	DEBUG_SYSLOG   : on
	DELAYED_MIC    : off
	DOCS           : on
	EAPOL_TEST     : off
	EKE            : on
	FAST           : on
	GPSK           : on
	GTC            : on
	HS20           : on
	HT_OVERRIDES   : off
	IEEE80211AC    : off
	IEEE80211N     : off
	IEEE80211R     : on
	IEEE80211W     : on
	IEEE8021X_EAPOL: on
	IKEV2          : on
	INTERWORKING   : on
	LEAP           : on
	MATCH          : on
	MD5            : on
	MSCHAPV2       : on
	NDIS           : off
	NONE           : off
	NO_ROAMING     : off
	OTP            : on
	P2P            : off
	PAX            : on
	PEAP           : on
	PKCS12         : on
	PRIVSEP        : off
	PSK            : on
	PWD            : on
	SAKE           : on
	SIM            : off
	SIM_SIMULATOR  : off
	SMARTCARD      : on
	TDLS           : off
	TEST           : off
	TLS            : on
	TLSV12         : off
	TNC            : on
	TTLS           : on
	USIM_SIMULATOR : off
	VHT_OVERRIDES  : off
	WEP            : on
	WIRED          : on
	WPS            : on
	WPS_ER         : on
	WPS_NFC        : on
	WPS_NOREG      : off
	WPS_UPNP       : on
Shared Libs required:
	libreadline.so.8
	libdbus-1.so.3
Annotations    :
	FreeBSD_version: 1400094
	build_timestamp: 2023-08-10T18:26:06+0000
	built_by       : poudriere-git-3.3.99.20220831
	cpe            : cpe:2.3:a:wpa_supplicant:wpa_supplicant:2.10:::::freebsd14:x64:6
	port_checkout_unclean: no
	port_git_hash  : c84214246
	ports_top_checkout_unclean: no
	ports_top_git_hash: 5914253c5
	repo_type      : binary
	repository     : FreeBSD
Flat size      : 1.69MiB
Description    :
wpa_supplicant is a client (supplicant) with support for WPA and WPA2
(IEEE 802.11i / RSN). It is suitable for both desktop/laptop computers and
embedded systems. Supplicant is the IEEE 802.1X/WPA component that is used
in the client stations. It implements key negotiation with a WPA
Authenticator and it controls the roaming and IEEE 802.11 authentication/
association of the wlan driver.

wpa_supplicant is designed to be a "daemon" program that runs in the
background and acts as the backend component controlling the wireless
connection. wpa_supplicant supports separate frontend programs and a
text-based frontend (wpa_cli) and a GUI (wpa_gui) are included with
wpa_supplicant.

WWW: https://w1.fi/wpa_supplicant/

grep wpa /var/log/messages:

wpa_supplicant from ports:

Sep  9 13:09:14 c720-1400094 wpa_supplicant[1879]: Successfully initialized wpa_supplicant
Sep  9 13:09:14 c720-1400094 wpa_supplicant[1879]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Invalid argument
Sep  9 13:09:14 c720-1400094 wpa_supplicant[1880]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
Sep  9 13:09:25 c720-1400094 wpa_supplicant[1880]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
Sep  9 13:10:02 c720-1400094 wpa_supplicant[1880]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all
Sep  9 13:10:02 c720-1400094 wpa_supplicant[1880]: wlan0: CTRL-EVENT-TERMINATING 

wpa_supplicant from base system

FreeBSD c720-1400094 14.0-CURRENT FreeBSD 14.0-CURRENT amd64 1400094 #2 main-n264568-1d7ffb373c9d-dirty: Wed Sep  6 07:13:22 CEST 2023     guru@jet:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

Sep  9 13:14:16 c720-1400094 wpa_supplicant[3517]: Successfully initialized wpa_supplicant
Sep  9 13:14:16 c720-1400094 wpa_supplicant[3517]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Invalid argument
Sep  9 13:14:24 c720-1400094 wpa_supplicant[3518]: wlan0: Trying to associate with 7c:ff:4d:c8:78:e2 (SSID='XXXXXXXXXXXXXXXXX' freq=2432 MHz)
Sep  9 13:14:24 c720-1400094 wpa_supplicant[3518]: wlan0: Associated with 7c:ff:4d:c8:78:e2
Sep  9 13:14:24 c720-1400094 wpa_supplicant[3518]: wlan0: WPA: Key negotiation completed with 7c:ff:4d:c8:78:e2 [PTK=CCMP GTK=CCMP]
Sep  9 13:14:24 c720-1400094 wpa_supplicant[3518]: wlan0: CTRL-EVENT-CONNECTED - Connection to 7c:ff:4d:c8:78:e2 completed [id=17 id_str=]
Sep  9 13:17:28 c720-1400094 wpa_supplicant[3518]: wlan0: WPA: Group rekeying completed with 7c:ff:4d:c8:78:e2 [GTK=CCMP]
Comment 1 Cy Schubert freebsd_committer freebsd_triage 2023-09-11 03:03:14 UTC
wpa in ports will need some patches from base backported to it. I'll try to get this done by the end of this or next week.
Comment 2 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:53:51 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=92b2d8e1bf08f4b81a5b3b92b30149dfd0807538

commit 92b2d8e1bf08f4b81a5b3b92b30149dfd0807538
Author:     R. Christian McDonald <rcm@rcm.sh>
AuthorDate: 2023-09-12 05:26:24 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:51:32 +0000

    net/hostapd-devel: wpa: Enable receiving priority tagged (VID 0) frames

    Certain internet service providers transmit vlan 0 priority tagged
    EAPOL frames from the ONT towards the residential gateway. VID 0
    should be ignored, and the frame processed according to the priority
    set in the 802.1P bits and the encapsulated EtherType (i.e. EAPOL).

    The pcap filter utilized by l2_packet is inadquate for this use case.

    Here we modify the pcap filter to accept both unencapsulated and
    encapsulated (with VLAN 0) EAPOL EtherTypes. This preserves the
    original filter behavior while also matching on encapsulated EAPOL.

    Sponsored by:   Rubicon Communications, LLC ("Netgate")
    Reviewed by:    cy
    Obtained from:  src bb5d6d14d81b
    PR:             273696
    MFH:            2023Q3

 net/hostapd-devel/Makefile                         |  2 +-
 .../patch-src_l2__packet_l2__packet__freebsd.c     | 30 ++++++++++++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)
Comment 3 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:53:53 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=3a88706af1e87ff0bd2857398137194da462c85c

commit 3a88706af1e87ff0bd2857398137194da462c85c
Author:     R. Christian McDonald <rcm@rcm.sh>
AuthorDate: 2023-09-12 05:24:29 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:51:23 +0000

    security/wpa_supplicant: wpa: Enable receiving priority tagged (VID 0) frames

    Certain internet service providers transmit vlan 0 priority tagged
    EAPOL frames from the ONT towards the residential gateway. VID 0
    should be ignored, and the frame processed according to the priority
    set in the 802.1P bits and the encapsulated EtherType (i.e. EAPOL).

    The pcap filter utilized by l2_packet is inadquate for this use case.

    Here we modify the pcap filter to accept both unencapsulated and
    encapsulated (with VLAN 0) EAPOL EtherTypes. This preserves the
    original filter behavior while also matching on encapsulated EAPOL.

    Sponsored by:   Rubicon Communications, LLC ("Netgate")
    Reviewed by:    cy
    Obtained from:  src bb5d6d14d81b
    PR:             273696
    MFH:            2023Q3

 security/wpa_supplicant/Makefile                   |  2 +-
 .../patch-src_l2__packet_l2__packet__freebsd.c     | 30 ++++++++++++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)
Comment 4 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:53:54 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=218c7064c3d83484a007ee54cc6556d58c657b4b

commit 218c7064c3d83484a007ee54cc6556d58c657b4b
Author:     R. Christian McDonald <rcm@rcm.sh>
AuthorDate: 2023-09-12 05:25:52 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:51:26 +0000

    security/wpa_supplicant-devel: wpa: Enable receiving priority tagged (VID 0) frames

    Certain internet service providers transmit vlan 0 priority tagged
    EAPOL frames from the ONT towards the residential gateway. VID 0
    should be ignored, and the frame processed according to the priority
    set in the 802.1P bits and the encapsulated EtherType (i.e. EAPOL).

    The pcap filter utilized by l2_packet is inadquate for this use case.

    Here we modify the pcap filter to accept both unencapsulated and
    encapsulated (with VLAN 0) EAPOL EtherTypes. This preserves the
    original filter behavior while also matching on encapsulated EAPOL.

    Sponsored by:   Rubicon Communications, LLC ("Netgate")
    Reviewed by:    cy
    Obtained from:  src bb5d6d14d81b
    PR:             273696
    MFH:            2023Q3

 security/wpa_supplicant-devel/Makefile             |  2 +-
 .../patch-src_l2__packet_l2__packet__freebsd.c     | 30 ++++++++++++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)
Comment 5 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:53:57 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=e7f23d81ae4b522701ab73482a3bb3e3a76f6e67

commit e7f23d81ae4b522701ab73482a3bb3e3a76f6e67
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-12 05:17:18 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:51:16 +0000

    net/hostapd: Fix uninitialized packet pointer on error

    The packet pointer (called packet) will remain uninitialized when
    pcap_next_ex() returns an error. This occurs when the wlan
    interface is shut down using ifconfig destroy. Adding a NULL
    assignment to packet duplicates what pcap_next() does.

    The reason we use pcap_next_ex() in this instance is because with
    pacp_next() when we receive a null pointer if there was an error
    or if no packets were read. With pcap_next_ex() we can differentiate
    between an error and legitimately no packets were received.

    PR:             270649, 273696
    Obtained from:  src 953efa5b200f
    Reported by:    Robert Morris <rtm@lcs.mit.edu>
    MFH:            2023Q3

 net/hostapd/Makefile                                         | 2 +-
 net/hostapd/files/patch-src_l2__packet_l2__packet__freebsd.c | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)
Comment 6 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:53:58 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=2150c312db2fe116e2ce5024645163948334d1e7

commit 2150c312db2fe116e2ce5024645163948334d1e7
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-12 05:17:36 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:51:19 +0000

    net/hostapd-devel: Fix uninitialized packet pointer on error

    The packet pointer (called packet) will remain uninitialized when
    pcap_next_ex() returns an error. This occurs when the wlan
    interface is shut down using ifconfig destroy. Adding a NULL
    assignment to packet duplicates what pcap_next() does.

    The reason we use pcap_next_ex() in this instance is because with
    pacp_next() when we receive a null pointer if there was an error
    or if no packets were read. With pcap_next_ex() we can differentiate
    between an error and legitimately no packets were received.

    PR:             270649, 273696
    Obtained from:  src 953efa5b200f
    Reported by:    Robert Morris <rtm@lcs.mit.edu>
    MFH:            2023Q3

 net/hostapd-devel/Makefile                                         | 2 +-
 net/hostapd-devel/files/patch-src_l2__packet_l2__packet__freebsd.c | 7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)
Comment 7 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:53:59 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=a872b8a14f51721830232b127cc6ac27663a903d

commit a872b8a14f51721830232b127cc6ac27663a903d
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-12 05:17:05 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:51:13 +0000

    security/wpa_supplicant-devel: Fix uninitialized packet pointer on error

    The packet pointer (called packet) will remain uninitialized when
    pcap_next_ex() returns an error. This occurs when the wlan
    interface is shut down using ifconfig destroy. Adding a NULL
    assignment to packet duplicates what pcap_next() does.

    The reason we use pcap_next_ex() in this instance is because with
    pacp_next() when we receive a null pointer if there was an error
    or if no packets were read. With pcap_next_ex() we can differentiate
    between an error and legitimately no packets were received.

    PR:             270649, 273696
    Obtained from:  src 953efa5b200f
    Reported by:    Robert Morris <rtm@lcs.mit.edu>
    MFH:            2023Q3

 security/wpa_supplicant-devel/Makefile             |  2 +-
 .../patch-src_l2__packet_l2__packet__freebsd.c     | 28 +++++++++++++++++++---
 2 files changed, 26 insertions(+), 4 deletions(-)
Comment 8 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:54:02 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=087cebebd616c77d469a9e337fa0c99041b3ccfb

commit 087cebebd616c77d469a9e337fa0c99041b3ccfb
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-11 06:20:47 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:50:53 +0000

    net/hostapd: driver_bsd.c: backout upstream IFF_ change and add logging

    This reverts the state to our old supplicant logic setting or clearing
    IFF_UP if needed.  In addition this adds logging for the cases in which
    we do (not) change the interface state.

    Depending on testing this seems to help bringing WiFi up or not log
    any needed changes (which would be the expected wpa_supplicant logic
    now).  People should look out for ``(changed)`` log entries (at least
    if debugging the issue; this way we will at least have data points).

    There is a hypothesis still pondered that the entire IFF_UP toggling
    only exploits a race in net80211 (see further discssussions for more
    debugging and alternative solutions see D38508 and D38753).
    That may also explain why the changes to the rc startup script [1]
    only helped partially for some people to no longer see the
    continuous CTRL-EVENT-SCAN-FAILED.

    It is highly likely that we will want further changes and until
    we know for sure that people are seeing ''(changed)'' events
    this should stay local.  Should we need to upstream this we'll
    likely need #ifdef __FreeBSD__ around this code.

    PR:             273696
    Obtained from:  src bfb202c4554a
    MFH:            2023Q3

 net/hostapd/Makefile                              |   2 +-
 net/hostapd/files/patch-src_drivers_driver__bsd.c | 130 ++++++++++++++++++++--
 2 files changed, 122 insertions(+), 10 deletions(-)
Comment 9 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:54:03 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=8668ee87415b8f14a4845b04358ac082aa34ea57

commit 8668ee87415b8f14a4845b04358ac082aa34ea57
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-11 06:21:46 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:50:56 +0000

    net/hostapd-devel: driver_bsd.c: backout upstream IFF_ change and add logging

    This reverts the state to our old supplicant logic setting or clearing
    IFF_UP if needed.  In addition this adds logging for the cases in which
    we do (not) change the interface state.

    Depending on testing this seems to help bringing WiFi up or not log
    any needed changes (which would be the expected wpa_supplicant logic
    now).  People should look out for ``(changed)`` log entries (at least
    if debugging the issue; this way we will at least have data points).

    There is a hypothesis still pondered that the entire IFF_UP toggling
    only exploits a race in net80211 (see further discssussions for more
    debugging and alternative solutions see D38508 and D38753).
    That may also explain why the changes to the rc startup script [1]
    only helped partially for some people to no longer see the
    continuous CTRL-EVENT-SCAN-FAILED.

    It is highly likely that we will want further changes and until
    we know for sure that people are seeing ''(changed)'' events
    this should stay local.  Should we need to upstream this we'll
    likely need #ifdef __FreeBSD__ around this code.

    PR:             273696
    Obtained from:  src bfb202c4554a
    MFH:            2023Q3

 net/hostapd-devel/Makefile                         |   1 +
 .../files/patch-src_drivers_driver__bsd.c          | 132 +++++++++++++++++++--
 2 files changed, 123 insertions(+), 10 deletions(-)
Comment 10 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:54:04 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=5da13f40eeaa4b39b3a9fd41e58d082e954acce6

commit 5da13f40eeaa4b39b3a9fd41e58d082e954acce6
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-12 05:08:11 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:51:07 +0000

    security/wpa_supplicant-devel: Reapply c586ac04eb66

    Reapply "Fix 100% CPU when USB wlan NIC removed."

    hostapd calls pcap_next(3) to read the next packet off the wlan interface.
    pcap_next() returns a pointer to the packet header but does not indicate
    success or failure. Unfortunately this results in an infinite loop (100%
    CPU) when the wlan device disappears, i.e. when a USB wlan device is
    manually removed or a USB error results in the device removal. However
    pcap_next_ex(3) does return success or failure. To resolve this we use
    pcap_next_ex(), forcing hostapd to exit when the error is encountered.

    An error message is printed to syslog or stderr when debugging (-d flag)
    is enabled. Unfortunately wpa_printf() only works when debugging is enabled.

    PR:             253608, 273696
    Obtained from:  src 6e5d01124fd4
    Reported by:    Damjan Jovanovic <damjan.jov@gmail.com>,
                    bz (privately)
    MFH:            2023Q3

 security/wpa_supplicant-devel/Makefile                   |  2 +-
 .../files/patch-src_l2__packet_l2__packet__freebsd.c     | 16 ++++++++++++++--
 2 files changed, 15 insertions(+), 3 deletions(-)
Comment 11 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:54:05 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=89484a70b0d26f483df30e43945b22a0df1be941

commit 89484a70b0d26f483df30e43945b22a0df1be941
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-12 05:15:41 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:51:10 +0000

    security/wpa_supplicant: Fix uninitialized packet pointer on error

    The packet pointer (called packet) will remain uninitialized when
    pcap_next_ex() returns an error. This occurs when the wlan
    interface is shut down using ifconfig destroy. Adding a NULL
    assignment to packet duplicates what pcap_next() does.

    The reason we use pcap_next_ex() in this instance is because with
    pacp_next() when we receive a null pointer if there was an error
    or if no packets were read. With pcap_next_ex() we can differentiate
    between an error and legitimately no packets were received.

    PR:             270649, 273696
    Obtained from:  src 953efa5b200f
    Reported by:    Robert Morris <rtm@lcs.mit.edu>
    MFH:            2023Q3

 security/wpa_supplicant/Makefile                                     | 2 +-
 .../wpa_supplicant/files/patch-src_l2__packet_l2__packet__freebsd.c  | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)
Comment 12 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:54:06 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=bf01744fb255852b2aed16b80e50cb76c35f19d4

commit bf01744fb255852b2aed16b80e50cb76c35f19d4
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-11 06:15:16 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:50:43 +0000

    security/wpa_supplicant: driver_bsd.c: backout upstream IFF_ change and add logging

    This reverts the state to our old supplicant logic setting or clearing
    IFF_UP if needed.  In addition this adds logging for the cases in which
    we do (not) change the interface state.

    Depending on testing this seems to help bringing WiFi up or not log
    any needed changes (which would be the expected wpa_supplicant logic
    now).  People should look out for ``(changed)`` log entries (at least
    if debugging the issue; this way we will at least have data points).

    There is a hypothesis still pondered that the entire IFF_UP toggling
    only exploits a race in net80211 (see further discssussions for more
    debugging and alternative solutions see D38508 and D38753).
    That may also explain why the changes to the rc startup script [1]
    only helped partially for some people to no longer see the
    continuous CTRL-EVENT-SCAN-FAILED.

    It is highly likely that we will want further changes and until
    we know for sure that people are seeing ''(changed)'' events
    this should stay local.  Should we need to upstream this we'll
    likely need #ifdef __FreeBSD__ around this code.

    Obtained from:  src bfb202c4554a
    PR:             273696
    MFH:            2023Q3

 security/wpa_supplicant/Makefile                   |   2 +-
 .../files/patch-src_drivers_driver__bsd.c          | 130 +++++++++++++++++++--
 2 files changed, 122 insertions(+), 10 deletions(-)
Comment 13 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:54:08 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=ba9d1c4fdcc2d0dd26af96e42aa11e5dbc0f9c7a

commit ba9d1c4fdcc2d0dd26af96e42aa11e5dbc0f9c7a
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-11 06:19:26 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:50:50 +0000

    security/wpa_supplicant-devel: driver_bsd.c: backout upstream IFF_ change and add logging

    This reverts the state to our old supplicant logic setting or clearing
    IFF_UP if needed.  In addition this adds logging for the cases in which
    we do (not) change the interface state.

    Depending on testing this seems to help bringing WiFi up or not log
    any needed changes (which would be the expected wpa_supplicant logic
    now).  People should look out for ``(changed)`` log entries (at least
    if debugging the issue; this way we will at least have data points).

    There is a hypothesis still pondered that the entire IFF_UP toggling
    only exploits a race in net80211 (see further discssussions for more
    debugging and alternative solutions see D38508 and D38753).
    That may also explain why the changes to the rc startup script [1]
    only helped partially for some people to no longer see the
    continuous CTRL-EVENT-SCAN-FAILED.

    It is highly likely that we will want further changes and until
    we know for sure that people are seeing ''(changed)'' events
    this should stay local.  Should we need to upstream this we'll
    likely need #ifdef __FreeBSD__ around this code.

    PR:             273696
    Obtained from:  src bfb202c4554a
    MFH:            2023Q3

 security/wpa_supplicant-devel/Makefile             |   1 +
 .../files/patch-src_drivers_driver__bsd.c          | 132 +++++++++++++++++++--
 2 files changed, 123 insertions(+), 10 deletions(-)
Comment 14 commit-hook freebsd_committer freebsd_triage 2023-09-12 05:54:09 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=33410dc2fce35423090de7566b10b2ce4ba5795c

commit 33410dc2fce35423090de7566b10b2ce4ba5795c
Author:     R. Christian McDonald <rcm@rcm.sh>
AuthorDate: 2023-09-12 05:26:08 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-12 05:51:29 +0000

    net/hostapd: wpa: Enable receiving priority tagged (VID 0) frames

    Certain internet service providers transmit vlan 0 priority tagged
    EAPOL frames from the ONT towards the residential gateway. VID 0
    should be ignored, and the frame processed according to the priority
    set in the 802.1P bits and the encapsulated EtherType (i.e. EAPOL).

    The pcap filter utilized by l2_packet is inadquate for this use case.

    Here we modify the pcap filter to accept both unencapsulated and
    encapsulated (with VLAN 0) EAPOL EtherTypes. This preserves the
    original filter behavior while also matching on encapsulated EAPOL.

    Sponsored by:   Rubicon Communications, LLC ("Netgate")
    Reviewed by:    cy
    Obtained from:  src bb5d6d14d81b
    PR:             273696
    MFH:            2023Q3

 net/hostapd/Makefile                               |  2 +-
 .../patch-src_l2__packet_l2__packet__freebsd.c     | 30 ++++++++++++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)
Comment 15 Cy Schubert freebsd_committer freebsd_triage 2023-09-12 06:40:24 UTC
src/ patches have been backported to wpa_supplicant and friends. Try it now.
Comment 16 Matthias Apitz 2023-09-12 07:44:53 UTC
I see commit for the following ports:
security/wpa_supplicant
security/wpa_supplicant-devel
net/hostapd
net/hostapd-devel
is it enough to update these in the ports tree?
Comment 17 Cy Schubert freebsd_committer freebsd_triage 2023-09-12 14:16:16 UTC
You can update only the ports you use. If you use security/wpa_supplicant, then only update it.
Comment 18 Matthias Apitz 2023-09-12 21:09:36 UTC
No change after updating the port, building and installing the new package.

guru@c720-1400094:~ $ ls -l /PKGDIR.20230806/wpa_supplicant-2.10_6.pkg 
-rw-r--r--  1 guru wheel 621215 Sep 12 19:25 /PKGDIR.20230806/wpa_supplicant-2.10_6.pkg


guru@c720-1400094:~ $ pkg info wpa_supplicant | more
wpa_supplicant-2.10_6
Name           : wpa_supplicant
Version        : 2.10_6
Installed on   : Tue Sep 12 22:53:01 2023 CEST
Origin         : security/wpa_supplicant
Architecture   : FreeBSD:14:amd64
...
Comment 19 Cy Schubert freebsd_committer freebsd_triage 2023-09-12 21:22:33 UTC
bf01744fb255852b2aed16b80e50cb76c35f19d4 is the commit that resolves this problem. wpa_supplicant (which has the fix) and ports wpa_supplicant (fixed by bf01744fb255852b2aed16b80e50cb76c35f19d4) should work the same. This suggests that the commit didn't make it into your ports tree.

Can you list a copy of your /usr/ports/security/wpa_supplicant/files/patch-src_drivers_driver__bsd.c, here, please?
Comment 20 Matthias Apitz 2023-09-12 21:41:49 UTC
$ ls -l /usr/ports/security/wpa_supplicant/files/patch-src_drivers_driver__bsd.c
-rw-r--r--  1 root wheel 7672 Sep 12 19:11 /usr/ports/security/wpa_supplicant/files/patch-src_drivers_driver__bsd.c

$ md5 /usr/ports/security/wpa_supplicant/files/patch-src_drivers_driver__bsd.c
MD5 (/usr/ports/security/wpa_supplicant/files/patch-src_drivers_driver__bsd.c) = 0de1cacaff812e520a3edc73a13d27fb
Comment 21 Matthias Apitz 2023-09-12 21:57:04 UTC
perhaps the problem has todo with my poudriere setup:

# ls -l /usr/local/poudriere/ports/ports20230806/security/wpa_supplicant/files/patch-src_drivers_driver__bsd.c /usr/ports/security/wpa_supplicant/files/patch-src_drivers_driver__bsd.c
-rw-r--r--  1 root wheel 5119 Aug  6 19:51 /usr/local/poudriere/ports/ports20230806/security/wpa_supplicant/files/patch-src_drivers_driver__bsd.c
-rw-r--r--  1 root wheel 7672 Sep 12 19:11 /usr/ports/security/wpa_supplicant/files/patch-src_drivers_driver__bsd.c

i.e. poudriere is not using the ports tree I updated with git; at the moment I do not understand why...
Comment 22 Cy Schubert freebsd_committer freebsd_triage 2023-09-12 22:27:56 UTC
Could be. 

Your md5sum matches mine.

There was a patch to the wpa_supplicant rc script that did in ifconfig down and up.

Suggest you simply build the port by hand:

make check-orphans deinstall install clean

For one-off ports, building ports by hand is ok when doing stuff like this.
Comment 23 Matthias Apitz 2023-09-13 05:13:46 UTC
I can confirm that the patches solved the problem.

It was my fault. I yesterday updated the ports tree below /usr/ports while the poudriere was using /usr/local/poudriere/ports/ports20230806 (as defined when creating the port within poudriere). I was faulty thinking that both are physically the same place and /usr/local/poudriere/ports/ports20230806 only a mount point of /usr/ports.

Sorry for this.
Comment 24 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:22 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=e242127d30cdcef77f50503bd266996c1ed8a50b

commit e242127d30cdcef77f50503bd266996c1ed8a50b
Author:     R. Christian McDonald <rcm@rcm.sh>
AuthorDate: 2023-09-12 05:26:24 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:46 +0000

    net/hostapd-devel: wpa: Enable receiving priority tagged (VID 0) frames

    Certain internet service providers transmit vlan 0 priority tagged
    EAPOL frames from the ONT towards the residential gateway. VID 0
    should be ignored, and the frame processed according to the priority
    set in the 802.1P bits and the encapsulated EtherType (i.e. EAPOL).

    The pcap filter utilized by l2_packet is inadquate for this use case.

    Here we modify the pcap filter to accept both unencapsulated and
    encapsulated (with VLAN 0) EAPOL EtherTypes. This preserves the
    original filter behavior while also matching on encapsulated EAPOL.

    Sponsored by:   Rubicon Communications, LLC ("Netgate")
    Reviewed by:    cy
    Obtained from:  src bb5d6d14d81b
    PR:             273696

    (cherry picked from commit 92b2d8e1bf08f4b81a5b3b92b30149dfd0807538)

 net/hostapd-devel/Makefile                         |  2 +-
 .../patch-src_l2__packet_l2__packet__freebsd.c     | 30 ++++++++++++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)
Comment 25 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:24 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=a313183071ac551368e87214ebf5ef6e5fa589d0

commit a313183071ac551368e87214ebf5ef6e5fa589d0
Author:     R. Christian McDonald <rcm@rcm.sh>
AuthorDate: 2023-09-12 05:26:08 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:45 +0000

    net/hostapd: wpa: Enable receiving priority tagged (VID 0) frames

    Certain internet service providers transmit vlan 0 priority tagged
    EAPOL frames from the ONT towards the residential gateway. VID 0
    should be ignored, and the frame processed according to the priority
    set in the 802.1P bits and the encapsulated EtherType (i.e. EAPOL).

    The pcap filter utilized by l2_packet is inadquate for this use case.

    Here we modify the pcap filter to accept both unencapsulated and
    encapsulated (with VLAN 0) EAPOL EtherTypes. This preserves the
    original filter behavior while also matching on encapsulated EAPOL.

    Sponsored by:   Rubicon Communications, LLC ("Netgate")
    Reviewed by:    cy
    Obtained from:  src bb5d6d14d81b
    PR:             273696

    (cherry picked from commit 33410dc2fce35423090de7566b10b2ce4ba5795c)

 net/hostapd/Makefile                               |  2 +-
 .../patch-src_l2__packet_l2__packet__freebsd.c     | 30 ++++++++++++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)
Comment 26 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:25 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=795667c94c9e8d44a37b32b203138c4f328f0caa

commit 795667c94c9e8d44a37b32b203138c4f328f0caa
Author:     R. Christian McDonald <rcm@rcm.sh>
AuthorDate: 2023-09-12 05:25:52 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:45 +0000

    security/wpa_supplicant-devel: wpa: Enable receiving priority tagged (VID 0) frames

    Certain internet service providers transmit vlan 0 priority tagged
    EAPOL frames from the ONT towards the residential gateway. VID 0
    should be ignored, and the frame processed according to the priority
    set in the 802.1P bits and the encapsulated EtherType (i.e. EAPOL).

    The pcap filter utilized by l2_packet is inadquate for this use case.

    Here we modify the pcap filter to accept both unencapsulated and
    encapsulated (with VLAN 0) EAPOL EtherTypes. This preserves the
    original filter behavior while also matching on encapsulated EAPOL.

    Sponsored by:   Rubicon Communications, LLC ("Netgate")
    Reviewed by:    cy
    Obtained from:  src bb5d6d14d81b
    PR:             273696

    (cherry picked from commit 218c7064c3d83484a007ee54cc6556d58c657b4b)

 security/wpa_supplicant-devel/Makefile             |  2 +-
 .../patch-src_l2__packet_l2__packet__freebsd.c     | 30 ++++++++++++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)
Comment 27 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:26 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=e09453d1ecfe3010b64a5f240df497dec741551c

commit e09453d1ecfe3010b64a5f240df497dec741551c
Author:     R. Christian McDonald <rcm@rcm.sh>
AuthorDate: 2023-09-12 05:24:29 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:45 +0000

    security/wpa_supplicant: wpa: Enable receiving priority tagged (VID 0) frames

    Certain internet service providers transmit vlan 0 priority tagged
    EAPOL frames from the ONT towards the residential gateway. VID 0
    should be ignored, and the frame processed according to the priority
    set in the 802.1P bits and the encapsulated EtherType (i.e. EAPOL).

    The pcap filter utilized by l2_packet is inadquate for this use case.

    Here we modify the pcap filter to accept both unencapsulated and
    encapsulated (with VLAN 0) EAPOL EtherTypes. This preserves the
    original filter behavior while also matching on encapsulated EAPOL.

    Sponsored by:   Rubicon Communications, LLC ("Netgate")
    Reviewed by:    cy
    Obtained from:  src bb5d6d14d81b
    PR:             273696

    (cherry picked from commit 3a88706af1e87ff0bd2857398137194da462c85c)

 security/wpa_supplicant/Makefile                   |  2 +-
 .../patch-src_l2__packet_l2__packet__freebsd.c     | 30 ++++++++++++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)
Comment 28 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:27 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=8ac8e6a2a8d6b2c88ede98f89c7f3b7f7a066c9a

commit 8ac8e6a2a8d6b2c88ede98f89c7f3b7f7a066c9a
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-12 05:17:36 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:44 +0000

    net/hostapd-devel: Fix uninitialized packet pointer on error

    The packet pointer (called packet) will remain uninitialized when
    pcap_next_ex() returns an error. This occurs when the wlan
    interface is shut down using ifconfig destroy. Adding a NULL
    assignment to packet duplicates what pcap_next() does.

    The reason we use pcap_next_ex() in this instance is because with
    pacp_next() when we receive a null pointer if there was an error
    or if no packets were read. With pcap_next_ex() we can differentiate
    between an error and legitimately no packets were received.

    PR:             270649, 273696
    Obtained from:  src 953efa5b200f
    Reported by:    Robert Morris <rtm@lcs.mit.edu>

    (cherry picked from commit 2150c312db2fe116e2ce5024645163948334d1e7)

 net/hostapd-devel/Makefile                                         | 2 +-
 net/hostapd-devel/files/patch-src_l2__packet_l2__packet__freebsd.c | 7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)
Comment 29 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:30 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=6f4c310eecc8e585f5df84ddd2b88cf76f51e543

commit 6f4c310eecc8e585f5df84ddd2b88cf76f51e543
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-12 05:17:18 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:44 +0000

    net/hostapd: Fix uninitialized packet pointer on error

    The packet pointer (called packet) will remain uninitialized when
    pcap_next_ex() returns an error. This occurs when the wlan
    interface is shut down using ifconfig destroy. Adding a NULL
    assignment to packet duplicates what pcap_next() does.

    The reason we use pcap_next_ex() in this instance is because with
    pacp_next() when we receive a null pointer if there was an error
    or if no packets were read. With pcap_next_ex() we can differentiate
    between an error and legitimately no packets were received.

    PR:             270649, 273696
    Obtained from:  src 953efa5b200f
    Reported by:    Robert Morris <rtm@lcs.mit.edu>

    (cherry picked from commit e7f23d81ae4b522701ab73482a3bb3e3a76f6e67)

 net/hostapd/Makefile                                         | 2 +-
 net/hostapd/files/patch-src_l2__packet_l2__packet__freebsd.c | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)
Comment 30 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:32 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=0b110f1e3e172f3ec29a1ff548ef30adfaa82277

commit 0b110f1e3e172f3ec29a1ff548ef30adfaa82277
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-12 05:17:05 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:43 +0000

    security/wpa_supplicant-devel: Fix uninitialized packet pointer on error

    The packet pointer (called packet) will remain uninitialized when
    pcap_next_ex() returns an error. This occurs when the wlan
    interface is shut down using ifconfig destroy. Adding a NULL
    assignment to packet duplicates what pcap_next() does.

    The reason we use pcap_next_ex() in this instance is because with
    pacp_next() when we receive a null pointer if there was an error
    or if no packets were read. With pcap_next_ex() we can differentiate
    between an error and legitimately no packets were received.

    PR:             270649, 273696
    Obtained from:  src 953efa5b200f
    Reported by:    Robert Morris <rtm@lcs.mit.edu>

    (cherry picked from commit a872b8a14f51721830232b127cc6ac27663a903d)

 security/wpa_supplicant-devel/Makefile             |  2 +-
 .../patch-src_l2__packet_l2__packet__freebsd.c     | 28 +++++++++++++++++++---
 2 files changed, 26 insertions(+), 4 deletions(-)
Comment 31 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:34 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=7233b4d8b95baff0f2f2915a8e93a5df2b6e5c4b

commit 7233b4d8b95baff0f2f2915a8e93a5df2b6e5c4b
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-12 05:08:11 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:43 +0000

    security/wpa_supplicant-devel: Reapply c586ac04eb66

    Reapply "Fix 100% CPU when USB wlan NIC removed."

    hostapd calls pcap_next(3) to read the next packet off the wlan interface.
    pcap_next() returns a pointer to the packet header but does not indicate
    success or failure. Unfortunately this results in an infinite loop (100%
    CPU) when the wlan device disappears, i.e. when a USB wlan device is
    manually removed or a USB error results in the device removal. However
    pcap_next_ex(3) does return success or failure. To resolve this we use
    pcap_next_ex(), forcing hostapd to exit when the error is encountered.

    An error message is printed to syslog or stderr when debugging (-d flag)
    is enabled. Unfortunately wpa_printf() only works when debugging is enabled.

    PR:             253608, 273696
    Obtained from:  src 6e5d01124fd4
    Reported by:    Damjan Jovanovic <damjan.jov@gmail.com>,
                    bz (privately)

    (cherry picked from commit 5da13f40eeaa4b39b3a9fd41e58d082e954acce6)

 security/wpa_supplicant-devel/Makefile                   |  2 +-
 .../files/patch-src_l2__packet_l2__packet__freebsd.c     | 16 ++++++++++++++--
 2 files changed, 15 insertions(+), 3 deletions(-)
Comment 32 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:37 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=45703ac1172cc56d8f2b3bebf57309c87b7ee85f

commit 45703ac1172cc56d8f2b3bebf57309c87b7ee85f
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-12 05:15:41 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:43 +0000

    security/wpa_supplicant: Fix uninitialized packet pointer on error

    The packet pointer (called packet) will remain uninitialized when
    pcap_next_ex() returns an error. This occurs when the wlan
    interface is shut down using ifconfig destroy. Adding a NULL
    assignment to packet duplicates what pcap_next() does.

    The reason we use pcap_next_ex() in this instance is because with
    pacp_next() when we receive a null pointer if there was an error
    or if no packets were read. With pcap_next_ex() we can differentiate
    between an error and legitimately no packets were received.

    PR:             270649, 273696
    Obtained from:  src 953efa5b200f
    Reported by:    Robert Morris <rtm@lcs.mit.edu>

    (cherry picked from commit 89484a70b0d26f483df30e43945b22a0df1be941)

 security/wpa_supplicant/Makefile                                     | 2 +-
 .../wpa_supplicant/files/patch-src_l2__packet_l2__packet__freebsd.c  | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)
Comment 33 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:38 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=5d8ede11d81e6ad044811bc455d1ea11de5e97bc

commit 5d8ede11d81e6ad044811bc455d1ea11de5e97bc
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-11 06:20:47 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:41 +0000

    net/hostapd: driver_bsd.c: backout upstream IFF_ change and add logging

    This reverts the state to our old supplicant logic setting or clearing
    IFF_UP if needed.  In addition this adds logging for the cases in which
    we do (not) change the interface state.

    Depending on testing this seems to help bringing WiFi up or not log
    any needed changes (which would be the expected wpa_supplicant logic
    now).  People should look out for ``(changed)`` log entries (at least
    if debugging the issue; this way we will at least have data points).

    There is a hypothesis still pondered that the entire IFF_UP toggling
    only exploits a race in net80211 (see further discssussions for more
    debugging and alternative solutions see D38508 and D38753).
    That may also explain why the changes to the rc startup script [1]
    only helped partially for some people to no longer see the
    continuous CTRL-EVENT-SCAN-FAILED.

    It is highly likely that we will want further changes and until
    we know for sure that people are seeing ''(changed)'' events
    this should stay local.  Should we need to upstream this we'll
    likely need #ifdef __FreeBSD__ around this code.

    PR:             273696
    Obtained from:  src bfb202c4554a

    (cherry picked from commit 087cebebd616c77d469a9e337fa0c99041b3ccfb)

 net/hostapd/Makefile                              |   2 +-
 net/hostapd/files/patch-src_drivers_driver__bsd.c | 130 ++++++++++++++++++++--
 2 files changed, 122 insertions(+), 10 deletions(-)
Comment 34 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:39 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=c5c914750fa6801c4315c55f3504e2592e44cf1c

commit c5c914750fa6801c4315c55f3504e2592e44cf1c
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-11 06:19:26 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:41 +0000

    security/wpa_supplicant-devel: driver_bsd.c: backout upstream IFF_ change and add logging

    This reverts the state to our old supplicant logic setting or clearing
    IFF_UP if needed.  In addition this adds logging for the cases in which
    we do (not) change the interface state.

    Depending on testing this seems to help bringing WiFi up or not log
    any needed changes (which would be the expected wpa_supplicant logic
    now).  People should look out for ``(changed)`` log entries (at least
    if debugging the issue; this way we will at least have data points).

    There is a hypothesis still pondered that the entire IFF_UP toggling
    only exploits a race in net80211 (see further discssussions for more
    debugging and alternative solutions see D38508 and D38753).
    That may also explain why the changes to the rc startup script [1]
    only helped partially for some people to no longer see the
    continuous CTRL-EVENT-SCAN-FAILED.

    It is highly likely that we will want further changes and until
    we know for sure that people are seeing ''(changed)'' events
    this should stay local.  Should we need to upstream this we'll
    likely need #ifdef __FreeBSD__ around this code.

    PR:             273696
    Obtained from:  src bfb202c4554a

    (cherry picked from commit ba9d1c4fdcc2d0dd26af96e42aa11e5dbc0f9c7a)

 security/wpa_supplicant-devel/Makefile             |   1 +
 .../files/patch-src_drivers_driver__bsd.c          | 132 +++++++++++++++++++--
 2 files changed, 123 insertions(+), 10 deletions(-)
Comment 35 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:40 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=0a98996fe2764c941816de09316fabc3f03a86c0

commit 0a98996fe2764c941816de09316fabc3f03a86c0
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-11 06:15:16 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:40 +0000

    security/wpa_supplicant: driver_bsd.c: backout upstream IFF_ change and add logging

    This reverts the state to our old supplicant logic setting or clearing
    IFF_UP if needed.  In addition this adds logging for the cases in which
    we do (not) change the interface state.

    Depending on testing this seems to help bringing WiFi up or not log
    any needed changes (which would be the expected wpa_supplicant logic
    now).  People should look out for ``(changed)`` log entries (at least
    if debugging the issue; this way we will at least have data points).

    There is a hypothesis still pondered that the entire IFF_UP toggling
    only exploits a race in net80211 (see further discssussions for more
    debugging and alternative solutions see D38508 and D38753).
    That may also explain why the changes to the rc startup script [1]
    only helped partially for some people to no longer see the
    continuous CTRL-EVENT-SCAN-FAILED.

    It is highly likely that we will want further changes and until
    we know for sure that people are seeing ''(changed)'' events
    this should stay local.  Should we need to upstream this we'll
    likely need #ifdef __FreeBSD__ around this code.

    Obtained from:  src bfb202c4554a
    PR:             273696

    (cherry picked from commit bf01744fb255852b2aed16b80e50cb76c35f19d4)

 security/wpa_supplicant/Makefile                   |   2 +-
 .../files/patch-src_drivers_driver__bsd.c          | 130 +++++++++++++++++++--
 2 files changed, 122 insertions(+), 10 deletions(-)
Comment 36 commit-hook freebsd_committer freebsd_triage 2023-09-15 14:09:41 UTC
A commit in branch 2023Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=662d7b7df237ceb81dbc6628360cabf919d78321

commit 662d7b7df237ceb81dbc6628360cabf919d78321
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2023-09-11 06:21:46 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2023-09-15 14:07:42 +0000

    net/hostapd-devel: driver_bsd.c: backout upstream IFF_ change and add logging

    This reverts the state to our old supplicant logic setting or clearing
    IFF_UP if needed.  In addition this adds logging for the cases in which
    we do (not) change the interface state.

    Depending on testing this seems to help bringing WiFi up or not log
    any needed changes (which would be the expected wpa_supplicant logic
    now).  People should look out for ``(changed)`` log entries (at least
    if debugging the issue; this way we will at least have data points).

    There is a hypothesis still pondered that the entire IFF_UP toggling
    only exploits a race in net80211 (see further discssussions for more
    debugging and alternative solutions see D38508 and D38753).
    That may also explain why the changes to the rc startup script [1]
    only helped partially for some people to no longer see the
    continuous CTRL-EVENT-SCAN-FAILED.

    It is highly likely that we will want further changes and until
    we know for sure that people are seeing ''(changed)'' events
    this should stay local.  Should we need to upstream this we'll
    likely need #ifdef __FreeBSD__ around this code.

    PR:             273696
    Obtained from:  src bfb202c4554a

    (cherry picked from commit 8668ee87415b8f14a4845b04358ac082aa34ea57)

 net/hostapd-devel/Makefile                         |   1 +
 .../files/patch-src_drivers_driver__bsd.c          | 132 +++++++++++++++++++--
 2 files changed, 123 insertions(+), 10 deletions(-)