History log of /freebsd/sys/net80211/ieee80211_wds.c (Results 1 – 25 of 125)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# a233c716 02-Jun-2025 Adrian Chadd <adrian@FreeBSD.org>

net80211: remove if_private.h from code that doesn't require it

The previous clean-ups to remove some direct ifp manipulation have
removed the need for if_private.h in these source files.

Different

net80211: remove if_private.h from code that doesn't require it

The previous clean-ups to remove some direct ifp manipulation have
removed the need for if_private.h in these source files.

Differential Revision: https://reviews.freebsd.org/D50646
Reviewed by: bz

show more ...


# 1a3c03d8 31-May-2025 Adrian Chadd <adrian@FreeBSD.org>

net80211: migrate if_printf() -> net80211_vap_printf()

Migrate the if_printf() calls to net80211_vap_printf(), which hides
the underlying ifp and the network stack.

Note: there are still a LOT of d

net80211: migrate if_printf() -> net80211_vap_printf()

Migrate the if_printf() calls to net80211_vap_printf(), which hides
the underlying ifp and the network stack.

Note: there are still a LOT of direct printf() calls in the codebase.
This is just a mostly mechanical conversion of if_printf() calls.

Differential Revision: https://reviews.freebsd.org/D50643
Reviewed by: bz

show more ...


# 249f14c8 18-May-2025 Adrian Chadd <adrian@FreeBSD.org>

net80211: remove direct references to ifp->if_xname

* change ieee80211_get_vap_ifname() to use if_name()
* migrate the other references of ifp->if_xname to
ieee80211_get_vap_ifname()

Differential

net80211: remove direct references to ifp->if_xname

* change ieee80211_get_vap_ifname() to use if_name()
* migrate the other references of ifp->if_xname to
ieee80211_get_vap_ifname()

Differential Revision: https://reviews.freebsd.org/D50407
Reviewed by: bz

show more ...


# a278d11a 18-May-2025 Adrian Chadd <adrian@FreeBSD.org>

net80211: refactor out ifp->if_broadcastaddr into ieee80211_freebsd.c

* create ieee80211_vap_get_broadcast_address() to fetch the broadcast
MAC address for the given VAP
* refactor references to i

net80211: refactor out ifp->if_broadcastaddr into ieee80211_freebsd.c

* create ieee80211_vap_get_broadcast_address() to fetch the broadcast
MAC address for the given VAP
* refactor references to ifp->if_broadcastaddr ->
ieee80211_vap_get_broadcast_address()

Differential Revision: https://reviews.freebsd.org/D50406
Reviewed by: bz

show more ...


Revision tags: release/13.4.0-p5, release/13.5.0-p1, release/14.2.0-p3, release/13.5.0, release/14.2.0-p2, release/14.1.0-p8, release/13.4.0-p4, release/14.1.0-p7, release/14.2.0-p1, release/13.4.0-p3, release/14.2.0
# 37e54466 09-Nov-2024 Adrian Chadd <adrian@FreeBSD.org>

net80211: clean up / add more macros to check the frame types

* Add new macros to check the version+type and version+type+subtype of a frame.
* Use these for existing frame checks.
* Convert the fla

net80211: clean up / add more macros to check the frame types

* Add new macros to check the version+type and version+type+subtype of a frame.
* Use these for existing frame checks.
* Convert the flag checks in net80211 to use the macros, rather than direct
header poking.

Notably I'm callign out things like QOS any versus QOS data, the
kind of NULL frames, etc. Eg, in the TKIP code it's checking whether
a frame is ANY kind of QOS frame, not just QOS data.

These macros should hopefully make the header checks clearer and less
error prone. They're also useful in drivers that are doing their
own header parsing.

Locally:

* ath(4), AP, STA, AP+STA modes
* local ath10k/athp - AP, STA modes
* rtwn - STA mode

Differential Revision: https://reviews.freebsd.org/D36615

show more ...


Revision tags: release/13.4.0, release/14.1.0, release/13.3.0
# fdafd315 24-Nov-2023 Warner Losh <imp@FreeBSD.org>

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...


Revision tags: release/14.0.0
# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# 4d846d26 10-May-2023 Warner Losh <imp@FreeBSD.org>

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...


Revision tags: release/13.2.0
# 3d0d5b21 23-Jan-2023 Justin Hibbits <jhibbits@FreeBSD.org>

IfAPI: Explicitly include <net/if_private.h> in netstack

Summary:
In preparation of making if_t completely opaque outside of the netstack,
explicitly include the header. <net/if_var.h> will stop in

IfAPI: Explicitly include <net/if_private.h> in netstack

