data pointer. This bug has been here since the ti-rpc import; it
apparently broke the clnt_control CLGET_SVC_ADDR options.
PR: misc/27813
Submitted by: Jean-Luc Richier <Jean-Luc.Richier@imag.fr>
record name indicator; this causes a spurious warning:
$ cat x
record:\
:capability=|value:
$ cap_mkdb x
cap_mkdb: ignored duplicate: record
Spotted by: dcs
- move the sysctl code to kern_intr.c
- do not use INTRCNT_COUNT, but rather eintrcnt - intrcnt to determine
the length of the intrcnt array
- move the declarations of intrnames, eintrnames, intrcnt and eintrcnt
from machine-dependent include files to sys/interrupt.h
- remove the hw.nintr sysctl, it is not needed.
- fix various style bugs
Requested by: bde
Reviewed by: bde (some time ago)
This closes a minor information leak which allows a remote observer to
determine the rate at which the machine is generating packets, since the
default behaviour is to increment a counter for each packet sent.
Reviewed by: -net
Obtained from: OpenBSD
errexit (-e) processing. This solves a problem where 'make clean' would
fail with an unspecified error in certain automake-generated makefiles.
Reviewed by: no objections from -hackers...
MFC after: 2 weeks
setting the 'max packet size' register in window 3. This only
works for cards based on the cyclone or newer chipsets (i.e. it
won't work with the original 3c905/boomerang cards).
There is a trick which will work with the boomerang, which is to turn
on the 'large packets ok' bit in the MAC control register, however this
lets the chip accept any frame up to 4K in length, which is larger than
the mbuf cluster buffers we use to receive frames. If somebody sends us
such a frame and the chip DMAs it to us, it could write past the end
of the cluster buffer and clobber something.
PR: kern/27742
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).
