net80211: migrate direct printf() to net80211_printf()

Mechanically migrate printf() -> net80211_printf().
A few places looked like they should be using net80211_vap_printf(),
so migrate those appro

net80211: migrate direct printf() to net80211_printf()

Mechanically migrate printf() -> net80211_printf().
A few places looked like they should be using net80211_vap_printf(),
so migrate those appropriately.

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

show more ...

net80211: migrate if_flags, if_drvflags out of most source files

Migrate both if_flags and if_drvflags out of most source files.
Ideally it'd only be referenced in ieee80211_freebsd.c, but for now
i

net80211: migrate if_flags, if_drvflags out of most source files

Migrate both if_flags and if_drvflags out of most source files.
Ideally it'd only be referenced in ieee80211_freebsd.c, but for now
it also ignores references in ieee80211_ioctl.c.

* migrate if_flags set to if_setflags
* migrate if_flags get to if_getflags
* migrate if_drvflags get to if_getdrvflags
* add ieee80211_vap_ifp_check_is_monitor() and
ieee8021_vap_ifp_check_is_simplex() to abstract out the IFF_MONITOR
and IFF_SIMPLEX flag checks.
* add ieee80211_vap_ifp_check_is_running() and
ieee80211_vap_ifp_set_running_state() to represent what IFF_DRV_RUNNING
means (ie, mark the underlying OS network interface as active and
inactive.)

Notably this doesn't yet clear up OACTIVE; I need to better describe
that.

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

show more ...

net80211: deal with lost state transitions

Since 5efea30f039c4 we can possibly lose a state transition which can
cause trouble further down the road.
The reproducer from 643d6dce6c1e can trigger the

net80211: deal with lost state transitions

Since 5efea30f039c4 we can possibly lose a state transition which can
cause trouble further down the road.
The reproducer from 643d6dce6c1e can trigger these for example.
Drivers for firmware based wireless cards have worked around some of
this (and other) problems in the past.

Add an array of tasks rather than a single one as we would simply
get npending > 1 and lose order with other tasks. Try to keep state
changes updated as queued in case we end up with more than one at a
time. While this is not ideal either (call it a hack) it will sort
the problem for now.
We will queue in ieee80211_new_state_locked() and do checks there
and dequeue in ieee80211_newstate_cb().
If we still overrun the (currently) 8 slots we will drop the state
change rather than overwrite the last one.
When dequeing we will update iv_nstate and keep it around for historic
reasons for the moment.

The longer term we should make the callers of
ieee80211_new_state[_locked]() actually use the returned errors
and act appropriately but that will touch a lot more places and
drivers (possibly incl. changed behaviour for ioctls).

rtwn(4) and rum(4) should probably be revisted and net80211 internals
removed (for rum(4) at least the current logic still seems prone to
races).

PR: 271979, 271988, 275255, 263613, 274003
Sponsored by: The FreeBSD Foundation (in 2023)
MFC after: 3 days
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43389

show more ...

net80211: fix checks for (*iv_preamble_update)/(*iv_ht_protmode_update)

