Bug 273696
| Summary: | security/wpa_supplicant from ports in 14.0-CURRENT does not associate | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Matthias Apitz <guru> |
| Component: | Individual Port(s) | Assignee: | Cy Schubert <cy> |
| Status: | In Progress --- | ||
| Severity: | Affects Only Me | CC: | grahamperrin, guru |
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(cy) |
| Version: | Latest | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
|
Description
Matthias Apitz
2023-09-10 12:03:42 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. 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) src/ patches have been backported to wpa_supplicant and friends. Try it now. 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? You can update only the ports you use. If you use security/wpa_supplicant, then only update it. 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 ... 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? $ 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 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... 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. 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. 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) 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(-) |
