| Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
allows us to deduplicate the network ranges sent in the TS payload and saves
some bytes on the wire.
ok patrick@
|
|
|
|
|
|
|
|
|
|
|
|
expected a sorted list, do the sorting ourselves upon parsing
the trip points.
ok kurt@
|
|
Looks nicer and matches the output of GNU grep.
ok millert@ deraadt@ visa@ miod@
|
|
ok kurt@
|
|
ok kurt@
|
|
ok kurt@
|
|
OK visa deraadt
|
|
From Michael Forney, thanks!
|
|
ok guenther@ and deraadt
|
|
ok deraadt@
|
|
the two cases "syscall in main program" (will succeed until we fix go)
and "syscall in library" (now properly fails)
ok mortimer
|
|
|
|
it's nicely backwards compatible, so we can use the same code for
both vxlan and vxlan-gpe.
|
|
|
|
Spotted by jsg@ when working on mesa. Diff tested by sthen@ in
a partial i386 bulk. Input from and ok jsg@ millert@
|
|
they were based on draft-ietf-dhc-dhcpv6-14, which was not what
ended up in the dhcpv6 rfc(s). the current printing code is a lot
smaller and self contained.
ok deraadt@
|
|
it looks like this code was using draft-ietf-dhc-dhcpv6-14 from
1999. there were 27 drafts, and by the time it got to draft 23 and
the rfc it was significantly different. this code for draft 14
cannot handle actual dhcpv6 messages. im kind of surprised
(disappointed?) that noone noticed before. i only noticed cos the
code was segfaulting on sparc64, and when i tried to fix it the
resulting messages looked nothing like what stock tcpdump produced.
the main difference between the early drafts and what ended up in
the rfc is that the base dhcpv6 messages in early drafts were large
structure with a lot of fixed fields, while the rfc settled on a 4
byte header that contains a 1 byte message type and a 3 byte
transaction id. the rest of the messages are built from dhcp options
fields.
this cuts all the old handling out, and fixes the fault in the
options handling by using EXTRACT_16BITS to get at the code and
length fields instead of using ntohs. dhcpv6 explicitly states that
it does not align options, so this is necessary to avoid faults on
strict alignment archs anyway. no options are pretty printed at the
moment, you just get a numeric type, a length, and a hexdump of the
value. this is still better than the garbage that the draft parsing
produced.
if someone is interested in making this easier to read, it would
be a straightforward and well contained project to better handle
option printing.
ok deraadt@
|
|
Saner default behavior that matches GNU grep. Diff from miod@, support
from espie@, ok visa@ millert@
|
|
It appears to have caused major performance regressions all over the
network stack.
Reported by bluhm@
ok deraadt@
|
|
|
|
not the number of bytes that were available in the buffer.
|
|
better that folk doing development in here use their own cp tooling.
|
|
ok florian@
|
|
|
|
obtained by scsi_inquire_vpd().
|
|
Prompted by and OK cheloha@
OK mpi@ anton@
|
|
OK mpi@ anton@
|
|
OK otto
|
|
ok tedu@, visa@
|
|
|
|
display; remove the why bogus status message; ok florian@
|
|
From Chris Wilson
e80e88ef6057c7947409bda9898387d25e54aaa9 in linux 4.19.y/4.19.87
2d691aeca4aecbb8d0414a777a46981a8e142b05 in mainline linux
|
|
From Evan Quan
8a67fbf6597122c4a5e2c48716bc441364357eef in linux 4.19.y/4.19.87
355d991cb6ff6ae76b5e28b8edae144124c730e4 in mainline linux
|
|
|
|
We currently mix timecounter.tc_freq_adj and timehands.th_adjtimedelta
in ntp_update_second() to produce timehands.th_adjustment, our net skew.
But if you set a low enough adjfreq(2) adjustment you can freeze time.
This prevents ntp_update_second() from running again. So even if you
then set a sane adjfreq(2) you cannot unfreeze time without rebooting.
If we just reread timecounter.tc_freq_adj every time we recompute
timehands.th_scale we avoid this trap. visa@ notes that this is
more costly than what we currently do but that the cost itself is
negligible.
Intuitively, timecounter.tc_freq_adj is a constant skew and should be
handled separately from timehands.th_adjtimedelta, an adjustment that
we chip away at very slowly.
tedu@ notes that this problem is sort-of an argument for imposing range
limits on adjfreq(2) inputs. He's right, but I think we should still
separate the counter adjustment from the adjtime(2) adjustment, with
or without range limits.
ok visa@
|
|
need to replay it.
|
|
|
|
|
|
and then a void * for calling the hexdump() operator
with bluhm
|
|
OK mpi@
|
|
Same fix as for the IPv6 case. Fixes a regression in ports/net/openvpn
spotted by landry@, ok bluhm@
|
|
|
|
ok millert@ deraadt@
|