A attacker sending a lot of bogus fragmented packets to the target
(with different IPv4 identification field - ip_id), may be able
to put the target machine into mbuf starvation state.
By setting a upper limit on the number of reassembly queues we
prevent this situation.
This upper limit is controlled by the new sysctl
net.inet.ip.maxfragpackets which defaults to NMBCLUSTERS/4
If you want old behaviour (no upper limit) set this sysctl
to a negative value.
If you don't want to accept any fragments (not recommended)
set the sysctl to 0 (zero)
Obtained from: NetBSD (partially)
MFC after: 1 week
all alphas with devices behind ppb's. I'm working on a better solution now.
Note that all alphas that use per-platform interrupt mapping are broken
again (as they have been for several months)
gigabit ethernet controller chip. This device is used on some
fiber optic gigE cards from SMC, D-Link and Addtron. Jumbograms and
TCP/IP checksum offload on receive are supported. Hardware VLAN
filtering is not, because it doesn't play well with our existing
VLAN code. Also add manual page.
There is a 4.x version of this driver available at
http://www.freebsd.org/~wpaul/Level1/4.x if anyone feels adventurous
and wants to test it. I still need to do performance testing and
tuning with this device.
(For my next trick, I will make the 3Com 3cR990 sit up and beg.)
any response to our third SYN to work-around some broken
terminal servers (most of which have hopefully been retired)
that have bad VJ header compression code which trashes TCP
segments containing unknown-to-them TCP options.
PR: kern/1689
Submitted by: jesper
Reviewed by: wollman
MFC after: 2 weeks
``chown -h owner symlink'' did not set the symlink's owner
if the file the symlink points to already had that owner:
# ls -l alink afile
-rw-r--r-- 1 nobody ru 0 May 31 14:14 afile
lrwxr-xr-x 1 root ru 5 May 31 14:14 alink -> afile
# ./chown -h -v nobody alink
# ls -l alink afile
-rw-r--r-- 1 nobody ru 0 May 31 14:14 afile
lrwxr-xr-x 1 root ru 5 May 31 14:14 alink -> afile
Similarly for chgrp(1) and chmod(1).
it already, their syntax is not compatible with ours. It will confuse
users. So, we have compatibility with their syntex.
Approved by: dwmalone
Obtained from: NetBSD
this works on cs4630 chips, and should implement the clkrun hack for
thinkpads- this will display diagnostic messages when triggered until its
correctness is established.
The PCCard daemon can hang indefinately while reading its
configuration file. If the last line of the file is a comment line
that does not end in a newline, the program goes into an infinite
loop searching for the non-existent newline.
This fix, provided by the PR, will allow files ending without a newline
to be read without hanging.
Submitted by: Crist J. Clark <cjclark@alum.mit.edu>
PR: bin/25791
there and compare the inode and device numbers to the values we remember,
to guard against the directory having been moved around in the meantime.
Reported by: Nick Cleaton <nick@cleaton.net>
one Makefile variable to control the building/installation of both
the DocProj documents and RELNOTESng.
Suggested by: obrien, dd
Tested by: John Hay <jhay@icomtek.csir.co.za>
in okname() in util.c and second, returning != 0 when you do have an
error from okname in two places in rcp.c.
Thanks to Garrett for the POSIX defintion of valid login and group names.
PR: bin/25757
MFC after: 3 weeks
from cpu_switch(), curproc has been changed, but the sched_lock owner will
not be updated until we return to mi_switch(), thus we deadlock against
ourselves. As a workaround, push the acquire and release of sched_lock out
to the callers of set_user_ldt(). Note that we can't use a mtx_assert() in
set_user_ldt for the same reason.
Sleuting by: tmm
Tested by: tmm, dougb
For FTP control connection, keep the CRLF end-of-line termination
status in there.
Fixed the bug when the first FTP command in a session was ignored.
PR: 24048
MFC after: 1 week
"install && rm" change fits in with the new FreeBSD default of
copy instead of move for install. Changing the order of the deletion
of the spurious password files doesn't affect FreeBSD functionality,
but it's done in such a way as not to matter.
Obtained from: Christian Weisgerber <naddy@mips.inka.de>