Summary:
In preparation of making if_t completely opaque outside of the netstack,
explicitly include the header. <net/if_var.h> will stop including the
header in the future.

Sponsored by: Juniper Networks, Inc.
Reviewed by: glebius, melifaro
Differential Revision: https://reviews.freebsd.org/D38200

show more ...


Revision tags: release/12.4.0
# c9b7e9df 01-Sep-2022 Bjoern A. Zeeb <bz@FreeBSD.org>

net80211 / drivers: rename to IEEE80211_FC0_SUBTYPE_QOS_DATA

Going through the Frame (Sub)types the "QOS Data" being called "QOS"
scheme leads to a naming conflict for QOS_CFPOLL and QOS_CFACKPOLL
(

net80211 / drivers: rename to IEEE80211_FC0_SUBTYPE_QOS_DATA

Going through the Frame (Sub)types the "QOS Data" being called "QOS"
scheme leads to a naming conflict for QOS_CFPOLL and QOS_CFACKPOLL
(if added). Rename QOS* to QOS_DATA* to avoid the conflict and
to also better match the standards name.

No functional changes intended.

Sponsored by: The FreeBSD Foundation
MFC after: 5 days
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D36409

show more ...


# bd29f817 17-Aug-2022 Bjoern A. Zeeb <bz@FreeBSD.org>

net80211: consistently use the IEEE80211_M_ memory related options

Replace a malloc() by IEEE80211_MALLOC().
For malloc flags even in the local ieee80211_freebsd.c there was a mix
of both versions M

net80211: consistently use the IEEE80211_M_ memory related options

Replace a malloc() by IEEE80211_MALLOC().
For malloc flags even in the local ieee80211_freebsd.c there was a mix
of both versions M_ and IEEE80211_M_.
Consistently use the IEEE80211_M_ malloc options everywhere.
If the field is changed for malloc, it'll also be changed for the
other accessor functions taking a "how" field to avoid any confusion.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D36249

show more ...


# 2889cbe2 12-Aug-2022 Adrian Chadd <adrian@FreeBSD.org>

net80211: add an IEEE80211_IS_PROTECTED() macro

Summary: This returns whether the given 802.11 frame has the protected bit set.

Test Plan:
* tested in AP/STA mode
* STA mode - local athp/ath10k dri

net80211: add an IEEE80211_IS_PROTECTED() macro

Summary: This returns whether the given 802.11 frame has the protected bit set.

Test Plan:
* tested in AP/STA mode
* STA mode - local athp/ath10k driver
* AP mode - in tree ath driver

Subscribers: imp, melifaro, glebius
Reviewed by: bz
Approved by: bz

Differential Revision: https://reviews.freebsd.org/D36183

show more ...


Revision tags: release/13.1.0
# 91b4225a 22-Mar-2022 Bjoern A. Zeeb <bz@FreeBSD.org>

net80211: introduce (*iv_update_bss)()

Introduce (*iv_update_bss)() with a default implementation to allow
drivers to overload/intercept the time when we swap iv_bss.

This helps firmware based driv

net80211: introduce (*iv_update_bss)()

Introduce (*iv_update_bss)() with a default implementation to allow
drivers to overload/intercept the time when we swap iv_bss.

This helps firmware based drivers to synchronize state with firmware.
Otherwise, for some state changes, we begin with one ni (and in
LinuxKPI lsta) and try to finish with another ni (and a new lsta
in different state) and may no longer have access to the previous state.
This also saves us from constantly checking for ni changes complicating
code.

No functional changes intended.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
X-MFC: move (*iv_update_bss) to spare area

show more ...


Revision tags: release/12.3.0
# ffc19cf5 07-Jun-2021 Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>

net80211: prevent plaintext injection by A-MSDU RFC1042/EAPOL frames

No longer accept plaintext A-MSDU frames that start with an RFC1042
header with EtherType EAPOL. This is done by only accepting

net80211: prevent plaintext injection by A-MSDU RFC1042/EAPOL frames

No longer accept plaintext A-MSDU frames that start with an RFC1042
header with EtherType EAPOL. This is done by only accepting EAPOL
packets that are included in non-aggregated 802.11 frames.

Note that before this patch, FreeBSD also only accepted EAPOL frames
that are sent in a non-aggregated 802.11 frame due to bugs in
processing EAPOL packets inside A-MSDUs. In other words,
compatibility with legitimate devices remains the same.

This relates to section 6.5 in the 2021 Usenix "FragAttacks" (Fragment
and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation)
paper.

Submitted by: Mathy Vanhoef (Mathy.Vanhoef kuleuven.be)
Security: CVE-2020-26144
PR: 256120
MFC after: 7 days
Differential Revision: https://reviews.freebsd.org/D30665

show more ...


# f024bdf1 07-Jun-2021 Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>

net80211: mitigation against A-MSDU design flaw

Mitigate A-MSDU injection attacks by detecting if the destination address
of a subframe equals an RFC1042 (i.e., LLC/SNAP) header, and if so
dropping

net80211: mitigation against A-MSDU design flaw

Mitigate A-MSDU injection attacks by detecting if the destination address
of a subframe equals an RFC1042 (i.e., LLC/SNAP) header, and if so
dropping the complete A-MSDU frame. This mitigates known attacks,
although new (unknown) aggregation-based attacks may remain possible.

This defense works because in A-MSDU aggregation injection attacks, a
normal encrypted Wi-Fi frame is turned into an A-MSDU frame. This means
the first 6 bytes of the first A-MSDU subframe correspond to an RFC1042
header. In other words, the destination MAC address of the first A-MSDU
subframe contains the start of an RFC1042 header during an aggregation
attack. We can detect this and thereby prevent this specific attack.

This relates to section 7.2 in the 2021 Usenix "FragAttacks" (Fragment
and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation)
paper.

Submitted by: Mathy Vanhoef (Mathy.Vanhoef kuleuven.be)
Security: CVE-2020-24588
PR: 256119
Differential Revision: https://reviews.freebsd.org/D30664

show more ...


# 11572d7d 07-Jun-2021 Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>

net80211: reject mixed plaintext/encrypted fragments

ieee80211_defrag() accepts fragmented 802.11 frames in a protected Wi-Fi
network even when some of the fragments are not encrypted.
Track whether

net80211: reject mixed plaintext/encrypted fragments

ieee80211_defrag() accepts fragmented 802.11 frames in a protected Wi-Fi
network even when some of the fragments are not encrypted.
Track whether the fragments are encrypted or not and only accept
successive ones if they match the state of the first fragment.

This relates to section 6.3 in the 2021 Usenix "FragAttacks" (Fragment
and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation)
paper.

Submitted by: Mathy Vanhoef (Mathy.Vanhoef kuleuven.be)
Security: CVE-2020-26147
PR: 256118
Differential Revision: https://reviews.freebsd.org/D30663

show more ...


Revision tags: release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0
# 0269ae4c 06-Jun-2019 Alan Somers <asomers@FreeBSD.org>

MFHead @348740

Sponsored by: The FreeBSD Foundation


# fb3bc596 25-May-2019 John Baldwin <jhb@FreeBSD.org>

Restructure mbuf send tags to provide stronger guarantees.

- Perform ifp mismatch checks (to determine if a send tag is allocated
for a different ifp than the one the packet is being output on), i

Restructure mbuf send tags to provide stronger guarantees.

- Perform ifp mismatch checks (to determine if a send tag is allocated
for a different ifp than the one the packet is being output on), in
ip_output() and ip6_output(). This avoids sending packets with send
tags to ifnet drivers that don't support send tags.

Since we are now checking for ifp mismatches before invoking
if_output, we can now try to allocate a new tag before invoking
if_output sending the original packet on the new tag if allocation
succeeds.

To avoid code duplication for the fragment and unfragmented cases,
add ip_output_send() and ip6_output_send() as wrappers around
if_output and nd6_output_ifp, respectively. All of the logic for
setting send tags and dealing with send tag-related errors is done
in these wrapper functions.

For pseudo interfaces that wrap other network interfaces (vlan and
lagg), wrapper send tags are now allocated so that ip*_output see
the wrapper ifp as the ifp in the send tag. The if_transmit
routines rewrite the send tags after performing an ifp mismatch
check. If an ifp mismatch is detected, the transmit routines fail
with EAGAIN.

- To provide clearer life cycle management of send tags, especially
in the presence of vlan and lagg wrapper tags, add a reference count
to send tags managed via m_snd_tag_ref() and m_snd_tag_rele().
Provide a helper function (m_snd_tag_init()) for use by drivers
supporting send tags. m_snd_tag_init() takes care of the if_ref
on the ifp meaning that code alloating send tags via if_snd_tag_alloc
no longer has to manage that manually. Similarly, m_snd_tag_rele
drops the refcount on the ifp after invoking if_snd_tag_free when
the last reference to a send tag is dropped.

This also closes use after free races if there are pending packets in
driver tx rings after the socket is closed (e.g. from tcpdrop).

In order for m_free to work reliably, add a new CSUM_SND_TAG flag in
csum_flags to indicate 'snd_tag' is set (rather than 'rcvif').
Drivers now also check this flag instead of checking snd_tag against
NULL. This avoids false positive matches when a forwarded packet
has a non-NULL rcvif that was treated as a send tag.

- cxgbe was relying on snd_tag_free being called when the inp was
detached so that it could kick the firmware to flush any pending
work on the flow. This is because the driver doesn't require ACK
messages from the firmware for every request, but instead does a
kind of manual interrupt coalescing by only setting a flag to
request a completion on a subset of requests. If all of the
in-flight requests don't have the flag when the tag is detached from
the inp, the flow might never return the credits. The current
snd_tag_free command issues a flush command to force the credits to
return. However, the credit return is what also frees the mbufs,
and since those mbufs now hold references on the tag, this meant
that snd_tag_free would never be called.

To fix, explicitly drop the mbuf's reference on the snd tag when the
mbuf is queued in the firmware work queue. This means that once the
inp's reference on the tag goes away and all in-flight mbufs have
been queued to the firmware, tag's refcount will drop to zero and
snd_tag_free will kick in and send the flush request. Note that we
need to avoid doing this in the middle of ethofld_tx(), so the
driver grabs a temporary reference on the tag around that loop to
defer the free to the end of the function in case it sends the last
mbuf to the queue after the inp has dropped its reference on the
tag.

- mlx5 preallocates send tags and was using the ifp pointer even when
the send tag wasn't in use. Explicitly use the ifp from other data
structures instead.

- Sprinkle some assertions in various places to assert that received
packets don't have a send tag, and that other places that overwrite
rcvif (e.g. 802.11 transmit) don't clobber a send tag pointer.

Reviewed by: gallatin, hselasky, rgrimes, ae
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D20117

show more ...


# c981cbbd 15-Feb-2019 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r343956 through r344177.


# f3f08e16 11-Feb-2019 Andriy Voskoboinyk <avos@FreeBSD.org>

net80211(4): hide casts for 'i_seq' field offset calculation inside
ieee80211_getqos() and reuse it in various places.

Checked with RTL8188EE, HOSTAP mode + RTL8188CUS, STA mode.

MFC after: 2 weeks


Revision tags: release/12.0.0, release/11.2.0
# fe267a55 27-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

sys: general adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
pro

sys: general adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

No functional change intended.

show more ...


Revision tags: release/10.4.0, release/11.1.0
# 27c24068 22-May-2017 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r318560 through r318657.


# 85c4e670 20-May-2017 Adrian Chadd <adrian@FreeBSD.org>

[net80211] prepare for A-MSDU/A-MPDU offload crypto / sequence number checking.

When doing AMSDU offload, the driver (for now!) presents 802.11 frames with
the same sequence number and crypto sequen

[net80211] prepare for A-MSDU/A-MPDU offload crypto / sequence number checking.

When doing AMSDU offload, the driver (for now!) presents 802.11 frames with
the same sequence number and crypto sequence number / IV values up to the stack.
But, this will trip afoul over the sequence number detection.

So drivers now have a way to signify that a frame is part of an offloaded
AMSDU group, so we can just ensure that we pass those frames up to the
stack.

The logic will be a bit messy - the TL;DR will be that if it's part of
the previously seen sequence number then it belongs in the same burst.
But if we get a repeat of the same sequence number (eg we sent an ACK
but the receiver didn't hear it) then we shouldn't be passing those frames
up. So, we can't just say "all subframes go up", we need to track
whether we've seen the end of a burst of frames for the given sequence
number or not, so we know whether to actually pass them up or not.

The first part of doing all of this is to ensure the ieee80211_rx_stats
struct is available in the RX sequence number check path and the
RX ampdu reorder path. So, start by passing the pointer into these
functions to avoid doing another lookup.

The actual support will come in a subsequent commit once I know the
functionality actually works!

show more ...


# 67bc8c8b 19-Nov-2016 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r308491 through r308841.


# fe75b452 19-Nov-2016 Adrian Chadd <adrian@FreeBSD.org>

[net80211] handle hardware encryption offload in the receive path

* teach the crypto modules about receive offload - although I have
to do some further reviewing in places where we /can't/ have an

[net80211] handle hardware encryption offload in the receive path

* teach the crypto modules about receive offload - although I have
to do some further reviewing in places where we /can't/ have an RX key
* teach the RX data path about receive offload encryption - check the flag,
handle NULL key, do decap and checking as appropriate.

Tested:

* iwn(4), STA mode
* ath(4), STA and AP mode
* ath10k port, STA mode (hardware encryption)

Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D8533

show more ...


12345