Fire UDP receive probes when a packet is received and there is no
endpoint consuming it. Fire the probe also if the TTL of the
received packet is smaller than the minimum required by the endpoint.
Clarify also in the man page, when the probe fires.
Reviewed by: dteske@, markj@, rrs@
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D16046
Some section-4 manpages are architecture-specific, and the build process
currently generates only the pages for the MACHINE_CPUARCH being built.
man(1) supports a '-m' option to find manpages belonging to an arbitrary
architecture other than the MACHINE_[CPU]ARCH, but we have no way to
generate and install alternate-arch pages right now.
This change adds a new make.conf variable, MAN_ARCH, which can be a list of
one or more MACHINE_ARCH or MACHINE_CPUARCH values. All arch-specific
manpages that exist for the named arches will be installed. If unset, it
continues the behavior of installing just the MACHINE_CPUARCH being built.
Differential Revision: https://reviews.freebsd.org/D16198
Code analysis and runtime analysis using truss(8) indicate that the only
privileged operations performed by ntpd are adjusting system time, and
(re-)binding to privileged UDP port 123. These changes add a new mac(4)
policy module, mac_ntpd(4), which grants just those privileges to any
process running with uid 123.
This also adds a new user and group, ntpd:ntpd, (uid:gid 123:123), and makes
them the owner of the /var/db/ntp directory, so that it can be used as a
location where the non-privileged daemon can write files such as the
driftfile, and any optional logfile or stats files.
Because there are so many ways to configure ntpd, the question of how to
configure it to run without root privs can be a bit complex, so that will be
addressed in a separate commit. These changes are just what's required to
grant the limited subset of privs to ntpd, and the small change to ntpd to
prevent it from exiting with an error if running as non-root.
Differential Revision: https://reviews.freebsd.org/D16281
Summary:
Add the device id of the Panda Wireless PAU06 which seems to be
the already-supported combination of RT5392 MAC and RF RT5372
radio.
Reviewed By: allanjude, eadler, jhb
Approved By: jhb
Differential Revision: https://reviews.freebsd.org/D16211
Remove numactl(1), edit numa(4) to bring it some closer to reality,
provide libc ABI shims for old NUMA syscalls.
Noted and reviewed by: brooks (previous version)
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D16142
Several third-parties use at least some of these ioctls. While it would be
better for regression testing if they were used in base (or at least in the
test suite), it's currently not worth the trouble to push through removal.
Submitted by: antoine, markj
API documented in previous version of uhid(4) man page has been obsolete
since May 2009 when old USB stack was replaced with USB2 implentation.
Current API has the same set of ioctl calls but uses usb_gen_descriptor
structure to pass data to/from kernel.
MFC after: 1 week
Update carp to set DSCP value CS7(Network Traffic) in the flowlabel field of
packets by default. Currently carp only sets TOS_LOWDELAY in IPv4 which was
deprecated in 1998. This also implements sysctl that can revert carp back to
it's old behavior if desired.
This will allow implementation of QOS on modern network devices to make sure
carp packets aren't dropped during interface contention.
Submitted by: Nick Wolff <darkfiberiru AT gmail.com>
Reviewed by: kp, mav (earlier version)
Differential Revision: https://reviews.freebsd.org/D14536
Several ioctls are unused in pf, in the sense that no base utility
references them. Additionally, a cursory review of pf-based ports
indicates they're not used elsewhere either. Some of them have been
unused since the original import. As far as I can tell, they're also
unused in OpenBSD. Finally, removing this code removes the need for
future pf work to take them into account.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D16076
To workaround buggy firmware that sets this flag when there's actually
a VGA present.
Reported and tested by: Yasuhiro KIMURA <yasu@utahime.org>
Sponsored by: Citrix Systems R&D
Reviewed by: kib
Differential revision: https://reviews.freebsd.org/D16003
Implement a ddb function walking the namecache to do this.
Reviewed by: jhb, mjg
Inspired by: gdb macro from jhb (old version)
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D14898
Lack of functioning link and activity LEDs on devices without an EEPROM
is expected (not a bug). Quoting the EVB-LAN7850 User's Guide:
When configured with the default internal register settings, the
Ethernet Link status LEDs are not enabled. To enable Ethernet Link
status LEDs, enable the EEPROM.
This is an artifact of the different ways in which the evaluation board
can be used. End-user USB-Ethernet adapters using the Microchip LAN78XX
or LAN7515 controllers should use an EEPROM or have OTP configuration,
if their product configuration does not match the boot default register
configuration.
Sponsored by: The FreeBSD Foundation
Differences between LAN7800 and LAN7850 from the driver's perspective:
* The LAN7800 muxes EEPROM signals with LEDs, so LED mode needs to be
disabled when reading/writing EEPROM. The EEPROM is not muxed on the
LAN7850.
* The Linux driver enables automatic duplex and speed detection when
there is no EEPROM, for the LAN7800 only. With this FreeBSD driver
LAN7850-based adapters without a configuration EEPROM fail to link
(with or without the automatic duplex and speed detection code), so
I have just followed the example of the Linux driver for now.
Sponsored by: The FreeBSD Foundation
Sponsored by: Microchip (hardware)
These ioctls are not documented and only stubbed in a few drivers: mse(4),
psm(4) and syscon's sysmouse(4). The only exception is MOUSE_GETVARS
implemented in psm(4)
Given the fact that they were introduced 20 years ago and implementation
has never been completed, remove any related code.
PR: 228718 (exp-run)
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D15726
of needed interface when many gif interfaces are present.
Remove rmlock from gif_softc, use epoch(9) and CK_LIST instead.
Move more AF-related code into AF-related locations.
Use hash table to speedup lookup of needed softc. Interfaces
with GIF_IGNORE_SOURCE flag are stored in plain CK_LIST.
Sysctl net.link.gif.parallel_tunnels is removed. The removal was planed
16 years ago, and actually it could work only for outbound direction.
Each protocol, that can be handled by if_gif(4) interface is registered
by separate encap handler, this helps avoid invoking the handler
for unrelated protocols (GRE, PIM, etc.).
This change allows dramatically improve performance when many gif(4)
interfaces are used.
Sponsored by: Yandex LLC
or 4 CPUs. Add a compile-time option SC_KERNEL_CONS_ATTRS to control the
defaults.
Default to color numbers in reverse order to CPU numbers (instead of
in the same order with white first and wrapping to dark grey), so that
the brightest bright colors are used first. Don't use dark grey at all;
replace it by dark green.
Syscons has too many compile-time options, but this one is needed in
in case the defaults give something like white on white, or the user
really hates this feature and can't wait to turn it off in rc.
MFC after: next release?
The hardware rate limiting feature is enabled by the RATELIMIT kernel
option. Please refer to ifconfig(8) and the txrtlmt option and the
SO_MAX_PACING_RATE set socket option for more information. This
feature is compatible with hardware transmit send offload, TSO.
A set of sysctl(8) knobs under dev.mce.<N>.rate_limit are provided to
setup the ratelimit table and also to fine tune various rate limit
related parameters.
Sponsored by: Mellanox Technologies
- remove "all rights reserved" from my copyright on my extensive
contributions
- belatedly add my name to tuning.7 which I was a large contributor to
several years ago
This commit can also serve as implicit permission for any formatting or
non-substantive changes that FreeBSD wishes to make in the future.
storage, CDC ACM (serial), and CDC ECM (ethernet) at the same time.
It's quite similar in function to Linux' "g_multi" gadget.
Reviewed by: hselasky@
MFC after: 2 weeks
Relnotes: yes
Sponsored by: The FreeBSD Foundation
This driver was merged to HEAD one week prior to Exar publicly announcing they
had left the Ethernet market. It is not known to be used and has various code
quality issues spotted by Brooks and Hiren. Retire it in preparation for
FreeBSD 12.0.
Submitted by: kbowling
Reviewed by: brooks imp
Relnotes: yes
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D15442
Somehow two copies of the man was in the file, remove one.
Replace an occurence of 'SD/MMC' that was left from copy/paste.
Remove space before ':'
Reported by: 0mp
Each TCP connection that uses the system default cc_newreno(4) congestion
control algorithm module leaks a "struct newreno" (8 bytes of memory) at
connection initialisation time. The NULL-pointer dereference is only germane
when using the ABE feature, which is disabled by default.
While at it:
- Defer the allocation of memory until it is actually needed given that ABE is
optional and disabled by default.
- Document the ENOMEM errno in getsockopt(2)/setsockopt(2).
- Document ENOMEM and ENOBUFS in tcp(4) as being synonymous given that they are
used interchangeably throughout the code.
- Fix a few other nits also accidentally omitted from the original patch.
Reported by: Harsh Jain on freebsd-net@
Tested by: tjh@
Differential Revision: https://reviews.freebsd.org/D15358
This hardware isn't totally ancient, about equal to a mxge(4) or mlx4en(4),
but the company was sold to Exar which then promptly exited the Ethernet
business so the card was commercially available for under 2 years. On deep
search, the only usage of these cards I found was by the importing of the
driver. There are code quality issues identified by Brooks and Hiren and
no visible use nor maintainership that warrant removal from FreeBSD 12.0.
Submitted by: kbowling
Reviewed by: gnn brooks
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D15363
