kernel - Fix another netinet6 panic, change how ipv6 proxying works
ipv6 isn't naturally proxying subnets on other interface (not responding
to neighbor solicitations) when forwarding is turned on.
However, there are numerous other issues involved here so for now I
am pushing a hack so at least we are backwards-compatible.
* Add a new interface flag, IFF_ANNOUNCE, named "proxy" in ifconfig.
Add "proxy" and "-proxy" options to ifconfig.
* Most non-localhost interfaces will set this bit by default. The bit
can be turned off in ifconfig using -proxy when configuring the interface.
* Adjust nd6_nbr.c (neighbor solicitation code) to respond to
solicitations if (A) the route has RTF_ANNOUNCE set, or (B)
the interface the route is associated with (note: its parent bridge
if the interface is on a bridge) has the IFF_ANNOUNCE bit set.
[10 lines not shown]
kernel - Fix ip6_forward_rt global and related panic
* Make ip6_forward_rt per-cpu, which should fix a route caching panic
that can occur sometimes due to code assuming single-threaded
operation.
evdev: Translate KEY_102ND in evdev_scancode2key()
This is the extra key on AT 102/105-keys keyboards, located just on the
right of the Left Shift key. For instance on a French layout, this key
is used to type '<' and '>'.
This fixes an issue where the key fires no evdev event and thus remains
inactive in an evdev/libinput-enabled X.Org server. The issue only
occurred on an AT keyboard; the same key on a USB keyboard worked fine.
Reported-by: daftaupe
Tested-by: daftaupe, Kentish
Obtained-from: FreeBSD (https://reviews.freebsd.org/D12883)
nrelease: Check GITREV and just fail if empty
The GITREV variable is determined by the tools/gitrev.sh script, which
might fail if the current user has insufficient permission to access the
source directory. That would cause the `uname` to output something
strange that could confuse people. So I think it's better to just fail
the build and require a fix to the build environment.
Reported-by: JustinS
nrelease: Check GITREV and just fail if empty
The GITREV variable is determined by the tools/gitrev.sh script, which
might fail if the current user has insufficient permission to access the
source directory. That would cause the `uname` to output something
strange that could confuse people. So I think it's better to just fail
the build and require a fix to the build environment.
Reported-by: JustinS
nrelease: Fix build due to 'pkg autoremove' removing itself
Since 2025Q1, if the 'ports-mgmt/pkg' package is installed as a
dependency of another package, it will be marked as 'automatic'
and will be removed by a later 'pkg autoremove', which would cause
the nrelease build to fail. Therefore, explicitly install it to
fix the issue.
Reported-by: tuxillo
Discussed-with: bapt
nrelease: Allow /etc/ssl/cert.pem be missing
The 'pkg-bootstrap' target in '/usr/Makefile' has been updated to work
without '/etc/ssl/cert.pem', so ignore copy failure of this file.
nrelease: Improve 'etc.hdd' creation to eliminate inconsistency
Previously, the 'etc.hdd' was created during the 'buildiso' target and
then updated in the 'pkgs' target. However, in the 'pkgs' target, only
the password files (i.e., master.passwd, passwd, group) were copied but
the password DBs (i.e., pwd.db, spwd.db) were not rebuild. This caused
an inconsistency in 'etc.hdd'. When a user tried manual installation
and forgot to run 'pwd_mkdb', the installed system would fail to add new
users and generate errors like:
> pw: user 'myuser' disappeared during update.
> adduser: ERROR: There was an error adding user (myuser).
This commit improves the creation of 'etc.hdd'. Reorder the 'customiso'
target *after* the 'pkgs' target, so we can simply copy the 'etc' to
'etc.hdd' and be done, without any further changes, and the resulting
password files and DBs are in consistency. In addition, this avoids
adding the 'installer' user to the 'etc.hdd' and so we get a cleaner
system by default.
[3 lines not shown]
