Because fnmatch has no side effects, we can safely avoid calling fnmatch
if the end result does not matter anyway (the compiler cannot see this,
so it calls fnmatch in the event it has side-effects).
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/747
The if_flags and if_cap fields hold a bitmask of flags. If a flag is
the MSB of the field, then the logic in setifflags and setifcap which
uses a < 0 check does the wrong thing (it tries to clear the flag
rather than setting it). Also, trying to use -<FOO> doesn't actually
work as the result is a nop. To fix, stop overloading setifcap and
setifflags and instead add new dedicated action functions clearifcap
and clearifflags for clearing a flag. The value passed in the
argument to the command is now always the raw flag.
This was reported by a GCC warning after raising WARNS:
sbin/ifconfig/ifconfig.c:2061:33: error: integer overflow in expression '-2147483648' of type 'int' results in '-2147483648' [-Werror=overflow]
2061 | DEF_CMD("-txtlsrtlmt", -IFCAP_TXTLS_RTLMT, setifcap),
| ^
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D40608
This change exports interface capabilities using the standard
Netlink attribute type, bitset, and switches `ifconfig(8)` to use
it when displaying interface data.
Bitset comes in two representations. The first one is "compact",
where the bits are exported via two arrays - "mask" listing the
"valid" bits and "values, providing the values for those bits.
The second one is more verbose, listing each bit as a separate item,
with its name, id and value. The latter option is handy when submitting
update requests.
The support for setting capabilities will be added in the upcoming diffs.
Differential Revision: https://reviews.freebsd.org/D40331
It is hard to reason about the contents of 'ifr' at any given time
as nearly every function sets random fields or pointers in this
structure.
Use local on-stack clean 'struct ifreq' for each function instead.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D40534
MFC after: 2 weeks
This variable was temporarily introduced in the beginning of the
code cleanup. Use on-stack instance in main() instead.
Reviewed By: kp
Differential Revision: https://reviews.freebsd.org/D40439
MFC after: 2 weeks
Consistenly use newly-added 'ctx->ifname' as the name of the current
target interface.
Reviewed By: kp
Differential Revision: https://reviews.freebsd.org/D40438
MFC after: 2 weeks
This is a pre-requisite for the global 'name' variable removal.
Reviewed By: kp
Differential Revision: https://reviews.freebsd.org/D40432
MFC after: 2 weeks
This variable was used to print the created interface name in the
atexit(3) handler. The interface name was calculated in the
ifclonecreate() by matching old & new names.
This change alter the implementation the following way:
1) the function responsible for the interface creation (ifcreate_ioctl)
updates all necessary state internally. This removes the need for the
name manipulation hack in wlan_create().
2) As atexit(3) handler does not accept any parameters, explicitly store
the name to print in the ifname_to_print variable read by the atexit(3)
handler.
Reviewed By: kp
Differential Revision: https://reviews.freebsd.org/D40431
MFC after: 2 weeks
This is the continuation of the ifconfig cleanup work. This change is
a pre-requsite for the next changes removing some of the global variables.
It will also help in implementing functionality via Netlink instead of ioctl.
No functional changes intended.
* vxlan_cb() was removed as it contained no code
* ioctl_ifcreate() was renamed to ifcreate_ioctl() to follow the other
netlink/ioctl function naming. Netlink and ioctl provide _different_
interfaces and it's not possible to have a unified interface object
that can be filled by either netlink or ioctl implementations. With that
in mind, I'm leaning more to the function_<nl|ioctl> postfix pattern,
than doing ioctl_ or netlink_ prefix.
Reviewed By: kp
Differential Revision: https://reviews.freebsd.org/D40426
MFC after: 2 weeks
Internally, inet and inet6 family handlers store state for
address addition and deletion separately, as, for example,
"ifconfig lo0 inet 127.0.0.2/32" triggers a) deletion of the
first interface address and b) addition of a new one.
The current logic behind handling "-alias" being the last argument
is to copy the address from "addition" state to the "deletion"
state. It is done by the generic ifconfig code, which explicitly
typecasts opaque handler state pointers to "struct ifreq", which
doesn't work in the Netlink case.
Fix this by introducing family-specific "af_copyaddr" handler,
which removes the peeking & typecasting logic from the generic code.
Reported by: otis
Tested by: otis
The structure consists of all current context - arguments,
open sockets, current family and so on.
Pass this structure as a first argument to most of the af_ menthods.
This allows to propagate and update shared data without using
global variables.
The diff is pretty large, but de-facto mechanical. All changes
except the structure setup in ifconfig[_netlink].c are one-line
mechanical changes.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D40239
MFC after: 2 weeks
Cleanup compiler warnings in preparation to set Wextra and remove WARNS?=2
Differential Revision: https://reviews.freebsd.org/D40238
MFC after: 2 weeks
Add -j <jail> flag to ifconfig to allow ifconfig to attach and run inside a
jail. This allow parent to configure network interfaces of its children
even if ifconfig is not available in child's tree (e.g. Linux Jails)
Reviewed by: emaste, khng, melifaro
Event: Kitchener-Waterloo Hackathon 202305
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D40213
When trying to auto-load a module, we trim the interface number off
the end. Currently we stop at the first digit. For interfaces which
have numbers in the driver name this does not work well.
In the current example ifconfig ath10k0 would load ath(4) instead of
ath10k(4). For module/interface names like rtw88[0] we never guess
correctly.
To improve for the case we can, start trimming off digits from the
end rather than the front.
Sponsored by: The FreeBSD Foundation
Reported by: thierry
MFC after: 20 days
Reviewed by: melifaro, thierry
Differential Revision: https://reviews.freebsd.org/D40137
This change is a prerequisite for netlink conversion.
No functional changes intended.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D40033
MFC after: 2 weeks
Reduce the amount of global variables by creating the dedicated
ifconfig_args structure and use it as a context-passing variable.
Simplify the code by moving all argument preparation code a
separate function.
Reviewed by: kp (previous version)
Differential Revision: https://reviews.freebsd.org/D39932
MFC after: 2 weeks
This reverts commit 2c24ad3377.
This change causes some commands to fail, for example when working with
renamed interfaces or when trying to list a nonexistent interface by
name.
PR: 269042
Reported by: dbaio, Michael Paepcke <bugs.fbsd@paepcke.de>
MFC with: 2c24ad3377
If "ifconfig create" tries to load a kernel module, and the module
exists but can't be loaded, fail the command with a useful error
message. This is helpful, for example, when trying to create a cloned
interface in a vnet jail. But ignore ENOENT, because sometimes ifconfig
can't correctly guess the name of the required kernel module.
MFC after: 2 weeks
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D37873
We have repeatedly gotten reports of unclassified SIOCIFCREATE2 errors
(usually "Device not configured"). This can happen if there is
configuration for interfaces in rc.conf which do not (yet) exist and
we try to configure. I can, e.g., provoke this by configuring wlan
interfaces with their physical interface not installed.
In order to cut support (guesswork) down print the name of the
interface to be configured with the error message.
Hopefully this will help us in the future to improve other configuration
or driver problems.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Provide sticky ARP flag for network interface which marks it as the
"sticky" one similarly to what we have for bridges. Once interface is
marked sticky, any address resolved using the ARP will be saved as a
static one in the ARP table. Such functionality may be used to prevent
ARP spoofing or to decrease latencies in Ethernet networks.
The drawbacks include potential limitations in usage of ARP-based
load-balancers and high-availability solutions such as carp(4).
The implemented option is disabled by default, therefore should not
impact the default behaviour of the networking stack.
Sponsored by: Conclusive Engineering sp. z o.o.
Reviewed By: melifaro, pauamma_gundo.com
Differential Revision: https://reviews.freebsd.org/D35314
MFC after: 2 weeks
A quick grep through the kernel code shows network drivers compute the
changed bits of network capabilities after a SIOCSIFCAP IOCTL(2) by
using the bitwise exclusive or operation. When the set capabilities
are equal to the already read capabilities, no action will be taken.
Let ifconfig(8) predict this case and skip the SIOCSIFCAP IOCTL(2)
system call.
Discussed with: kib@ (revert change in case of issues)
MFC after: 1 week
Sponsored by: NVIDIA Networking
Add a postproc function for af_inet, and add interface flags as a
parameter. Check there if setting an address without a mask unless
the interface is loopback or point-to-point, where mask is not really
meaningful; warn if so. This will hopefully be an error in the future.
MFC after: 1 month
Reviewd by: bz
Differential Revision: https://reviews.freebsd.org/D32709
This should eventually replace the socket passed to the various
handlers. In the meantime, making it global avoids repeatedly opening
and closing handles.
Reported by: kp
Reviewed by: kp (earlier version)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D28990
Originally IFCAP_NOMAP meant that the mbuf has external storage pointer
that points to unmapped address. Then, this was extended to array of
such pointers. Then, such mbufs were augmented with header/trailer.
Basically, extended mbufs are extended, and set of features is subject
to change. The new name should be generic enough to avoid further
renaming.
If multiple threads are invoking "ifconfig XXX create" a race may occur
which can lead to two different error messages for the same error.
a) ifconfig: SIOCIFCREATE2: File exists
b) ifconfig: interface XXX already exists
This patch ensures ifconfig prints the same error code
for the same case.
Reviewed by: imp@ and kib@
Differential Revision: https://reviews.freebsd.org/D27380
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
- Add a new send tag type for a send tag that supports both rate
limiting (packet pacing) and TLS offload (mostly similar to D22669
but adds a separate structure when allocating the new tag type).
- When allocating a send tag for TLS offload, check to see if the
connection already has a pacing rate. If so, allocate a tag that
supports both rate limiting and TLS offload rather than a plain TLS
offload tag.
- When setting an initial rate on an existing ifnet KTLS connection,
set the rate in the TCP control block inp and then reset the TLS
send tag (via ktls_output_eagain) to reallocate a TLS + ratelimit
send tag. This allocates the TLS send tag asynchronously from a
task queue, so the TLS rate limit tag alloc is always sleepable.
- When modifying a rate on a connection using KTLS, look for a TLS
send tag. If the send tag is only a plain TLS send tag, assume we
failed to allocate a TLS ratelimit tag (either during the
TCP_TXTLS_ENABLE socket option, or during the send tag reset
triggered by ktls_output_eagain) and ignore the new rate. If the
send tag is a ratelimit TLS send tag, change the rate on the TLS tag
and leave the inp tag alone.
- Lock the inp lock when setting sb_tls_info for a socket send buffer
so that the routines in tcp_ratelimit can safely dereference the
pointer without needing to grab the socket buffer lock.
- Add an IFCAP_TXTLS_RTLMT capability flag and associated
administrative controls in ifconfig(8). TLS rate limit tags are
only allocated if this capability is enabled. Note that TLS offload
(whether unlimited or rate limited) always requires IFCAP_TXTLS[46].
Reviewed by: gallatin, hselasky
Relnotes: yes
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D26691
These are similar to the existing VLAN capabilities.
Reviewed by: kib@
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D25873
