methods called Vestigial Time-Wait (VTW) and Maximum Segment Lifetime
Truncation (MSLT).
MSLT and VTW were contributed by Coyote Point Systems, Inc.
Even after a TCP session enters the TIME_WAIT state, its corresponding
socket and protocol control blocks (PCBs) stick around until the TCP
Maximum Segment Lifetime (MSL) expires. On a host whose workload
necessarily creates and closes down many TCP sockets, the sockets & PCBs
for TCP sessions in TIME_WAIT state amount to many megabytes of dead
weight in RAM.
Maximum Segment Lifetimes Truncation (MSLT) assigns each TCP session to
a class based on the nearness of the peer. Corresponding to each class
is an MSL, and a session uses the MSL of its class. The classes are
loopback (local host equals remote host), local (local host and remote
host are on the same link/subnet), and remote (local host and remote
host communicate via one or more gateways). Classes corresponding to
nearer peers have lower MSLs by default: 2 seconds for loopback, 10
seconds for local, 60 seconds for remote. Loopback and local sessions
expire more quickly when MSLT is used.
Vestigial Time-Wait (VTW) replaces a TIME_WAIT session's PCB/socket
dead weight with a compact representation of the session, called a
"vestigial PCB". VTW data structures are designed to be very fast and
memory-efficient: for fast insertion and lookup of vestigial PCBs,
the PCBs are stored in a hash table that is designed to minimize the
number of cacheline visits per lookup/insertion. The memory both
for vestigial PCBs and for elements of the PCB hashtable come from
fixed-size pools, and linked data structures exploit this to conserve
memory by representing references with a narrow index/offset from the
start of a pool instead of a pointer. When space for new vestigial PCBs
runs out, VTW makes room by discarding old vestigial PCBs, oldest first.
VTW cooperates with MSLT.
It may help to think of VTW as a "FIN cache" by analogy to the SYN
cache.
A 2.8-GHz Pentium 4 running a test workload that creates TIME_WAIT
sessions as fast as it can is approximately 17% idle when VTW is active
versus 0% idle when VTW is inactive. It has 103 megabytes more free RAM
when VTW is active (approximately 64k vestigial PCBs are created) than
when it is inactive.
from userland is initialized (it is used by the kernel only)
fixes crash or data injection (CVE-2010-3830), usually by root user only
OpenBSD has rewritten the code to start with a zero'd struct and fills
in needed parts only - to be considered in case a newer pf version
is imported.
packets due to wrong buffer size computations. The corrupted
mbufs could lead to a panic.
Fix computation of link mtu where the link mtu itself is unspecified.
Limit ICMP error packets for IPv6 to MMTU as required by RFC4443. This
also avoids dropped errors when the length exceeds the link mtu.
using an EXTERN_INLINE definition for functions that are defined as
inline but provide an externally callable reference.
(these are externally called in ipftest)
pfs(8) is a tool similar to ipfs(8) but for pf(4). It allows the admin to
dump internal configuration of pf, and restore at a latter point, after a
maintenance reboot for example, in a transparent way for user.
This work has been done mostly during my GSoC 2009
No objections on tech-net@
#if NBPFILTER is no longer required in the client. This change
doesn't yet add support for loading bpf as a module, since drivers
can register before bpf is attached. However, callers of bpf can
now be modularized.
Dynamically loadable bpf could probably be done fairly easily with
coordination from the stub driver and the real driver by registering
attachments in the stub before the real driver is loaded and doing
a handoff. ... and I'm not going to ponder the depths of unload
here.
Tested with i386/MONOLITHIC, modified MONOLITHIC without bpf and rump.
Note: the ipf code contains a lot of ifdefs, some of them for NetBSD
versions that are no longer maintained. It won't make the code more
readable, but we should consider removing them.
Pfsync interface exposes change in the pf(4) over a pseudo-interface, and can
be used to synchronise different pf.
This work was part of my 2009 GSoC
No objection on tech-net@
http://git.moblin.org/cgit.cgi/acpica/commit/?id=26a2eea9f4a18acb0ba2a92070d945d9835df948
I uncovered the bug by having the console flooded with:
ACPI Error (evgpe-0896): No handler or method for GPE[ 0], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ 1], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ 2], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ 4], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ 5], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ 6], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ 7], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ 8], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ 9], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ A], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ B], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ C], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ D], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ E], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[ F], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[10], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[11], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[12], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[13], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[14], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[15], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[16], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[17], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[18], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[19], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[1A], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[1B], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[1C], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[1D], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[1E], disabling event [20080321]
ACPI Error (evgpe-0896): No handler or method for GPE[1F], disabling event [20080321]
and with breaking into ddb:
ACPI Error (evgpe-0899): No handler or method for GPE[ 0], disabling event [20080321]
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ffffffff8020c1fd cs e030 rflags 296 cr2 0 cpl 8 rsp ffffffff80f32c98
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x5: leave
breakpoint() at netbsd:breakpoint+0x5
AcpiEvGpeDispatch() at netbsd:AcpiEvGpeDispatch+0x9f
AcpiEvGpeDetect() at netbsd:AcpiEvGpeDetect+0x136
AcpiEvSciXruptHandler() at netbsd:AcpiEvSciXruptHandler+0x46
Xresume_xenev6() at netbsd:Xresume_xenev6+0x55
With this merged fix console is no longer flooded and I get in dmesg:
ACPI Exception (evevent-0165): AE_BAD_ADDRESS, Unable to initialize fixed events [20080321]
acpi0: unable to enable ACPI: AE_BAD_ADDRESS
Upstream fix pointed out by jmcneill@, merged fix ok'd by joerg@.
2031730 4.1.31 Nat drops fragmented packets after the first
http://ipfilter.cvs.sourceforge.net/viewvc/ipfilter/ipfilter/ip_nat.c#rev1.2.2.48
Fixes problems on UDP NFS with ipnat as mentioned in PR kern/38773 and
PR kern/41074. Tested on several slow NFS clients and an i386 server
running ipnat.
Should be pulled up to 5.0.
has been changed from m0 to *mpp. But as *mpp has been set to NULL just
before the call, we end up calling ether_output() with a NULL mbuf,
leading to a NULL pointer dereference. Revert back to using m0 here.
The issue show up when using 'return-rst' or 'return-icmp' in ipf6.conf.
Problem discovered and fix tested on ftp.fr.netbsd.org.
drochner