As a side effect...
1. The tests now checks for the root user before continuing with kyua, which is
more visible than the test being skipped with the TAP protocol
2. The tests work with devices that aren't /dev/md0 by caching the device
attached during the test to a file, and later use the cached information to
detach the device in the cleanup routine
3. The tests no longer require perl to run
MFC after: 1 week
PR: 191191
Sponsored by: EMC / Isilon Storage Division
- bootparamd
- bootpd
- finger/fingerd
- ftp/ftpd
- hastctl/hastd
- iscsid, et al
- rbootd
- talk/talkd
- tcpd, et al
- tftp/tftpd
Add src.conf entries for the various components and do a best effort
at adding components to tools/build/mk/OptionalObsoleteFiles.inc
OpenBSD; unsure why we chose to do so. As groups are a requirement for
pf, exposing them by default will make our pf implementation less
confusing.
While here add a missing free() that OpenBSD fixed 7 years ago.
PR: 194925
Differential Revision: https://reviews.freebsd.org/D1185
Approved by: des
Obtained from: OpenBSD
Update route MTU in case of ifnet MTU change.
Add new RTF_FIXEDMTU to track explicitly specified MTU.
Old behavior:
ifconfig em0 mtu 1500->9000 -> all routes traversing em0 do not change MTU.
User has to manually update all routes.
ifconfig em0 mtu 9000->1500 -> all routes traversing em0 do not change MTU.
However, if ip[6]_output finds route with rt_mtu > interface mtu, rt_mtu
gets updated.
New behavior:
ifconfig em0 mtu 1500->9000 -> all interface routes in all fibs gets updated
with new MTU unless RTF_FIXEDMTU flag set on them.
ifconfig em0 mtu 9000->1500 -> all routes in all fibs gets updated with new
MTU unless RTF_FIXEDMTU flag set on them AND rt_mtu is less than ifp mtu.
route add ... -mtu XXX automatically sets RTF_FIXEDMTU flag.
route change .. -mtu 0 automatically removes RTF_FIXEDMTU flag.
PR: 194238
MFC after: 1 month
CR: D1125
Initially in_matrote() in_clsroute() in their current state was introduced by
r4105 20 years ago. Instead of deleting inactive routes immediately, we kept them
in route table, setting RTPRF_OURS flag and some expire time. After that, either
GC came or RTPRF_OURS got removed on first-packet. It was a good solution
in that days (and probably another decade after that) to keep TCP metrics.
However, after moving metrics to TCP hostcache in r122922, most of in_rmx
functionality became unused. It might had been used for flushing icmp-originated
routes before rte mutexes/refcounting, but I'm not sure about that.
So it looks like this is nearly impossible to make GC do its work nowadays:
in_rtkill() ignores non-RTPRF_OURS routes.
route can only become RTPRF_OURS after dropping last reference via rtfree()
which calls in_clsroute(), which, it turn, ignores UP and non-RTF_DYNAMIC routes.
Dynamic routes can still be installed via received redirect, but they
have default lifetime (no specific rt_expire) and no one has another trie walker
to call RTFREE() on them.
So, the changelist:
* remove custom rnh_match / rnh_close matching function.
* remove all GC functions
* partially revert r256695 (proto3 is no more used inside kernel,
it is not possible to use rt_expire from user point of view, proto3 support
is not complete)
* Finish r241884 (similar to this commit) and remove remaining IPv6 parts
MFC after: 1 month
Split it into two modules: if_gre(4) for GRE encapsulation and
if_me(4) for minimal encapsulation within IP.
gre(4) changes:
* convert to if_transmit;
* rework locking: protect access to softc with rmlock,
protect from concurrent ioctls with sx lock;
* correct interface accounting for outgoing datagramms (count only payload size);
* implement generic support for using IPv6 as delivery header;
* make implementation conform to the RFC 2784 and partially to RFC 2890;
* add support for GRE checksums - calculate for outgoing datagramms and check
for inconming datagramms;
* add support for sending sequence number in GRE header;
* remove support of cached routes. This fixes problem, when gre(4) doesn't
work at system startup. But this also removes support for having tunnels with
the same addresses for inner and outer header.
* deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD.
Use our standard ioctls for tunnels.
me(4):
* implementation conform to RFC 2004;
* use if_transmit;
* use the same locking model as gre(4);
PR: 164475
Differential Revision: D1023
No objections from: net@
Relnotes: yes
Sponsored by: Yandex LLC
- convert boot1.efi to corrrectly calculate the lba for what the
media reports and convert the size based on what FreeBSD uses.
The existing code would use the 512 byte lba and convert the
size using 4K byte size.
- make fsck_msdosfs read the boot block as 4K so the read doesn't
fail on a 4Kn drive since FreeBSD will error out parition reads
of a block. Make the bpbBytesPerSec check a multiple of 512 since
it can be 512 or 4K depending on the disk. This allows fsck to
pass checking the EFI partition on a 4Kn disk.
To create the EFI file system I used:
newfs_msdos -F 32 -S 4096 -c 1 -m 0xf8 <partition>
This works for booting 512 and 4Kn disks.
Caveat is that loader.efi cannot read the 4Kn EFI partition. This isn't
critical right now since boot1.efi will read loader.efi from the ufs
partition. It looks like loader.efi can be fixed via making some of the
512 bytes reads more flexible. loader.efi doesn't have trouble reading
the ufs partition. This is probably a simple fix.
I now have FreeBSD installed on a system with 4Kn drives and tested the
same code works on 512.
MFC after: 1 week
to mount_nfs(8). They are implemented on Linux, OS X, and Solaris,
and thus can be expected to appear in automounter maps.
Reviewed by: rmacklem@
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
vxlan creates a virtual LAN by encapsulating the inner Ethernet frame in
a UDP packet. This implementation is based on RFC7348.
Currently, the IPv6 support is not fully compliant with the specification:
we should be able to receive UPDv6 packets with a zero checksum, but we
need to support RFC6935 first. Patches for this should come soon.
Encapsulation protocols such as vxlan emphasize the need for the FreeBSD
network stack to support batching, GRO, and GSO. Each frame has to make
two trips through the network stack, and each frame will be at most MTU
sized. Performance suffers accordingly.
Some latest generation NICs have begun to support vxlan HW offloads that
we should also take advantage of. VIMAGE support should also be added soon.
Differential Revision: https://reviews.freebsd.org/D384
Reviewed by: gnn
Relnotes: yes
