Set package archive timestamps based on most recent source commit
timestamp (approach suggested by bapt).
I'd like to include git metadata in a file included in src tarballs, so
that the build is reproducible (including the hash shown in uname etc.)
outside of a git checkout. There are still details to be sorted out to
do that, so this is an interim step to improve reproducibility.
Reviewed by: bapt
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49165
* add static where needed
* delete old unused flags, dating back to the initial commit from Sam
* indirect through void * where appropriate, to avoid LLVM alignment
errors
* PRIu64 where needed
This does work, but it currently doesn't track the ifname itself,
so we see ifindexes, not ifnames:
Wed Feb 26 18:35:59 RTM_IEEE80211: if# 2, scan complete
Wed Feb 26 18:35:59 RTM_IEEE80211: if# 2, associate with 30🇩🇪4b:db:46:0a
Wed Feb 26 18:35:59 RTM_IFINFO: if# 2, link: up, flags:<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
.. but it does work!
Differential Revision: https://reviews.freebsd.org/D49149
I don't know what I was thinking in 2017 when I wrote this, but
it's very wrong.
Use ifa->ifa_next to iterate, not the array index / pointer arithmetic.
Differential Revision: https://reviews.freebsd.org/D49148
Interfaces all have an mlink to if_$foo. Add these for the missing ones
and remove an incorrect one from rtwn_pci. Wireless network drivers are
all accessible via `apropos -s4 "wireless network driver", except two
which are "wireless network device". I actually prefer the latter, but
make them all consistent upon the more common parlance. Tag SPDX on one
of the files I touched, while here.
MFC after: 3 days
Reviewed by: bz, carlavilla, mhorne
Approved by: carlavilla, mhorne (mentors)
Differential Revision: https://reviews.freebsd.org/D49063
The 'while' part corresponding to the 'do' was missing.
Did not notice the problem as later commits using it have been stashed
and never reworked up to now, and it is currently unused in the tree.
While here, fix spacing after the '#define' in the !(_KERNEL &&
INVARIANS) part.
Fixes: 34740937f7 ("queue: New debug macros for STAILQ")
MFC after: 1 minute
Sponsored by: The FreeBSD Foundation
Provide more details about the influence of optargs' first character
on the shell's behavior in regard to invalid arguments. Also do some
minor word-smithing.
Original submission by rea@
Differential Revision: https://reviews.freebsd.org/D49106
vm_page_alloc() just calls vm_page_alloc_after(), after it has found
the predecessor of a page parameter. Many callers of vm_page_alloc()
already know that predecessor. Letting them pass that to
vm_page_alloc_after() directly could save a little redundant
calculation.
Reviewed by: alc
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D49103
Currently af-to works only on inbound interface by creating a reversed
NAT state key which is used to match traffic returning on the outbound
interface.
Such limitation is not necessary. When an af-to state is created
for an outbound rule do not reverse the NAT state key, making it work
just like if it was created for a normal NAT rule. Depending on firewall
design it might be easier and more natural to use af-to on the outbound
interface.
Reviewed by: kp
Approved by: kp (mentor)
Sponsored by: InnoGames GmbH
Differential Revision: https://reviews.freebsd.org/D49122
Fix typo in commit e59991206b ("==" instead of "=" for the assignment
of st_ino).
Reported by: Coverity Scan CID 1592442
Approved by: kib
Fixes: e59991206b fts(3): be less strict when automount does its job under us walking autofs mount
Set the default refill threshod to be one quarter of the rx queue
length. User can change this value with hw.mana.rx_refill_thresh
in loader.conf. It improves the rx completion handling by saving
10% to 15% of overall time with this change.
Tested by: whu
MFC after: 2 weeks
Sponsored by: Microsoft
libzfs insists that these be cloned from the origin, so avoid making a
deep copy of them ourselves to unbreak creating a new BE from a BE with
encrypted components -- in today's environment, without a loader that
does encryption, this means a deep BE setup where something underneath
the BE (e.g., home directories) are encrypted.
Reported and tested by: arrowd
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D48464
The isi_txrate field is 8 bits and only represents legacy/HT rates.
So to avoid logging a warning, only populate if it's a legacy/HT
rate.
Differential Revision: https://reviews.freebsd.org/D48616
This is one of the two obvious left-over dot11rate lookups that trigger
a debug print. (The other is get_sta_info()).
* Change ieee80211_rate2media() to use the passed in ieee80211_node_txrate
and use the rate type field to see if it's legacy/ht or vht.
* .. and (I hope!) actually handle the VHT rate correctly.
* Change the callers of ieee80211_rate2media() to use the new static
initialisers.
For the one spot in ieee80211_ht.c which uses the HT initialiser, it should
just be a straight up mechanical change that correctly sets the HT MCS
rate.
For the rest of them in ieee80211.c, they're doing table initialisation
for the media types / rates, and it's currently very focused on legacy
rates. So just leave that all as-is for now with a mechanical change.
Differential Revision: https://reviews.freebsd.org/D48615
Update ieee80211_node_get_txrate_mbit() to use
ieee80211_phy_vht_get_mcs_kbit() to calculate VHT rates.
For now just assume long-GI; I'd have to go and do some extra
work to figure out which short/long GI flag to use.
Differential Revision: https://reviews.freebsd.org/D48613
This is a simple implementation, similar to HT, to generate
VHT MCS rates for testing.
I've verified it seems to do the right thing through
MCS 0..9 and NSS 1..2. It's not very optimal - same issues as
with 11n - but it at least now fully tests the 11ac TX path in
rtwn and the tx rate refactoring.
Differential Revision: https://reviews.freebsd.org/D48611
Refactor amrr_node_init() into HT and legacy paths, clean up the
printing to be a bit clearer about the selected rates.
This is precursor work to setting VHT rates in ni->ni_txrate .
Differential Revision: https://reviews.freebsd.org/D48429
Split the amrr_update() routine into HT and legacy paths.
Currently they're the same, minus HT / non-HT specific comments
and some logging changes.
HT rates don't monotonically go up (ie, going MCS 7 -> MCS 8 is wrong,
as MCS8 is "just" two stream MCS0) and failing a rate by a little
shouldn't necessarily preclude testing the next rate up.
This should be a no-op, besides the logging changes.
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48248
Reviewed by: bz, thj
Introduce ieee80211_vht_node_check_tx_valid_mcs(), which takes the
node, bandwidth, NSS and MCS and validates whether that is possible
to TX to the given node.
Differential Revision: https://reviews.freebsd.org/D48610
Reviewed by: bz, thj
* add a node VHT transmit function, which configures the parameters
accordingly.
* add a node VHT transmit function which just copies in another
ieee80211_node_txrate struct.
Differential Revision: https://reviews.freebsd.org/D48609
Reviewed by: bz
Not all NSS / MCS / channel bandwidth combinations are valid.
This will be important for rate control and transmit rate
setup (eg static management, unicast, multicast rates.)
This is based on 802.11-2020 Section 21.5 (Parameters for VHT-MCSs.)
Differential Revision: https://reviews.freebsd.org/D48608
Reviewed by: bz
Implement ieee80211_setup_vht_rates() - calculate the intersection between
the peers advertised RX VHT MCS map and the vap's configured TX map.
Whilst here, remove the unused vhtcap/vhtinfo fields; they're
already populated in the ieee80211_node before ieee80211_setup_vht_rates()
is called.
Differential Revision: https://reviews.freebsd.org/D48607
Reviewed by: bz
Migrate the transmit path to use ieee80211_node_get_txrate(), and handle
VHT rates.
Nothing is currently setting VHT rates, but the driver should now
be ready.
Differential Revision: https://reviews.freebsd.org/D48606
Reviewed by: bz
ieee80211_node_get_txrate() populates the passed-in ieee80211_node_txrate with
the current rate configuration.
This is a no-op - nothing is yet setting VHT rates.
Differential Revision: https://reviews.freebsd.org/D48605
Reviewed by: bz
* create struct ieee80211_node_txrate, which represents both
the existing legacy / HT rates, and makes space for VHT rates
* convert the ieee80211_node_* routines that manipulate the txrate
field to use the new format
* return OFDM6 for now if a VHT rate is set but the driver calls
ieee80211_node_get_txrate_dot11rate(). It SHOULD be the lowest
available rate - which for 11b will be a CCK rate, for
turbo/half/quarter will be different rates! - but this is just
for development.
This should be a no-op for existing drivers and rate control, as
everything now uses the accessor functions instead of directly
accessing ni->ni_txrate.
Locally tested:
* RTL8821AU, STA mode (5GHz VHT/40)
Differential Revision: https://reviews.freebsd.org/D48604
Reviewed by: bz, thj
There are only a few places where the returned rix is used:
* linuxkpi - logging
* bwi/bwn - used for finding a fallback rate to choose, which
honestly should be returned by the ratectl API
* iwm - building the rateset to program into firmware
Everyone else uses the dot11rate value in ni->ni_txnode.
This is a precursor for VHT and later rate support; where currently
there aren't rate tables in ieee80211_phy.c for VHT and later
rates.
Although it's likely doable to add tables for VHT, 11ax and MU-OFDMA
(HE) rates are sufficiently larger/different to just not fit in the
current scheme without more refactoring.
Differential Revision: https://reviews.freebsd.org/D48603
Reviewed by: bz, thj
This just mechanically converts things.
* For linuxkpi, it was just used for display.
* For uath, it was just used for display, as firmware
doesn't report it up.
Differential Revision: https://reviews.freebsd.org/D48602
Reviewed by: bz, thj
The summary:
* Refactor ni_txrate access into ieee80211_node_get_txrate_dot11rate()
and ieee80211_node_set_txrate_dot11rate(). These wrap the ni->ni_txrate
access and will eventually be able to do runtime sanity checks and
fallback where necessary.
* Refactor ieee80211_node_get_txrate_kbit() from the ioctl code which
sets isi_txmbps (which is in 0.5Mbit/s units.) This new routine
returns the TX rate in kbit/s units.
* Also use ieee80211_node_get_txrate_kbit() in various places in the
code where the dot11rate was turned into a Mbit/sec value, which was
very wrong for HT (but also only used for logging, so it didn't
have an effect on normal runtime.)
* Mb -> Mbit/s
The long version:
The current ni->ni_txrate value is what net80211's phy code
calls a 'dot11rate'. Inside the ieee80211_phy.c tables you'll
find a bunch of tables which represent:
* for legacy rates its in 1/2 mbit units.
* for turbo (Atheros 40MHz OFDM) it's the non-turbo rates, but the
turbo rate speed in kbit/sec.
* for 802.11n rates its the MCS, starting at 0x80.
However there are a couple of catches with this:
* Basic rates are represented in the pre-11n rates using the high bit
(IEEE80211_RATE_BASIC)
* 11n rates are also represented using the high bit (IEEE80211_RATE_MCS)
Now, ni->ni_txrate will clear the IEEE80211_RATE_BASIC flag before
storing it, so if the high bit exists it must be an 802.11n rate.
However, there's still a bunch of code everywhere that purposefully
filters that out.
The goals of this commit:
* Provide an easy API to migrate existing drivers and other consumers
to - ieee80211_node_get_txrate_dot11rate() is defined as "will return
the normal legacy or HT rate" so all the existing code can work.
* Lay the ground work for extending ni_txrate (and a rate representation
in general) that can represent legacy, HT, VHT, EHT, HE, etc rates.
* Create a central place where ni_txrate is updated from rate control,
drivers that will update ni_txrate itself, and consumers,
so we can provide some basic runtime checks / logging as VHT, EHT, HE,
etc rates are eventually added.
For example, a VHT driver will eventually receive VHT rates, but an
existing HT driver will not, so the API should log and return a
sensible default when something like a VHT rate shows up on a HT only
device.
The rate control code currently returns a rix, and sets ni_txrate to the
dot11rate. Drivers can choose either. However, choosing the rix is
risky because you need to know if it's the ni_rates or ni_htrates, which
requires a lot of duplicate work that lines up consistently at all
layers (see the AMRR code for an example.)
Differential Revision: https://reviews.freebsd.org/D48601
Reviewed by: bz, thj
Since 9d5c83a0b8 pf depends on the crypto module (for SHA512_*).
Explicitly list this dependency.
PR: 285019
Sponsored by: Rubicon Communications, LLC ("Netgate")
Allow the LUN number to be specified as the key for a LUN instead
of requiring it as a "number" field. If a key is used, permit
a simple string value to be used for non-anymous LUNs. This permits
replacing:
lun = [
{ number = 0, name = zvol_lun },
{
number = 1
backend = ramdisk
size = 1GB
}
]
with:
lun = {
0 = zvol_lun
1 {
backend = ramdisk
size = 1GB
}
}
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D48939
In the case that a separate auth-group is not required, this permits
replacing:
portal-group = { name = pg0 }
with:
portal-group = pg0
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D48938
If a target LUN entry doesn't have a name property, assume it is an
anonymous LUN and parse other properties from the entry to define the
LUN.
This removes the odd support for target LUNs only named by an integer.
My guess is this was meant to implement support for anonymous LUNs
based on how the syntax for this works in the non-UCL case, but the
prior implementation was useless (it just created unconfigured LUNs).
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D48937
- Support for "foreign", "offload", and "tag" properties in portal
group contexts.
- Support for "ctl-lun" and "device-type" properties in LUN contexts.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D48936
The auth-group context required an array of entries for "chap",
"chap-mutual", "initiator-name", and "initiator-portal" whereas the
target context required exactly one entry (and only permitted a single
entry).
Allow either a single entry or an array of entries for these keywords
in both the auth-group and target contexts.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D48935
Errors from auth groups, portal groups, global luns, and targets were
not propagated out of the main loop.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D49071
The primary purpose of this is to permit the rest of ctld to use C++.
However, this also has the nice side effect of reducing code
duplication with the UCL parser.
As a general rule, setting of options including error handling for
invalid values, etc. is moved out of parse.y and into conf.c. The
globals for the current configuration, auth group, portal group, lun,
and target are also moved into conf.c hiding the types from parse.y.
The intention is that all of the functions declared in conf.h will be
extern "C" for use by parse.y and that the backing data structures can
be reimplemented as C++ classes instead of C structures if desired.
A few other small changes are included with this refactoring:
- Warn and fail a configuration that specifies the same LUN multiple
times for a target.
- Use T_* constants for SCSI device types instead of magic numbers.
- Warn and fail for a few UCL properties that aren't the required type
including "discovery-auth-group" in a portal group context,
"auth-type" and "port" in a target context.
- Fix a bug where chap-mutual in a target in UCL would not auto-create
a new auth-group.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D48934
Pointer arithmetic overflow is UB. Convert to unsigned uintptr_t and do
the check there.
PR: 204945
Reported by: David Binderman <dcb314@hotmail.com>
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Compile in the VHT compat code by default even though no one will make
use of it yet.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Tested with: iwlwifi AX210 (NOHT, HT20, HT40, VHT20, VHT40, VHT80)
If HT is enabled but not using CHW=40 set CHW=20 to make sure we do
not get stuck on any other value.
If VHT and the VHT Operation element Channel Width field is 0
(use 20/40) do not update the bandwidth but stick with what HT selected.
This is better than disabling VHT alltogether for 20/40 and allows us
to work on VHT20 and VHT40 APs it seems.
We will have to do more work to can align with the chanctx or deal with
Operating Mode Notification Action frames in LinuxKPI or net80211.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Compile in the HT compat code by default even though no one will make
use of it yet.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Tested with: iwlwifi AX210 (NOHT, HT20 and HT40)
