ports/net/hostapd, branch 2025Q3

hostapd/* wpa_supplicant/*: Support CCMP-256/GMCP-256

2025-04-08T21:08:33Z

Chase src/fa06d18b3b87 adding support for CCMP-256/GMCP-256.

net/hostapd* security/wpa-supplicant*: Fix 13 and 14 builds

2025-03-17T13:15:29Z

The updates imported from 15-CURRENT included features not implemented in FreeBSD 13 and 14. #ifdef them out. Fixes: 995f5b9b0e4d PR: 285371

net/nhostapd, security/wpa_supplicant: Sync drivers_bsd.c from src

2025-03-15T22:43:27Z

src/ commits to drviers_bsd.c in src have fixed a number of problems with wpa_supplicant/hostapd and FreeBSD. Bring those changes into the ports. PR: 285371 Tested by: Matthias Apitz MFH 2025Q1

net/hostapd: Sync driver_bsd.c with base system

2024-09-13T23:04:20Z

Replace driver_bsd.c with the one from src. It utilizes facilities and features already in FreeBSD.

net/hostapd: Update to 2.11

2024-07-21T13:06:30Z

net/hostapd: Fix 15-CURRENT 108de784513d build

2024-06-02T05:32:10Z

On FreeBSD systems without 108de784513d the old definition will be used while on 108de784513d and newer the duplicate case will be removed. Obtained from: src 676041c41ba5 Discussed with: imp

net/hostapd*: Work around lack of MLME support

2024-03-04T16:44:36Z

hostap MLME uses Linux data structures and definitions not available in FreeBSD. The ability for hostapd to select the frequency (channel) depends Linux MLME, though strictly it's not required. Work around the Linux MLME requirement to configure device frequency. The detailed description is: hostapd will only set the channel (frequency) when Linux MLME is configured. Enabling NEED_AP_MLME will result in numerous build errors due do Linux data structures and definitions not available under FreeBSD. The code to set the frequency from the selected channel is only within the NEED_AP_MLME code path because without MLME, hostapd_get_hw_features() is an inline that always returns -1 whereas with MLME hostapd_get_hw_features() will obtain hardware features from the kernel. Until such time we simply set the frequency as configured. PR: 276375 MFH: 2024Q1

net/hostapd: Sanitize MANPREFIX

2024-01-22T16:52:30Z

Approved by: portmgr (blanket)

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

2023-09-12T05:51:29Z

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: Fix uninitialized packet pointer on error

2023-09-12T05:51:16Z

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 MFH: 2023Q3