Both vap_update_preamble() and vap_update_ht_protmode() also check for
(*iv_erp_protmode_update)() rather than (*iv_preamble_u

net80211: fix checks for (*iv_preamble_update)/(*iv_ht_protmode_update)

Both vap_update_preamble() and vap_update_ht_protmode() also check for
(*iv_erp_protmode_update)() rather than (*iv_preamble_update)()
or (*iv_ht_protmode_update)() before calling the later.
Use the appropriate NULL-function-pointer checks before calling it.

All seem unused currently so no functional changes expected.

MFC after: 3 days
Fixes: f1481c8d3b58e
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43655

show more ...

net80211: make sure calls to (*iv_update_bss)() are locked

It turned out thare various calls into (*iv_update_bss)(), that is
direct changes to vap->iv_bss in the old days, happened without
synchron

net80211: make sure calls to (*iv_update_bss)() are locked

It turned out thare various calls into (*iv_update_bss)(), that is
direct changes to vap->iv_bss in the old days, happened without
synchronisation.

Use locking assertions to document the requirement or status quo
at some callers given ic locking will eventually have to be dealt
with.

MFC after: 3 days
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43512

show more ...

net80211: improve logging about state transitions lost

It is possible that we call ieee80211_new_state_locked() again before
a previous task finished to completion (not run yet or unlocked in
betwee

net80211: improve logging about state transitions lost

It is possible that we call ieee80211_new_state_locked() again before
a previous task finished to completion (not run yet or unlocked in
between) since 5efea30f039c4 (and follow-up).
In either case we would overwrite the new state and argument in the vap.

While most drivers somehow deal with that (or not), LinuxKPI 802.11 compat
code has KASSERTs to keep net80211, LinuxKPI and driver/firmware state in
sync and they may trigger due to a missing transition or more likely a
changed ni/lsta.

Enhance the wlandebug +state logging for these cases so they
are easier to debug.

While here remove the unconditional logging to the message buffer;
it has been here for a good decade but not helped to actually identify
and sort the problem.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D42560

show more ...

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

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

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 ...

net80211: Remove double words in source code comments

- s/we we/we/

MFC after: 5 days

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 ...

netlink: add interface notification on link status / flags change.

* Add link-state change notifications by subscribing to ifnet_link_event.
In the Linux netlink model, link state is reported in 2

netlink: add interface notification on link status / flags change.

* Add link-state change notifications by subscribing to ifnet_link_event.
In the Linux netlink model, link state is reported in 2 places: first is
the IFLA_OPERSTATE, which stores state per RFC2863.
The second is an IFF_LOWER_UP interface flag. As many applications rely
on the latter, reserve 1 bit from if_flags, named as IFF_NETLINK_1.
This flag is mapped to IFF_LOWER_UP in the netlink headers. This is done
to avoid making applications think this flag is actually
supported / presented in non-netlink outputs.
* Add flag change notifications, by hooking into rt_ifmsg().
In the netlink model, notification should include the bitmask for the
change flags. Update rt_ifmsg() to include such bitmask.

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

show more ...

mbufs: isolate max_linkhdr and max_protohdr handling in the mbuf code

o Statically initialize max_linkhdr to default value without relying
on domain(9) code doing that.
o Statically initialize max

mbufs: isolate max_linkhdr and max_protohdr handling in the mbuf code

o Statically initialize max_linkhdr to default value without relying
on domain(9) code doing that.
o Statically initialize max_protohdr to a sane value, without relying
on TCP being always compiled in.
o Retire max_datalen. Set, but not used.
o Don't make the domain(9) system responsible in validating these
values and updating max_hdr. Instead provide KPI max_linkhdr_grow()
and max_protohdr_grow().
o Call max_linkhdr_grow() from IEEE802.11 and max_protohdr_grow() from
TCP. Those are the only protocols today that may want to grow.

Reviewed by: tuexen
Differential revision: https://reviews.freebsd.org/D36376

show more ...

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 ...

net80211(4): Fix a typo in a source code comment

- s/paramaters/parameters/

MFC after: 3 days

Fix unused variable warning in ieee80211_proto.c

With clang 15, the following -Werror warning is produced:

sys/net80211/ieee80211_proto.c:1070:34: error: variable 'num_mixed' set but not used [

Fix unused variable warning in ieee80211_proto.c

With clang 15, the following -Werror warning is produced:

sys/net80211/ieee80211_proto.c:1070:34: error: variable 'num_mixed' set but not used [-Werror,-Wunused-but-set-variable]
int num_vaps = 0, num_pure = 0, num_mixed = 0;
^

The 'num_mixed' variable was in ieee80211_proto.c when the function
vap_update_ht_protmode() was added, but it was never used for anything,
so remove it.

MFC after: 3 days

show more ...

net80211: simplify code after STA/AP VAPs traffic hang fix

Combine the comment and double-unsetting of OACTIVE into a single case
after e8de31caceaa36caf5d7b4355072f148e2433b82.
This saves the quest

net80211: simplify code after STA/AP VAPs traffic hang fix

Combine the comment and double-unsetting of OACTIVE into a single case
after e8de31caceaa36caf5d7b4355072f148e2433b82.
This saves the question of why we do it twice--once right before and
one more time right after the state change check.
Also move the XXX comment about kicking the queue up to where it seems
better suited now.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D35135

show more ...

net80211: Fix traffic hang on STA/AP VAPs on a multi-VAP interface

This took an embarrasingly long time to find.

The state changes for a radio with a STA /and/ AP VAP gets a bit messy.
The AP maps

net80211: Fix traffic hang on STA/AP VAPs on a multi-VAP interface

This took an embarrasingly long time to find.

The state changes for a radio with a STA /and/ AP VAP gets a bit messy.
The AP maps are marked as waiting, waiting for the STA AP to find a
channel to use before the AP VAPs become active.

However, the code path that clears the OACTIVE flag on a VAP only runs
during a successful run of ieee80211_newstate_cb().

So here is how it goes:

* the STA VAP goes down and needs to scan;
* the AP vap goes RUN->INIT; but it doesn't YET call ieee80211_newstate_cb();
* meanwhile - a send on the AP VAP causes the VAP to set the OACTIVE flag here;
* then the STA VAP finishes scan and goes to RUN;
* which will call wakeupwaiting() as part of the STA VAP transition to RUN;
* .. then the AP VAP goes INIT->RUN directly via a call to hostap_newstate
in wakeupwaiting rather than it being through the deferred path;
* /then/ the ieee80211_newstate_cb() is called, but it sees the state go
RUN->RUN;
* .. which results in the OACTIVE flag never being cleared.

This clears the OACTIVE flag when a VAP transitions RUN->RUN; the
driver layer or net80211 layer can set it if required in a subsequent
transmit.

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

Reviewed by: bz

show more ...

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 ...

net80211: add debugging information

Add more STATE / DEBUG probes and enhance the output of one in order
to track state changes triggered by "ack" (or not).
This helped to narrow down causes from dr

net80211: add debugging information

Add more STATE / DEBUG probes and enhance the output of one in order
to track state changes triggered by "ack" (or not).
This helped to narrow down causes from drivers or the LinuxKPI 802.11
compat framework which kept us in a scan -> auth -> scan loop.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

show more ...

net: clean up empty lines in .c and .h files

[net80211] Migrate HT/legacy protection mode and preamble calculation to per-VAP flags

The later firmware devices (including iwn!) support multiple configuration
contexts for a lot of things, leavin

[net80211] Migrate HT/legacy protection mode and preamble calculation to per-VAP flags

The later firmware devices (including iwn!) support multiple configuration
contexts for a lot of things, leaving it up to the firmware to decide
which channel and vap is active. This allows for things like off-channel
p2p sta/ap operation and other weird things.

However, net80211 is still focused on a "net80211 drives all" when it comes to driving
the NIC, and as part of this history a lot of these options are global and not per-VAP.
This is fine when net80211 drives things and all VAPs share a single channel - these
parameters importantly really reflect the state of the channel! - but it will increasingly
be not fine when we start supporting more weird configurations and more recent NICs.
Yeah, recent like iwn/iwm.

Anyway - so, migrate all of the HT protection, legacy protection and preamble
stuff to be per-VAP. The global flags are still there; they're now calculated
in a deferred taskqueue that mirrors the old behaviour. Firmware based drivers
which have per-VAP configuration of these parameters can now just listen to the
per-VAP options.

What do I mean by per-channel? Well, the above configuration parameters really
are about interoperation with other devices on the same channel. Eg, HT protection
mode will flip to legacy/mixed if it hears ANY BSS that supports non-HT stations or
indicates it has non-HT stations associated. So, these flags really should be
per-channel rather than per-VAP, and then for things like "do i need short preamble
or long preamble?" turn into a "do I need it for this current operating channel".
Then any VAP using it can query the channel that it's on, reflecting the real
required state.

This patch does none of the above paragraph just yet.

I'm also cheating a bit - I'm currently not using separate taskqueues for
the beacon updates and the per-VAP configuration updates. I can always further
split it later if I need to but I didn't think it was SUPER important here.

So:

* Create vap taskqueue entries for ERP/protection, HT protection and short/long
preamble;
* Migrate the HT station count, short/long slot station count, etc - into per-VAP
variables rather than global;
* Fix a bug with my WME work from a while ago which made it per-VAP - do the WME
beacon update /after/ the WME update taskqueue runs, not before;
* Any time the HT protmode configuration changes or the ERP protection mode
config changes - schedule the task, which will call the driver without the
net80211 lock held and all correctly serialised;
* Use the global flags for beacon IEs and VAP flags for probe responses and
other IE situations.

The primary consumer of this is ath10k. iwn could use it when sending RXON,
but we don't support IBSS or AP modes on it yet, and I'm not yet sure whether
it's required in STA mode (ie whether the firmware parses beacons to change
protection mode or whether we need to.)

Tested:

* AR9280, STA/AP
* AR9380, DWDS STA+STA/AP
* ath10k work, STA/AP
* Intel 6235, STA
* Various rtwn / run NICs, DWDS STA and STA configurations

show more ...

[net80211] Add initial U-APSD negotiation support.

U-APSD (unscheduled automatic power save delivery) is a power save method
that's a bit better than legacy PS-POLL - stations can mark frames with
a

[net80211] Add initial U-APSD negotiation support.

U-APSD (unscheduled automatic power save delivery) is a power save method
that's a bit better than legacy PS-POLL - stations can mark frames with
an extra flag that tells the AP to leak out more frames after it sends
its own frames rather than needing to send a PS-POLL to get another frame
from the AP.

Now, this code just handles the negotiation bits; it doesn't actually
implement U-APSD. That's up to drivers, and nothing in the tree yet
implements this. I /may/ implement this for ath(4) if I eventually care
enough but right now I plan on just implementing it for firmware offload
based NICs that handle this in the NIC.

I'll commit the ifconfig bit after this and I may have some follow-up
commits as this gets used more by me in local testing.

This should be a glorious no-op for everyone else. If things change
for anyone that isn't fixed by a complete recompile then please reach out
to me.

show more ...

[net80211] Don't call ic_updateslot if it's not set.

Turns out this isn't a required call. I didn't pick it up because my
uncommitted changes involve new updateslot methods for cards I'm working
on.

[net80211] Don't call ic_updateslot if it's not set.

Turns out this isn't a required call. I didn't pick it up because my
uncommitted changes involve new updateslot methods for cards I'm working
on.

Dunce hat to: adrian

show more ...

[net80211] Migrate short slot time configuration into per-vap and deferred taskqueue updates.

The 11b/11g ERP and slot time update handling are two things which weren't
migrated into the per-VAP sta

[net80211] Migrate short slot time configuration into per-vap and deferred taskqueue updates.

The 11b/11g ERP and slot time update handling are two things which weren't
migrated into the per-VAP state when Sam did the initial VAP work.
That makes sense for a lot of setups where net80211 is driving radio state
and the radio only cares about the shared state.

However, as noted by a now deleted comment, the ERP and slot time updates
aren't EXACTLY correct/accurate - they only take into account the most
RECENTLY created VAP, and the state updates when one creates/destroys
VAPs isn't exactly great.

So:

* track the short slot logic per VAP;
* whenever the slot time configuration changes, just push it into a deferred
task queue update so drivers don't have to serialise it themselves;
* if a driver registers a per-VAP slot time handler then it'll just get the
per VAP one;
* .. if a driver registers a global one then the legacy behaviour is maintained -
a single slot time is calculated and pushed out.

Note that the calculated slot time is better than the existing logic - if ANY
of the VAPs require long slot then it's disabled for all VAPs rather than
whatever the last configured VAP did.

Now, this isn't entirely complete - the rest of ERP tracking around short/long
slot capable station tracking needs to be converted into per-VAP, as well
as the preamble/barker flags. Luckily those also can be done in a similar
fashion - keep per-VAP counters/flags and unify them before doing the driver
update. I'll defer that work until later.

All the existing drivers can keep doing what they're doing with the global
slot time flags as that is maintained. One driver (iwi) used the per-VAP
flags instead of the ic flags, so now that driver will work properly.

This unblocks some ath10k porting work as the firmware takes the slot time
configuration per-VAP rather than globally, and some firmware handles
STA+AP and STA+STA (on same/different channels) configurations where
the firmware will switch slot time as appropriate.

Tested:

* AR9380, STA/AP mode
* AR9880 (ath10k), STA mode

show more ...

net80211: post RTM_IFINFO notification after toggling IFF_DRV_RUNNING

This is useful when a wireless driver is stopped or started in response
to events like an RF Kill button press. Applications li

net80211: post RTM_IFINFO notification after toggling IFF_DRV_RUNNING

This is useful when a wireless driver is stopped or started in response
to events like an RF Kill button press. Applications like
wpa_supplicant depend on such events to have a correct view of interface
state.

Reviewed by: adrian, cy, melifaro
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D24925

show more ...