RST's being ignored, keeping a connection around until it times out, and
thus has the opposite effect of what was intended (which is to make the
system more robust to DoS attacks).
much like the scancode mode.
However the keys that (for no good reason) returns extension codes
etc, are translated into singlebyte codes.
Needed by libvgl. This makes life ALOT easier, also the XFree86
folks could use this.
nuked file descriptor. This is probably why sysinstall's ftp xfer
occasionally SEGV'd if you left things alone for a long time and
the timeout code got called. Whoops!
moment - the compile-time options are useless since the object
files are being used from ppp to build the crunched image, and
the ppp objects include DES at this stage since they were last
built that way to make the secure distribution. Hmmmm!
interface for callbacks to doscmd from DOS, obsoleting the instbsdi
redirector. (redir.com replaces it)
A temporary hack is in place so the instbsdi program will (hopefully) work
in the short term.
Submitted by: Helmut F. Wirth <hfwirth@ping.at>
is asking for trouble (sequential database enumerations can get caught
in an infinite loop). The yp_mkdb(8) utility avoids putting such records
into a database, but ypxfr does not. Today I got bit by a NULL entry in
one of the amd maps on my network, which is served by a SunOS master.
The map was transfered successfully to my FreeBSD slave, but attempting
to dump it with ypcat(1) caused ypserv(8) to transmit the same record
over and over again, making the map appear to be infinitely large. I
finally noticed the problem while testing a new version of amd under
development at the Columbia CS department, which began gobbling up insane
amounts of memory while trying to swallow the map.
To deal with this problem, I'm modifying ypxfr to watch for records
with zero-length keys and turn them into something less destructive
before writing them to the database.
overruns (not that it was a problem, but it could be):
1) Doubled the number of receive buffers in the DMA chain to 64.
2) Do packet receive processing before transmit in the interrupt routine.
'read' command to return an error if the user fails to supply any
input withink a given time period. The behaviour of this option is
similar to that of the like-named option in ksh93.
Reviewed by: joerg
$ vipw
[corrupt a line in editor, exit editor]
pwd_mkdb: corrupted entry
pwd_mkdb: at line #2
pwd_mkdb:
/etc/pw.012585: Inappropriate file type or format
re-edit the password file? [y]: n^D^D
[hang]
if it is in 10Mbps mode and gets certain types of garbage prior to
the packet header. The work-around involves reprogramming the
multicast filter if nothing is received in some number of seconds
(currently set at 15). As a side effect, implemented complete support
for multicasting rather than the previous 'receive all multicasts'
hack, since we now have the ability to program the filter table.
Fixed a serious bug which crept in with the timeout() changes;
the cookie was only saved on the first timeout() call in fxp_init()
and wasn't updated in the most common place in fxp_stats_update()
when the timeout was rescheduled. This bug would have resulted in
an eventual panic if fxp_stop() was called (which happens when any
interface flags are changed, for example).
Fixed a bug in Alpha support that would have caused the TxCB
descriptor chain to span a page boundry, causing serious problems
if the pages didn't happen to be contiguous.
Removed some gratuitous bit masking that was left over from an
older implementation.
Fixed a bug where too much was copied from the configuration
template, spilling over into memory that followed it.
Fixed handling of if_timer...it was cleared too early in some cases.
