1) Handle forking and non-forking internal services correctly.
Turn on wrapping for internal services because it works now.
2) Preserve server names for each service on HUP.
3) Honour hosts_options(5) severity option.
4) Add IMPLEMENTATION NOTES section to clarify TCP Wrappers
usage and limitations.
This change may cause previously allowed builtin services (e.g. daytime)
to be denied in existing configurations.
PR: 12097
Reviewed by: markm
1)
Reported by: Pierre Beyssac <pb@fasterix.freenix.org>
2)
Submitted by: Masachika ISHIZUKA <ishizuka@ish.org>
3)
Submitted by: David Malone <dwmalone@maths.tcd.ie>
mode by padding out the ``struct device'' to the maximum
device size.
Bump the ppp version number to indicate the transfer format
change.
This should make MP over tty and udp devices functional again.
sizeof(ifr->ifr_addr) for the variable length field ifr->ifr_addr.sa_len.
Otherwise the increment will be wrong in certain cases.
Obtained from: Whistle source tree
For the record: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> suggests
SIOCGIFCONF should be dropped in favor of a sysctl mechanism.
sizeof(ifr->ifr_addr) for the variable length field ifr->ifr_addr.sa_len.
Otherwise the increment will be wrong in certain cases.
Obtained from: Whistle source tree
For the record: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> suggests
SIOCGIFCONF should be dropped in favor of a sysctl mechanism.
having different speed links in a bundle. This would manifest itself
by having the link occasionally hang, but revive when a new connection
is made....
Make ``show mp'' a bit prettier.
o Show more information about missing MP fragments in ``show mp''.
o Do away with mbuf_Log(). It was showing mbuf stats twice on
receipt of LCP/CCP/IPCP packets.... ???!!?
o Pre-allocate a bit extra when creating LQR packets to avoid having
to allocate another mbuf in mbuf_Prepend().
- Mention that the 6Mbps turbo adapters are supported in HARDWARE.TXT
and RELNOTES.TXT and the wi.4 man page
- Mention turbo adapters in the wicontrol.8 man page and provide a
complete table of available transmit speed settings
ADMtek AL981 "Comet" chipset. The AL981 is yet another DEC tulip clone,
except with simpler receive filter options. The AL981 has a built-in
transceiver, power management support, wake on LAN and flow control.
This chip performs extremely well; it's on par with the ASIX chipset
in terms of speed, which is pretty good (it can do 11.5MB/sec with TCP
easily).
I would have committed this driver sooner, except I ran into one problem
with the AL981 that required a workaround. When the chip is transmitting
at full speed, it will sometimes wedge if you queue a series of packets
that wrap from the end of the transmit descriptor list back to the
beginning. I can't explain why this happens, and none of the other tulip
clones behave this way. The workaround this is to just watch for the end
of the transmit ring and make sure that al_start() breaks out of its
packet queuing loop and waiting until the current batch of transmissions
completes before wrapping back to the start of the ring. Fortunately, this
does not significantly impact transmit performance.
This is one of those things that takes weeks of analysis just to come
up with two or three lines of code changes.
on CDs and FTP sites.
o Collapse some redundant code.
o Fix typo'd menu.
o Restrict searches properly to packages rather than categories.
o Small tweaks to signal handling.
All RELENG_3 candidates.
being the same as the previous (still supported) ``host:port''
syntax for tcp socket devices.
A udp device uses synchronous ppp rather than async, and avoids
the double-retransmit overhead that comes with ppp over tcp (it's
usually a bad idea to transport IP over a reliable transport that
itself is using an unreliable transport). PPP over UDP provides
througput of ** 1.5Mb per second ** with all compression disabled,
maxing out a PPro/200 when running ppp twice, back-to-back.
This proves that PPPoE is plausable in userland....
This change adds a few more handler functions to struct device and
allows derivations of struct device (which may contain their own
data etc) to pass themselves through the unix domain socket for MP.
** At last **, struct physical has lost all the tty crud !
iov2physical() is now smart enough to restore the correct stack of
layers so that MP servers will work again.
The version number has bumped as our MP link transfer contents have
changed (they now may contain a `struct device').
Don't extract the protocol twice in MP mode (resulting in protocol
rejects for every MP packet). This was broken with my original
layering changes.
Add ``Physical'' and ``Sync'' log levels for logging the relevent
raw packets and add protocol-tracking LogDEBUG stuff in various
LayerPush & LayerPull functions.
Assign our physical device name for incoming tcp connections by
calling getpeername().
Assign our physical device name for incoming udp connections from
the address retrieved by the first recvfrom().
I simply forgot that I'd already proven this to be a "really good idea that
unfortunately didn't work at all" the *last* time I tried it. Now
I remember. Hmmm. I WILL defeat this evil problem.
