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.
