to see if there's anything to do, schedule the next alarm
based on the next required timeout.
This decreases the load when there are lots of relatively
idle ppp processes.
While I'm in there, handle the possibility that a timeout
makes the timer element go out of scope by grabbing the
enext pointer before executing the timer function.
Prevent cron from going crazy if the time steps. For example, if you
have a system with hundreds of users and lots of different crontabs
and your time steps back an hour, the old cron would then attempt to
run an hours worth of cron jobs in a few seconds.
Have pwd_mkdb lock the source file while rebuilding the database. When
called by programs such as vipw, the source file is a temporary file and
this does not conflict with the lock on /etc/master.passwd already held
by vipw. When run manually, however, master.passwd is typically specified
as the argument and the locking prevents other programs from messing with
master.passwd during the database rebuild.
Also pwd_mkdb uses a blocking exclusive lock as it may be called from
a script. The -N option was added to cause pwd_mkdb to get the lock
non-blocking and exit with an error if the attempt fails, again useful
for scripts.
Remove any dial timer that might be hanging around at
datalink_Destroy() time. This timer may be left running
after the link is closed (making sure it's not automatically
opened again too soon).
exits, it causes a select() exception.
Handle these select() exceptions on link descriptors in pretty
much the same way as loss of carrier rather than dropping out
in confusion.
PCI fast ethernet adapters, plus man pages.
if_pn.c: Netgear FA310TX model D1, LinkSys LNE100TX, Matrox FastNIC 10/100,
various other PNIC devices
if_mx.c: NDC Communications SOHOware SFA100 (Macronix 98713A), various
other boards based on the Macronix 98713, 98713A, 98715, 98715A
and 98725 chips
if_vr.c: D-Link DFE530-TX, other boards based on the VIA Rhine and
Rhine II chips (note: the D-Link and certain other cards
that actually use a Rhine II chip still return the PCI
device ID of the Rhine I. I don't know why, and it doesn't
really matter since the driver treats both chips the same
anyway.)
if_wb.c: Trendware TE100-PCIE and various other cards based on the
Winbond W89C840F chip (the Trendware card is identical to
the sample boards Winbond sent me, so who knows how many
clones there are running around)
All drivers include support for ifmedia, BPF and hardware multicast
filtering.
Also updated GENERIC, LINT, RELNOTES.TXT, userconfig and
sysinstall device list.
I also have a driver for the ASIX AX88140A in the works.
# `moused' is getting too over-loaded now. If we want something
# more than simple mouse emulation for tablets or remote devices,
# we should start writing a separate daemon...
Submitted by: luigi
mode' button. Mouse movement will be treated as wheel movement while
this button is held down. Useful for mice with many buttons but
without a wheel.
PR: bin/8001
Submitted by: Hideyuki Suzuki
o Move fixups into extraction routine so all consumers don't have to duplicate
the right behavior.
o Make some things more orthogonal (just for asthetics sake)
o Add option to go back and do it again if XF86Setup fails (possibly with
a different setup - this one has always annoyed me).
configured in the kernel. It gives them a device name of "none" and
monotonically incrementing unit numbers. (starting at 0) Before, pciconf
would just skip over unconfigured devices. (unconfigured devices can be
detected because they have a null string for a device name)
Update the man page to reflect the new pciconf output. Unfortunately, this
causes the sample 'pciconf -l' output lines to wrap, but I'm not sure what
to do about that really.
If anyone presents a reasonable case for printing out something other than
"none1" for unconfigured devices, I'm willing to listen.
for our interface address. We're about to call ip_Input()
anyway, and ip_Input() does the PacketAliasIn().
Stack trace provided by: Cameron Grant <gandalf@vilnya.demon.co.uk>
where "/var/db/kvm_kernel.db" exists.
Note, kvm_mkdb tries to be clever, and skips rebuilding the database
if it thinks it's already up to date. To see the effects of this
fix, you may need to manually delete "/var/db/kvm_kernel.db" and
then run "kvm_mkdb".
match - otherwise, with a delayed (\\d) ``send'', the
timeout may happen during the send and cause a failure.
Problem reported by: David L. Vondrasek <dallas.tx@airmail.net>
are done in the same way as command execution.
For example, ``set proctitle USER INTERFACE PROCESSID'' would
be useful in a -direct profile for identifying who's connected.
for every machine on every class C or smaller subnet that we
route to.
Add ``set {send,recv}pipe'' for controlling our socket buffer
sizes.
Mention the IP number with the problem in a few error messages.
All submitted by: Craig Leres <leres@ee.lbl.gov>
Modified slightly by: me
like
tun0: flags=blah
10.0.0.1 -> 10.0.0.100
10.0.0.2 -> 10.0.0.100
10.0.0.3 -> 10.0.0.100
to DTRT, despite the SIOCAIFADDR for each new alias returning
-1 & EEXIST while adding the alias anyway. In real life, once
we have the second alias with the same destination, nothing will
route any more ! Also, because I was ignoring EEXIST, the
dynamic IP assignment code was assigning duplicate addresses
('cos it was being lied to by iface_inAdd()).
Now we have
tun0: flags=blah
10.0.0.1 -> 255.255.255.255
10.0.0.2 -> 10.0.0.100
10.0.0.3 -> 255.255.255.255
This works - stuff bound to 10.1 & 10.3 will be considered alive
by the kernel, and when they route back to the tun device, the
packets get aliased to 10.2 and go out to 10.100 (as with the
original plan).
We still see the EEXIST in SIOCAIFADDR, but ignore it when our
destination is 255.255.255.255, assuming that the alias *was*
actually added.
Additionally, ``iface add'' may now optionally be given only
the interface address. The mask & destination default to
255.255.255.255.
shortseq, authname and authkey.
o Auth{name,key} may additionally be set in PHASE_ESTABLISH.
o The others may be set in PHASE_ESTABLISH as long as no links
have yet reached DATALINK_LCP.
Interrupt handlers are now configured in drivers.
Didn't update config/SMM.doc. It doesn't have any i386 examples (not
even `isa').
Bumped CONFIGVERS. This is not necessary for -current yet, but using
the new config with old system sources gives null pointers for all
vectors.
demand-dial links with dynamic IP numbers where the program
that causes the dial bind()s to an interface address that is
subsequently changed after ppp negotiation.
The problem is defeated by adding negotiated addresses to the
tun interface as additional alias addresses and providing a set
of ``iface'' commands for managing the interface. Libalias is
also required (and what a name clash!) - it happily IP-aliases
the address so that the source is that of the primary (negotiated)
interface and un-IP-aliases it on the way back.
An ``enable iface-alias'' is done implicitly by the -alias command
line switch. If -alias isn't given, iface-aliasing is disabled by
default and can't be enabled 'till an ``alias enable yes'' is done.
``alias enable no'' silently disables iface-alias.
So, for dynamic-IP-type-connections, running ``ppp -alias -auto blah''
will work for the first connection, although existing bindings will
not survive a disconnect/connect as the TCP peer will be trying to
send to the old IP address - the packets won't route.
It's now a lot easier to add IPXCP to ppp with minor updates to
the new iface.[ch] (if anyone ever gets 'round to it).
It's also now possible to manually add interface aliases with
something like ``iface add 1.2.3.4/24 5.6.7.8''. This allows
multi-homed ppp links :-)
RealTek 8129/8139 chipset like I've been threatening. Update kernel
configs, userconfig.c, relnotes and sysinstall. No man page yet;
comming soon.
I consider this driver stable enough that I want to give it some
exposure in -current.
Didn't bump CONFIGVERS, since ioconf.h was already unused when
CONFIGVERS was last bumped (although essentially the same (CAM)
commit batch that bumped CONFIGVERS also added bogus includes of
ioconf.h).
execvp() in the child branch of a vfork(). Changed to use fork()
instead.
Some of these (mv, find, apply, xargs) might benefit greatly from
being rewritten to use vfork() properly.
PR: Loosely related to bin/8252
Approved by: jkh and bde
- it has longer timeout as per the PnP COM Device Specificaiton 1.0,
- and it tries to obtain the PnP ID string by strictly following the
specification and if it fails, by deploying slightly simplified
steps. (moused has used the simplified method because early PnP mice
do not exactly follow the specification. But now, recent mice
do not supply the ID string unless the strict procedure is used...)
Jointly developed by luigi and yokota.
MD4Update(), but our version in libmd expects a byte count.
This code is not currently compiled or linked into pppd, so I'm
reasonably sure I didn't break anything. :-) I added the necessary
statements to the Makefile, but left them commented out because we
are in feature freeze. When the code is enabled, we must be careful
to build it only if the DES library is available.
Disable building tickadj(8) by removing util from SUBDIR in the xntpd
Makefile. Note that the sources are still there and tickadj can still
be built and installed by doing:
# cd /usr/src/usr.sbin/xntpd/util
# make all install
There are enough references to tickadj in e.g. the xntpd documentation
(not to mention the sysctl variables it uses etc.) that I don't feel
up to implementing the final solution right now.
Kinda-approved-by: phk
route. If your nameserver config is wrong, this will otherwise hang for
the default resolver timeout (75 seconds), leading people to think that
the system has hung.
various ports don't complain about it. It also requires that the pkg
registration bits be stick into the Xbin tarball so that they'll be
present in /usr/X11R6/lib/X11/pkgreg.tar.gz. The registration tarball
is removed upon first use to prevent it later spamming a genuine build
from ports if inadvertently extracted again.
- Accept generic video mode names: 80x25, 80x30, etc. Specific video
mode names, VGA_80x25, VESA_132x25, are still accpeted too.
- Update the man page accordingly.
generation was causing unaligned access faults on the Alpha.
I have incremented the devstat version number, since this is an interface
change. You'll need to recompile libdevstat, systat, iostat, vmstat and
rpc.rstatd along with your kernel.
Partially Submitted by: Andrew Gallatin <gallatin@cs.duke.edu>
fixed variable so all manually-specified devices are shown rather then
cutting the display off at 3, fixed formatting for msps when msps is
larger then 100 (it was blowing the columner display output before),
added -K option to make blk count (-oIK) force a 1K block size (to conform
more closely to systat, vmstat definition of blocksize).
Kazu writes:
The VESA support code requires vm86 support. Make sure your kernel
configuration file has the following line.
options "VM86"
If you want to statically link the VESA support code to the kernel,
add the following option to the kernel configuration file.
options "VESA"
The vidcontrol command now accepts the following video mode names:
VESA_132x25, VESA_132x43, VESA_132x50, VESA_132x60, VESA_800x600
The VESA_800x600 mode is a raster display mode. The 80x25 text will
be displayed on the 800x600 screen. Useful for some laptop computers.
vidcontrol accepts the new `-i <info>' option, where <info> must be
either `adapter' or `mode'. When the `-i adapter' option is given,
vidcontrol will print basic information (not much) on the video
adapter. When the `-i mode' option is specified, vidcontrol will
list video modes which are actually supported by the video adapter.
Submitted by: Kazutaka YOKOTA yokota@FreeBSD.ORG
===================================
HARP | Host ATM Research Platform
===================================
HARP 3
What is this stuff?
-------------------
The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center,
Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed
the Host ATM Research Platform (HARP) software, which allows IP hosts to
communicate over ATM networks using standard protocols. It is intended to
be a high-quality platform for IP/ATM research.
HARP provides a way for IP hosts to connect to ATM networks. It supports
standard methods of communication using IP over ATM. A host's standard IP
software sends and receives datagrams via a HARP ATM interface. HARP provides
functionality similar to (and typically replaces) vendor-provided ATM device
driver software.
HARP includes full source code, making it possible for researchers to
experiment with different approaches to running IP over ATM. HARP is
self-contained; it requires no other licenses or commercial software packages.
HARP implements support for the IETF Classical IP model for using IP over ATM
networks, including:
o IETF ATMARP address resolution client
o IETF ATMARP address resolution server
o IETF SCSP/ATMARP server
o UNI 3.1 and 3.0 signalling protocols
o Fore Systems's SPANS signalling protocol
What's supported
----------------
The following are supported by HARP 3:
o ATM Host Interfaces
- FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters
- FORE Systems, Inc. PCA-200E ATM PCI Adapters
- Efficient Networks, Inc. ENI-155p ATM PCI Adapters
o ATM Signalling Protocols
- The ATM Forum UNI 3.1 signalling protocol
- The ATM Forum UNI 3.0 signalling protocol
- The ATM Forum ILMI address registration
- FORE Systems's proprietary SPANS signalling protocol
- Permanent Virtual Channels (PVCs)
o IETF "Classical IP and ARP over ATM" model
- RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
- RFC 1577, "Classical IP and ARP over ATM"
- RFC 1626, "Default IP MTU for use over ATM AAL5"
- RFC 1755, "ATM Signaling Support for IP over ATM"
- RFC 2225, "Classical IP and ARP over ATM"
- RFC 2334, "Server Cache Synchronization Protocol (SCSP)"
- Internet Draft draft-ietf-ion-scsp-atmarp-00.txt,
"A Distributed ATMARP Service Using SCSP"
o ATM Sockets interface
- The file atm-sockets.txt contains further information
What's not supported
--------------------
The following major features of the above list are not currently supported:
o UNI point-to-multipoint support
o Driver support for Traffic Control/Quality of Service
o SPANS multicast and MPP support
o SPANS signalling using Efficient adapters
This software was developed under the sponsorship of the Defense Advanced
Research Projects Agency (DARPA).
Reviewed (lightly) by: phk
Submitted by: Network Computing Services, Inc.
Host ATM Research Platform (HARP), Network Computing Services, Inc.
This software was developed with the support of the Defense Advanced
Research Projects Agency (DARPA).
