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.
[29 lines not shown]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.
Approved by: re (cperciva)
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43512
(cherry picked from commit 49619f73151aeaca4cef5adf631253da04a46e19)
(cherry picked from commit f8ec0379435745d800ec149f9289401c792e61bb)
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.
[7 lines not shown]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.
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43512
(cherry picked from commit 49619f73151aeaca4cef5adf631253da04a46e19)
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.
[26 lines not shown]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.
Fixes: f1481c8d3b58e
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43655
(cherry picked from commit 48d689d6cabe41f9c04e75b774ef5b3e45b94469)
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.
[5 lines not shown]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.
[25 lines not shown]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.
Fixes: f1481c8d3b58e
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43655
(cherry picked from commit 48d689d6cabe41f9c04e75b774ef5b3e45b94469)
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.
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43512
(cherry picked from commit 49619f73151aeaca4cef5adf631253da04a46e19)
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.
[5 lines not shown]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.
[15 lines not shown]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
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
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.
[4 lines not shown]sys: Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
Similar commit in current:
(cherry picked from commit 685dc743dc3b)
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 BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
(cherry picked from commit 4d846d260e2b9a3d4d0a701462568268cbfe7a5b)
FreeBSD/src 4d846d2 — lib/libc/stdio wscanf.c xprintf_errno.c, sys/dev/qlxge qls_isr.c
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
net80211: Remove double words in source code comments
- s/we we/we/
(cherry picked from commit 93e491481686bb392b36a01e1569069846cf5f7e)
net80211: Remove double words in source code comments
- s/we we/we/
(cherry picked from commit 93e491481686bb392b36a01e1569069846cf5f7e)
net80211: Remove double words in source code comments
- s/we we/we/
MFC after: 5 days
FreeBSD/src 3d0d5b2 — sys/net80211 ieee80211_ddb.c, sys/netinet ip_fastfwd.c ip_gre.c
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
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
FreeBSD/src c414347 — sys/kern uipc_mbuf.c uipc_domain.c, sys/net80211 ieee80211_proto.c
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
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
net80211(4): Fix a typo in a source code comment
- s/paramaters/parameters/
(cherry picked from commit 044169efe0b7f8a3c30f33ae081054def91acc7d)
net80211(4): Fix a typo in a source code comment
- s/paramaters/parameters/
(cherry picked from commit 044169efe0b7f8a3c30f33ae081054def91acc7d)
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 [-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
(cherry picked from commit 9319211f96c6f11959c76f1d565a744ab37b0031)
