For now we only return the legacy rate and have two TODOs for HT and
VHT which still need to be implemented as needed.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Given I was looking at the struct make it more packed at the beginning
at least. In fact it did not shrink but the tx_time_est got expanded.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Convert a lot more LinuxKPI rx_status fields to net80211 rx_stats
bits for as much as we can see fit. Factor the entire logic out
into its own function as it got quite long.
Now only net80211 needs to start using more of these values and
report them.
Also fix some related fields and struct definitions in LinuxKPI.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
The value 'index' in a pctrie iterator cannot be written
with "%lx" on a 32-bit machine. Use '%jx' after a uintmax_t cast instead.
Reported by: bz
Fixes: bba883df5e
Add the missing IEEE80211_RX_F_DECRYPTED and IEEE80211_RX_F_MMIC_STRIP
(really just MIC_STRIP) checks to make hwaccel offload work.
This makes rtw8x drivers pass RX packets again at least with LinuxKPI
if HW_CRYPTO support is enabled.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D49030
There are cases when we see "rx seq# violation (CCMP)".
Historically these were AHDEMO/IBBS cases (IEEE80211_KEY_NOREPLAY,
see 5d766a09da).
With iwlwifi(4) doing RSS for newer chipsets and us not having any idea
about multiple rx-queues (passed all the way through) leads to the same
problem. An easy way to trigger this is doing an IPv6 all-nodes echo
request. With a sufficient amount of nodes answering the answers will
be hashed to different queues and re-ordering will likely take place
as queues get released individually.
However crypto validation is already done in fw/driver for these cases
and we need to carry the state forward. Add IEEE80211_RX_F_PN_VALIDATED
to indicate that the checks were done passing the information from driver
through LinuxKPI to net80211.
LinuxKPI enforces that a frame was indeed decrypted; otherwise the flag
would be invalid.
This also avoids returning an error and no key from
ieee80211_crypto_decap() and thus avoids dropping the frame.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D49029
pctrie_iter_remove checks to see if the thing the iterator points to
is actually there, and panics if it is not. This panic would likely
indicate the same iterator had been used for removal twice, without
advancing the iterator in-between. This test takes a bit of time, and
as it indicates a programmer error rather than some external
condition, it is better handled as a KASSERT. This means with KASSERTs
disabled, a wee bit of time is saved.
Reviewed by: alc, markj
Differential Revision: https://reviews.freebsd.org/D49015
This change fixes a couple of issues in the Rockchip SDHCI driver:
- Fix a panic caused by sdhci_fdt_rockchip_attach not populating the
softc's dev variable before initializing clocks
- Fix a bug where sdhci_fdt_rockchip_set_clock fails to call
sdhci_fdt_set_clock
Fixes: e17e33f997
Reported by: Alonso Cárdenas Márquez (acardenas@bsd-peru.org)
Implement ieee80211_rate_set_vht(), ieee80211_rate_get_vht_{mcs,nss}(),
and ieee80211_get_vht_max_nss().
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Until net80211 will grow proper scan offload with the various options
needed and will allow switching the scan engine try to improve the
situation if we are doing a hw_scan and the device supports
SINGLE_SCAN_ON_ALL_BANDS. In that case create the channel list from
our device information of supported channels rather than from the
net80211 scan list. Filter out currently unsupported bands.
While the general "scan EBUSY" problem remains at least in my local
testing I am seeing a lot more 2 and 5 GHz band results rather than
being stuck on a single band (as was also often the case with iwm for
me in the past).
Tested by: rene (previous version)
MFC after: 3 days
An assignment in collapse_scan() has become useless because, on every
path, another assignment to that variable overrides it before that
variable is read. Another assignment can be avoided sometimes, so
move it down in the loop to where it's really necessary.
Reviewed by: alc, markj
Differential Revision: https://reviews.freebsd.org/D49017
For ieee80211_node_delucastkey() rather than checking the keyix to be
IEEE80211_KEYIX_NONE use the IEEE80211_KEY_UNDEFINED() macro (which
chekes the wk_cipher to be 'none').
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D48980
net80211 crypto currently re-uses the M[ichael]MIC flag for MIC as well
at least in CCMP. This is a bit confusing so at least try to improve
the comment that it becomes more obvious.
In the long-term we may want to just add a MIC flag as well?
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D48978
Bits 2 and 3 (\3 and \4 of the %b flag mask) are the 'Supported Channel
Width Set' indicating VHT160 (B2) or VHT160 and VHT80P80 (B3) support.
Though longer rename \4 from CHAN80P80 to CHAN160+80P80 to not confuse
the reader that VHT160 might not be supported.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D48977
ieee80211_setupcurchan() compares the flags in a greater than manner.
In this case VHT160 should be > VHT80P80 as it is preferable.
Swap the two flags and add a comment to note this.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D48976
Add the mask and shift for the VHT Extended NSS BW Support field.
Document them in net80211 and further related bitmasks in LinuxKPI.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D48975
This adds read only support for the W25N series of flash parts.
Specifically starting with the W25N01GV, a 128MiB SPI NAND flash.
This doesn't currently support writing or erasing, as this requires
a NAND flash layer that we don't currently have. There are also
plenty of other commands that aren't currently supported - notably
maintaining the on-chip flash translation layer, flash wear statistics,
etc.
But read support is fine enough for now; it at least allows for
reading the boot / config / calibration flash on my ASUS IPQ4018 based
router.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D48979
The callback CB_RECALL_SLOT is required for NFSv4.1/4.2.
Fortunately, there does not appear to be any extant
NFSv4.1/4.2 servers that use it. Since commit b97a478896
fixed handling of session slot shrinking, this patch
adds support for CB_RECALL_SLOT, which shrinks the
number of session slots as well.
MFC after: 2 weeks
pfi_kkif_attach() annotates the kif with a flag indicating it is the "any" match.
pfi_kif_match obeys() that flag.
ok benno
Obtained from: OpenBSD, henning <henning@openbsd.org>, 4be478ce5d
Sponsored by: Rubicon Communications, LLC ("Netgate")
No change to the underlying type, so no ABI change.
We define __time_t as uint64_t if __LP64__, otherwise uint32_t,
and only define __LP64__ if long is 64 bits.
In other words: __time_t == long.
ok henning@ deraadt@
Obtained from: OpenBSD, guenther <guenther@openbsd.org>, 6c1b69a0ff
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D48963
This is an unlocked check, and after commit 34740937f7 the debug
checks in STAILQ_EMPTY may spuriously fail here. In particular, the per
process queue is updated under the global ktrace mutex, not held in
ktr_drain(). If a record is enqueued concurrently, the recording thread
will schedule an AST to drain the queue again, so it should not be
possible for a race to leave records in the queue indefinitely.
Reviewed by: kib, olce
Reported by: syzbot+d67eddd8c4923ee28bb7@syzkaller.appspotmail.com
MFC after: 2 weeks
Fixes: 34740937f7 ("queue: New debug macros for STAILQ")
Differential Revision: https://reviews.freebsd.org/D48899
In some places, these macros are used without a lock, under the
assumption that they are naturally atomic. After commit
34740937f7 ("queue: New debug macros for STAILQ"), this assumption is
false.
Provide *_EMPTY_ATOMIC for such cases. This lets us include extra debug
checks for the non-atomic case, and gives us a way to explicitly
annotate unlocked checks, which generally deserve extra scrutiny and
might otherwise raise reports from KCSAN.
Reviewed by: kib, olce (previous version)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48899
When a packet matches a binat/nat/rdr rule, pf logs the match. The log
metadata includes the rule's action on the packet, e.g., PF_PASS. NAT
rules have their own actions: PF_BINAT, PF_NAT, PF_RDR.
Before commit 948e8413ab ("pflog: pass the action to pflog directly"),
pflog_packet() would obtain the action from the rule definition, whereas
after that commit the action is passed as a parameter. When a NAT rule
matches, we want to log the rule action, but after that commit, PF_PASS
is hard-coded. Restore the previous behaviour.
Add a regression test which installs a redirect, logs packets matching
the redirect rule, and verifies that the corresponding pflog entry
includes the correct action.
Reviewed by: kp
Fixes: 948e8413ab ("pflog: pass the action to pflog directly")
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: OPNsense
Differential Revision: https://reviews.freebsd.org/D48911
Currently, for DQO QPL our MPASS assertion on qpl_buf_head for available
pending_pkts (i.e. not holding a packet) fails due to incorrect
initialization. The MPASS fails on the first run of packets through the
ring when INVARIANTS is on, and when INVARIANTS is off, things work
without a bug.
The MPASS guards against improper reaping of "pending_pkt" objects,
and thus was failing for the first run through the ring. By correctly
initializing the objects in this patch we make the MPASS not fail on the
first run too.
Signed-off-by: Vee Agarwal <veethebee@google.com>
Signed-off-by: Jasper Tran O'Leary <jtranoleary@google.com>
Reviewed by: delphij, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48968
This commit fixes several minor issues:
- Removes an unnecessary function pointer parameter on gve_start_tx_ring
- Adds a presubmit check against style(9)
- Replaces mb() and rmb() macros with native
atomic_thread_fence_seq_cst() and atomic_thread_fence_acq()
respectively
- Fixes various typos throughout
- Increments the version number to 1.3.2
Co-authored-by: Vee Agarwal <veethebee@google.com>
Signed-off-by: Vee Agarwal <veethebee@google.com>
Signed-off-by: Jasper Tran O'Leary <jtranoleary@google.com>
Reviewed by: delphij, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48969
Before this change, during reset we were allocating new memory for
priv->ptype_lut_dqo, irq_db_array and the counter_array over the old
memory. This change ensures we do not allocate new memory during reset
and avoid memory leaks.
Signed-off-by: Vee Agarwal <veethebee@google.com>
Signed-off-by: Jasper Tran O'Leary <jtranoleary@google.com>
Reviewed by: delphij, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48970
If hardware LRO is enabled with GVE, then setting the driver's MTU to a
range of values around 8000 will cause dropped packets and drastically
degraded performance. While this issue is being investigated, we need
to prohibit the driver's MTU being set to a value within this range.
Signed-off-by: Jasper Tran O'Leary <jtranoleary@google.com>
Reviewed by: delphij, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48971
Those sysctl handlers have been guaranteed to have non-null softc. No
need for NULL check within sysctl handlers.
No functional change intended.
Reviewed by: markj
Tested by: Daniel Porsch <daniel.porsch@loopia.se>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48495
While here, update the description of dev.bnxt.X.dcb to more informative
words "Data Center Bridging".
Reviewed by: markj
Fixes: 35b53f8c98 bnxt_en: Add PFC, ETS & App TLVs protocols support
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48993
It appears that the maximum number of APP TLVs supported by the hardware
is 128 according to D45005. Well Daniel Porsch reported an issue PR284073
which shows that the number can exceed the limit, causing out of bound
write to on-stack allocated variable app[128] and the kernel panics.
Limit to 128 while retrieving APP TLVs.
PR: 284073
Reviewed by: markj
Tested by: Daniel Porsch <daniel.porsch@loopia.se>
Fixes: 35b53f8c98 bnxt_en: Add PFC, ETS & App TLVs protocols support
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48589
It was always set to PCATCH because the driver tested (INTR_OK) instead
of (flags & INTR_OK). Fit a WITNESS_WARN in a single line while here.
MFC after: 1 week
Sponsored by: Chelsio Communications
The driver does minimal initialization in this mode and suspend/resume
should ignore resources that aren't setup. This is for debug only.
kenv hw.cxgbe.sos="1"
kldload if_cxgbe
devctl suspend t6nex0
devctl resume t6nex0
MFC after: 1 week
Sponsored by: Chelsio Communications
We don't use legacy receive descriptors and masking out the vlan ID
isn't necessary since the tag is in the standard format, so remove it.
MFC after: 3 days
For every state pf creates up to two source nodes: a limiting one
struct pf_kstate -> src_node and a NAT one struct pf_kstate -> nat_src_node.
The limiting source node is tracking information needed for limits using
max-src-states and max-src-nodes and the NAT source node is tracking NAT
rules only.
On closer inspection some issues emerge:
- For route-to rules the redirection decision is stored in the limiting source
node. Thus sticky-address and source limiting can't be used separately.
- Global source tracking, as promised in the man page, is totally absent from
the code. Pfctl is capable of setting flags PFRULE_SRCTRACK (enable source
tracking) and PFRULE_RULESRCTRACK (make source tracking per rule). The kernel
code checks PFRULE_SRCTRACK but ignores PFRULE_RULESRCTRACK. That makes
source tracking work per-rule only.
This patch is based on OpenBSD approach where source nodes have a type and each
state has an array of source node pointers indexed by source node type
instead of just two pointers. The conditions for limiting are applied
only to source nodes of PF_SN_LIMIT type. For global limit tracking
source nodes are attached to the default rule.
Reviewed by: kp
Approved by: kp (mentor)
Sponsored by: InnoGames GmbH
Differential Revision: https://reviews.freebsd.org/D39880
Prior to change [1] this flag is useless but harmless. After the change
plat_name[] will be fetched from kernel environment after invoking the
platform probe function `platform_probe_and_attach()`. The probe function
runs at early boot stage prior to `mi_startup()` thus it is too late and
pointless to set plat_name[] after the probe.
Nathan mentioned that the logic to specify the platform pre-dates the
powerpc64 work, and is from the original pre-FDT Book-E bringup from
like 2008, so it's irrelevant these days. Instead of fixing setting the
sysctl knob hw.platform, let's clean it up now.
[1] 3da1cf1e88 Extend the meaning of the CTLFLAG_TUN flag to ...
Discussed with: nwhitehorn
Reviewed by: olce (previous version), jhibbits, #powerpc
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D48897
Translate port numbers for inner udp packets when they're returned
as a payload of icmp error messages. Makes traceroute6 operate
across a nat64 gateway.
prompted by sthen, ok henning
Previous udp port number rewrite fix turned out to be a work around
the incorrect pf_change_ap call. While here make the tcp case use
pf_change_ap since it shares the same properties. ok henning
Obtained from: OpenBSD, mikeb <mikeb@openbsd.org>, 7a304f30d6
Obtained from: OpenBSD, mikeb <mikeb@openbsd.org>, 5d4200d304
Sponsored by: Rubicon Communications, LLC ("Netgate")
IPv6 atomic fragments must not go the reassembly queue, but be
processed immediately. Let pf step over an atomic fragment header
and handle the packet like an unfragmented.
OK mikeb@
Obtained from: OpenBSD, bluhm <bluhm@openbsd.org>, fd6d9d2982
Sponsored by: Rubicon Communications, LLC ("Netgate")
In pf_test_rule, when dealing with a match rule, obey the match rule's quick
flag to decide wether to abort ruleset eval instead of the last matching rule's
one. Makes "match quick" abort ruleset evaluation with the current block/pass
state. From Maxim Khitrov <max at mxcrypt.com>, ok bluhm mikeb
Obtained from: OpenBSD, henning <henning@openbsd.org>, c5611d5b70
Sponsored by: Rubicon Communications, LLC ("Netgate")
Start the expire counter when the queue is created by the first
fragment and drop it if the packet could not be reassembled within
60 seconds.
Reported by Antonios Atlasis; OK henning@ deraadt@
Obtained from: OpenBSD, bluhm <bluhm@openbsd.org>, 4697a20621
Sponsored by: Rubicon Communications, LLC ("Netgate")
