Adds `ifconfig_set_up()` to set and unset the `IFF_UP`
on a network interface using `RTM_NEWLINK`.
Sponsored by: Google LLC (GSoC)
Reviewed by: obiwac, mckusick (mentor), kp
Approved by: obiwac, mckusick (mentor), kp
Differential Revision: https://reviews.freebsd.org/D52128
Currently the idle time will show as `true` part of the time in the json
output and quoting depends on what is being printed. Make sure it's
always printed correctly and for consistency treated as a string in the
json output.
Login time delta and since times are currently exposed in the xml
output, expose these times in the json output as well.
In the json and xml outputs expose the number of seconds idle as a new
field or attribute respectively.
MFC after: 1 week
Sponsored by: Modirum MDPay
Event: Oslo Hackathon 202508
Differential Revision: https://reviews.freebsd.org/D52237
While we are still associated we cannot delete the keys as packets
may still go out and if the firmware has no more keys it will raise
and exception.
This can happen given net80211 has its own mind when to do this and
we, in various places, unlock and re-lock the com lock, so are open
to races.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Split the scan logging up into scan and scan/beacon in order to
not log every beacon if we are trying to debug the scan machinery
but not the actual results.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
In the special case hardware scan fails to start, we cancel the
scan with net80211 and cleanup our part. In that case we now
sleep and wait for a wakeup. The wakeup was moved to a different
callback function to serve both cases (hw scan cancelled, and
hw scan failed).
In the very special case the hardware scan fails with a return code
of 1, we need to start a software scan. I cannot fully imagine this
ever worked well (some rtw88 chipsets are using this). The trouble
is that the cancael_scan runs in a taskq in net80211 and by the time
we tried to start the new scan, the old one was not fully cleaned up
and finished (or could have been restarted in case we enable bgscan).
So defer starting the software scan to the taskq as well and it will
run once the previous finished. The RTW8821ce I tested with seemed
a lot more happy.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
In one of my setups I am sometimes seeing "ghost beacons" (beacons from a
BSSID on a 2nd channel where it is not sending beacons; also checked with
a monitor node to be sure).
In order to rule out later processing errors I added debugging early on
in the LinuxKPI 802.11 RX path. This will at least help us (users) to
debug possible problems more easily by turning on scan debugging (either
here, or using wlandebug +scan to get the net80211 view on it, or both).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
With the option to not use the net80211 scan list but scan all channels
(if we can scan all bands at once, etc.) we possibly scanned more
channels than needed (or we should have). Add a helper function to
sort out disabled channels and channels which are not on the net80211
ic_chan_active list (e.g. removed by regdomain). This could potentially
also remove channels for a 2nd band for software scanning, but in the
offload cases it should not.
Add scan logging for the disabled channels and add scan logging to print
the finalized channel list we are using for this scan (as net80211 has a
similar logging).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Both iwm(4) and iwx(4) are using the iv_dtim_period from the vap.
This likely stems from the fact that ieee80211_sta_join() while setting
up the ni basics does set the dtim_period on the vap (we should revist
this in net80211) from the scan results.
The problem with that is that once we are associated and are receiving
beacons, sta_recv_mgmt() will handle the TIM IE and and save the
tim period and tim count in ni_dtim_period and ni_dtim_count on the node.
Given we need to inform the driver/firmware (at least for iwlwifi)
with values from beacons received after assoc, the ni is the better
place the take the value from (though the beacons hopefully stay
consistent).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Introduce SCAN tracing by adding a dedicated debug category for it
and sprinkle some TRACE_SCAN() lines in hopefully helpful places.
Add an experimental sysctl to re-sort the scan channel list based on
"primary" channels first and 5Ghz before 2Ghz.
Also start scanning the higher bands first (5Ghz before 2.4 even without
the sysctl set).
These are largely a result of various reports of people not able to
see their BSSID on 5Ghz. How much of a difference this will make
in real world and depending on driver/firmware is for the people to
experiment. In my observations iwlwifi(4) independent on all this
presents scan results 2.4 band channels 1..14 first, and then the
5Ghz band channels 177..32.
Factor out re-enabling hardware scan. This is used especially in case
of rtw88 to not be stuck on software scan forever if the rtw88 driver
decides that it currently cannot do a full hw offload scan.
Add compile time support for BGSCANs but keep it disabled by default
as during testing races with net80211 and some APs idle-disconnect
were found. Still check in the code in case we do see a bgscan
despite it being disabled. This stems from 32af70fae8.
Minor improvements like recording the scan_start time and making sure
we properly cancel/restart scans if hw offload scan fails.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
In bc24342d96 we added lower wake_queue locking. There are paths,
such as in rtw89 from a (*hw_scan_cancel)() that we can get to there and
then would recursively acquire the wiphy lock which is not allowed.
Adjust locking to a spin lock to match Linux driver expectations.
Sponsored by: The FreeBSD Foundation
Fixes: bc24342d96
MFC after: 3 days
These structs as part of the union are used to handle raw packet data
so mark them all __packed.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
A Linux definition of a channel has freq, hw_value, band, and flags.
rtw88 so far only set the first two but never set the band on the
channel.
This sorted out channels from scanning (at least after updates) but
possibly also led to other unnoticed circumstances.
Use the macros from rtw89 and replicate the information properly
filling band on each channel definition as well.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Implement str_disable_enable() needed by a wireless driver by using
the already existing str_enable_disable() with a toggled argument.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D52081
No functional change.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: aokblast, imp
Differential Revision: https://reviews.freebsd.org/D52147
+ replace "-*- nroff -*-" comment with SPDX tag
+ alphabetize options in SYNOPSIS and DESCRIPTION
+ add HISTORY, correct two minor mdoc typos
MFC after: 3 days
Reviewed by: imp
Closes: https://github.com/freebsd/freebsd-src/pull/1829
Now that pf is aware of address family of each pool address and source
tracking uses distinct address family for source and redirection
adddresses it is possible to add a new pool option prefer-ipv6-nexthop
which enables routing of IPv4 packets over IPv6 next hops for rules
with the route-to option.
Add a pool option flag PF_POOL_IPV6NH, apply it to pools with a keyword
prefer-ipv6-nexthop.
Modify pf_map_addr() to handle pools with addresses of different
families. Use *naf as a hint about what address family the forwarded
packet is, then pick from the pool addresses of family that can be used
as a next hop for the forwarded packet, controlled by the PF_POOL_IPV6NH
flag. For NAT pools this flag is never set and thus pf_map_addr()
will return an IP address of the same family as the forwarded packet.
For route-to pools when the flag is enabled IPv6 addresses can be
returned or IPv4 packets.
In pf_route() check rt_af, it is not guaranteed to be AF_INET anymore
because pf_map_addr() could have changed it (as *naf).
Add tests for behaviour of pf_map_addr() both with PF_POOL_IPV6NH and
without, for single IP addresses, prefixes and subnets.
Reviewed by: kp
Sponsored by: InnoGames GmbH
Differential Revision: https://reviews.freebsd.org/D50781
We ship cloudware images without a downloaded copy of the pkg repo
database, since it will typically be wildly out of date by the time
cloudware releases get launched. These paths changed due to the
"FreeBSD" -> "FreeBSD-ports" renaming in /etc/pkg/FreeBSD.conf.
While I'm here, nuke the FreeBSD-ports-kmods repo database too; I
forgot to add that when we added that to /etc/pkg/FreeBSD.conf.
Fixes: c83705a575 ("Rename FreeBSD* pkg repos to FreeBSD-ports*")
If MANSRC.{TARGET} is not used, don't truncate the source path of the
page using :T.
Reported by: matteo
Fixes: 65f60d715f ("bsd.man.mk: Add a MANSRC.{TARGET} variable")
Sponsored by: Chelsio Communications
Fix a couple of minor style nits that I've noticed (including the
historical initial blank line). Do this all at once rather than many
commits.
Sponsored by: Netflix
Fix the byte conversion macros for rsvd{2,3}. They are 32-bit quantity,
not 16, so use htole32. These typically aren't used, so this is a nop
for all in-tree uses. This would only have an effect on
powerpc64. Otherwise, we pass the value through unchanged.
Sponsored by: Netflix
The type of variable promisc and allmulti was changed from int to bool
by commit [1].
[1] 7dce56596f Convert to if_foreach_llmaddr() KPI
MFC after: 3 days
Make the refcounting occur outside any code that might deref a pointer
to struct vfsconf.
Increment vfc_refcount in vfs_byname(), under vfsconf_lock.
Unref either on early mount failure, before struct mount is
instantiated, or in vfs_mount_destroy().
Reported and reviewed by: kevans
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Fix the aggregation of the interface level counters
* dev.vtnet.X.tx_task_rescheduled,
* dev.vtnet.X.tx_tso_offloaded,
* dev.vtnet.X.tx_csum_offloaded,
* dev.vtnet.X.rx_task_rescheduled,
* dev.vtnet.X.rx_csum_offloaded, and
* dev.vtnet.X.rx_csum_failed.
Also ensure that dev.vtnet.X.tx_defrag_failed only counts the number
of times m_defrag() fails.
While there, mark sysctl-variables used for exporting statistics as
such (CTLFLAG_STATS).
Reviewed by: Timo Völker
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D51999
It eliminates the need to upgrade the lock in the function.
More importantly, the calls to nfs_advlock_p()/nlm_advlock() sometimes
flush buffers, which requires exclusive locking.
Reported and tested by: bz
Reviewed by: rmacklem
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D52195
gpioc never has any children, so there's no need to call these.
Reviewed by: jhb
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D51933
With gpioc being a direct child of the GPIO controller, it can't
allocate interrupts properly. It currently allocates interrupts using
it's parent dev (gpioX). This causes problems since the call never goes
through gpiobus. Instead, make gpioc a child of gpiobus and allocate
interrupts using our own dev. Also don't misuse pin->flags, it's not
meant to store the flags from sys/gpio.h
Reported by: Evgenii Ivanov <devivanov@proton.me>
Reviewed by: mmel
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D51932
While most GPIO controllers provide pins from 0 .. N in a sequential
manner, not all controllers start with pin 0, and not all controllers
order their pins sequentially. Allow callers to get a pin list from the
controller. The default behaviour is to fill pin_list with pins 0 to
GPIO_PIN_MAX().
Suggested by: mmel
Reviewed by: mmel
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D52172
gpioc normally depends on gpioc_cdevpriv_dtor to call
gpioc_release_pin_intr when it's done with a pin. However, if
gpioc_allocate_pin_intr fails, the pin is never added to the linked list
which the destructor loops over to free the pins. Make it so
gpioc_allocate_pin_intr cleans up after itself if it fails.
Reported by: Evgenii Ivanov <devivanov@proton.me>
Approved by: imp (mentor, implicit)
Differential Revision: https://reviews.freebsd.org/D51998
Add pin_config_32 and pin_access_32 to the gpiobus interface. These work
like the rest of the gpiobus interface. For example, if a child has the
following pins in it's ivars: {2, 7 ... 38} calling these functions with
pin 1 will configure/access pins 7 - 38 on the controller.
Reviewed by: mmel
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D51931
Without -P (or -R, which defaults to enabling -P) symlinks are
dereferenced and so the target file is copied, not the symlink itself.
Fixes: 5e16809c95 ("tzsetup: symlink /etc/localtime instead of copying")
Without -P (or -R, which defaults to enabling -P) symlinks are
dereferenced and so the target file is copied, not the symlink itself.
Fixes: 5e16809c95 ("tzsetup: symlink /etc/localtime instead of copying")
Buildworld failed when objcopy tried to overwrite itself, with `objcopy:
open objcopy failed: Text file busy`. The PATH ended up with `::`,
effectively including the current directory, and we found the wrong
objcopy.
PR: 261215
Sponsored by: The FreeBSD Foundation
When building an ffs image containing large file(s), space requirements
were calculated incorrectly yielding a bigger image than necessary.
The reason is that amount of indirect blocks estimation was done wrong:
- single indirect block was treated as it can hold just 12 data blocks
- nested indirect blocks were not taken into account at all
Add support for indirect blocks and fix another tiny bug with
underestimated space requirement for files with size between
(UFS_NDADDR-1)*blksz+fragsz ... (UFS_NDADDR)*blksz requesting N>1
fragments instead of a whole block.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D52120
[PowerPC] Do not merge TLS constants within PPCMergeStringPool.cpp (#94059)
This patch prevents thread-local constants to be merged within
PPCMergeStringPool.cpp.
The PPCMergeStringPool pass primarily merges non-thread-local constants
together, and thread-local constants should not be mixed together with
other (non-thread-local) constants. In the event that thread-local and
other non-thread-local constants are pooled together, the
llvm.threadlocal.address intrinsic can fail as it expects its argument
to be a thread-local global value, but the merged string structure
created by the PPCMergeStringPool pass is not thread-local as a whole.
This fixes an error "llvm.threadlocal.address first argument must be a
GlobalValue" when building the math/nauty port on PowerPC architectures.
PR: 289122
Reported by: pkubaj
MFC after: 3 days
Muhammad Saheed