Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z - Internet FAQ Archives

comp.unix.sco Technical FAQ (4/5)

( Part1 - Part2 - Part3 - Part4 - Part5 )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Forum archive ]
FAQ Starting Page

These FAQS were developed and maintained for years by (Stephen M. Dunn). Steve no longer has the time to
maintain them, and has asked me to take them over. Please remember the
debt all of us owe to Steve for his efforts- I myself spent many hours
learning from these very documents, and I'm sure many of us can say
similar things.

Because Steve has not been able to maintain these for a while now,
some of the information herein is outdated. I am working to correct
that, but it's a lot to catch up on, so if you spot something, please
let me know. For the moment, I'm just marking some of it as probably
being useless; as I have time, I'll check further to be certain before
I remove anything.

Suggestion: Use my Search to find what you are looking for.

telnet doesn't work properly

See reader questions & answers on this topic! - Help others by sharing your knowledge
   There is a known bug in telnetd under Xenix (and probably also under
   Unix), which causes it to be flaky when accessed by certain other
   software (such as Novell's LAN Workplace for DOS). This is supposed to
   have been fixed in TCP/IP 1.2; also, the Xenix problem was supposed to
   have been fixed in lng337, which is no longer available.
   Note that there may also be problems if you install an older version
   of TCP/IP on a newer operating system. The newer version of /bin/login
   from your operating system may be overwritten by the older version
   from TCP/IP.
   [Table of Contents]
How do I know if I have enough streams buffers for TCP/IP and/or NFS?

   In OpenServer Release 5, streams buffers are among the data structures
   allocated dynamically by the kernel, and so in general you will never
   need to tune them because the system will allocate more if it's
   running short. Note also that OSR5 does away with the 80% and 90%
   (default) low and medium priority limits.
   Under Xenix, use the program sw (stream watch); it will provide a
   dynamic display of the current and historical usage of various stream
   buffers. Under Unix, you can use the crash command; the subcommand to
   use is strstat. Under TCP/IP for Unix, you can also use the netstat -m
   command. Finally, u386mon, available as tls012, provides similar
   Generally, you should set each class of streams buffer to be 30-40%
   higher than the maximum usage you see, because by default the kernel
   will usually only use 80% of the buffers you have allocated (the rest
   are reserved for high-priority use, and this percentage is tunable;
   there is probably no reason why you can't set STRLOFRAC to 95 and
   STRMEDFRAC to 97). Leave your system running and under typical use for
   as long as practicable (at least a few days, if at all possible), and
   then use one of the tools mentioned above to check the status of your
   streams buffers. These tools list the configured limits for each class
   of buffers, the maximum number of each class used since the system was
   rebooted, and also how many times an allocation request for a given
   class has failed due to lack of available buffers. It's usually not a
   bad idea to tune the number of each class of buffer, because if you've
   allocated far more than is needed you're wasting memory and if you've
   underallocated, you may experience problems. For more information,
   consult your System Administrator's Guide.
   [Table of Contents]
TCP/IP gives messages like "Notice: TCP SUM: SRC 89270107 SUM 0000D7AD"

   This simply means that TCP detected a checksum error in a packet. TCP
   is a reliable protocol and will automatically request that the packet
   be re-sent. This message serves as a notice only and should not be of
   concern unless it occurs frequently. If you wish to determine the IP
   address of the machine that sent the bad packet, convert the SRC field
   from hexadecimal ( to decimal ( There are two
   common causes for these on high-speed networks, which are flaky
   network cards and slow cards that can't keep up with network traffic.
   Also, these messages are common on SLIP and PPP links.
   Under Unix, at least, you may be able to stop the system from printing
   these errors. In /etc/conf/pack.d/tcp/space.c, find the line which
   reads int tcpprintfs = 1; and change the 1 to a 0. Relink the kernel
   and reboot. I don't know of any similar procedure under Xenix ...
   In OpenServer Release 5, this variable defaults to zero (i.e. not
   printing these diagnostics). It can be adjusted without a reboot using
   [Table of Contents]
How do I get /etc/issue to print for telnet sessions?

   Modern releases use /etc/issue for telnet sessions
   See TA 640279. Basically, you will need to create a file (we'll call
   it /etc/telbanner), owned by bin/bin and readable by everyone, with
   the message to be printed. Next, create the following shell script and
   call it /etc/telbannerd:
# name of file with banner
# name of telnet daemon
# print banner if it exists and is readable
[ -r ${BANNER_FILE} ] && cat ${BANNER_FILE}
# now pass control to telnetd
exec ${TELNETD} $*

   This script should be owned by bin/bin and world-executable and world-
   readable. Now edit the telnet line in /etc/inetd.conf and change the
   /etc/telnetd to /etc/telbannerd. Leave everything else exactly as it
   is. Finally, you'll need to send a SIGHUP to inetd to force it to
   re-read /etc/inetd.conf.
   One other note - in order for the above to work, you need the kernel
   support for #! turned on; see the entry on hashplingenable in section
   3 of this FAQ.
   [Table of Contents]
What does "WARNING: tcp_deqdata" mean?

   This error means that streams resources need to be increased due to
   the volume of traffic on the network. See the earlier entry in this
   section on how to check which streams buffers need to be increased.
   [Table of Contents]
Ping is really slow.

   If you're finding that ping times are measured in seconds, even for
   hosts which you know should be responding faster, it's usually a DNS
   problem. Even if you supply ping with an IP addrses, it still does DNS
   lookups so that when it get a packet back, it can display both the IP
   address and the host name.
   Test to see if it's a DNS problem by using ping -n; the -n flag turns
   off DNS lookups. If ping -n works quickly but ping takes forever, you
   have a DNS problem. Check the entries in /etc/resolv.conf and make
   sure that they do, in fact, point to functional and reachable DNS
   servers. It's also a good idea, when troubleshooting DNS problems, to
   ping -n each of the DNS servers listed in /etc/resolv.conf to ensure
   that the machines are actually alive. As well, try using them to do
   DNS lookups to make sure not only that the machines are running but
   that they have usable DNS servers on them (e.g. if you list
   aaa.bbb.ccc.ddd as one of your servers, try nslookup
   [Table of Contents]
Telnet/FTP is very slow to connect

   Slow telnet or ftp connections are often caused by the server wanting
   to to a reverse DNS lookup to find out who is connecting. If you
   aren't running DNS, you can fix this just by listing all the machines
   in /etc/hosts. Note that you don't have to be accurate about the
   names: I often use the ip adress with "_" substituted for the "."'s,
   like "host_192_168_2_3" and so on. See Installing a Small Office
   Network for a script that
   will produce these.
   [Table of Contents]
Dial in PPP disconnects immediately

   Check to make sure that "idle" isn't set to 1 in /etc/ppphosts- it
   will disconnect immediately.
   [Table of Contents]
How do I add a default route?

route add default

   would set the default route to, but that would not survive a
   Prior to 5.0.6, there was no certain place to add this (it's now part
   of "netconfig"). You'll need to add the commands to a start-up file
   (/etc/rc2.d/S99route, for example: it doesn't exist, but you can
   create it) or modify the /etc/gateways file (see 'man routed'for the
   syntax of that file). The disadvantage of /etc/gateways is that it is
   used by routed, so if you are not running routed, that won't work.
   You could also modify /etc/tcp and add your routes after it sets up
   its default routes. That has the disadvantage of modifying a system
   file: an upgrade will overwrite that.
   SCO 5.0.4 adds a /etc/rc2.d/S90iproute script that reads
   /usr/internet/etc/sco_ip/routes. It's the Internet Manager that can
   add info to that file, but there's no reason you can't do it manually.
   The format is simple:

# comments are ok
# simple form
net default
# it's smart enough to delete the previous default
net default
# routes to specific hosts
# netmasks optional
# if field 1 isn't host or net, it's ignored

   Another advantage of this script is that when called with "stop"
   (/etc/rc2.d/S90iproute   stop), it will delete the routes listed in
   the file.
   The "routed" daemon can reset your routes- disable it (edit /etc/tcp)
   if you are not using it.
   [Table of Contents]
How do I test a popd connection?

telnet popserver 110
-server will (or should) respond indicating that it is ready
user username
- server will tell you that a password is required
pass usernames_password
- server will tell you how many messages username has
- server will show you size of each message
retr 1
- first message will be displayed

   [Table of Contents]
Why can't my other sub-net browse the Visionfs or Samba shares?

   Because that's the way Microsoft wants it to work.
   First, if all you want to do is ACCESS the shares, you can, even
   though they don't pop up in Network neighborhood. You'll need a
   \WINDOWS\LMHOSTS file, and all it needs in it is something like this: mysmbserver #PRE

   For NT, it's "\WINNT\SYSTEM32\DRIVERS\ETC\LMHOSTS" (assuming your
   system is in \WINNT)
   The "#PRE" is not a comment, it needs to be there. With this in place
   (and you probably need to reboot, you can do Start-&gtRun, type
   \\mysmbserver and, all other things being equal, it will pop up.
   But if you want to browse across sub-nets, you need more. Microsoft
   wants you to put in an NT server on the subnet's LAN; you can do it
   with a Unix/Linux machine running Samba and get the same benefit.
   [Table of Contents]
How do I get the latest version of Visionfs for Unixware 7 and OSR5 5.0.4 or

   Download the latest version of Visionfs from Sco's Vision Site.
   [Table of Contents]
Why do I get "portmapper is not responding" errors?

   "portmapper is not responding" usually means that there is an
   incorrect extra ip address in /etc/hosts for this machine. Remove the
   incorrect address( this usually happens when you change the tcp/ip
   address). Here's an example of what such a /etc/hosts file would look

#      @(#)hosts,v 6.1 1993/08/21 02:17:48 stevea Exp - STREAMware TCP/IP  sour
#      SCCS IDENTIFICATION       localhost       scobox       scobox

   The machine's IP address has been changed, but the old entry is still
   present. Remove it.
   The portmapper is used by NFS, so you could also disable NFS startup
   by commenting it out of /etc/tcp.
   [Table of Contents]
How can I make a device that will print to a network printer?

   First, are you really sure you need to do this? Only very lame
   software can't handle a spooled printer. However, if you must:
   The basic concept is to create a named pipe. For example, you might do

mknod /dev/myfakenetprint p

   That creates a "device" that your application can print to. Use
   "chmod" as necessary to give it whatever permissions you need (666 if
   everyone needs to use it).
   Now you need something that runs all the time in background. It's a
   shell script (see New to Unix if you don't know how to make a shell
   script) and it needs to start automatically whenever the machine is
   rebooted (see Automating Program Startup). This script assumes that
   your network printer already exists in the spooler:

while true
cat /dev/myfakenetprint | lp -dmyrealnetprinter

   You could also use hpnpf or netcat (see Network Printing ) directly:
while true
cat /dev/myfakenetprint | netcat -h printername -p 3001

   These work because the "cat" will hang until something (your
   application) writes data to the named pipe. The "lp" won't complete
   until cat is done reading, which will be when your application closes
   its writing. Although it might look like this ties up your cpu, it
   doesn't- the cat sleeps while it hangs, and so does lp or netcat:
   there's nothing going on until you write data to the named pipe.
   [Table of Contents]
Archive-name: Questions and Answers about Serial Communications and UUCP - SCO Technical FAQ 5/5
Posting-Frequency: Monthly (mid month)
Last-modified: Sep 16
   Questions and Answers about Serial Communications and UUCP - SCO Technical FAQ

   FAQ Starting Page
   These FAQS were developed and maintained for years by (Stephen M. Dunn). Steve no longer has the time to
   maintain them, and has asked me to take them over. Please remember the
   debt all of us owe to Steve for his efforts- I myself spent many hours
   learning from these very documents, and I'm sure many of us can say
   similar things.
   Because Steve has not been able to maintain these for a while now,
   some of the information herein is outdated. I am working to correct
   that, but it's a lot to catch up on, so if you spot something, please
   let me know. For the moment, I'm just marking some of it as probably
   being useless; as I have time, I'll check further to be certain before
   I remove anything.
   Suggestion: Use my Search to find what you are looking for.
My serial connections are losing characters

   Here are three possibilities. First, check the NCLIST kernel
   parameter. This governs how many CLIST structures are allocated; these
   are used to buffer input and output. If this is too low, then at times
   of high serial I/O demands, your system will run out of CLIST
   structures and start discarding characters. Note that there is a limit
   as to how many CLIST structures may be allocated to an individual
   process, regardless of how many are available systemwide. This is done
   to prevent one misbehaving program from monopolizing all of the CLIST
   structures. Look for the tunable parameter TTHOG (only available in
   newer Unix systems), which controls this limit.
   The next possibility is that you may have an old UART (8250 or 16450).
   See the next answer for more info.
   And you may also have flow control problems. The devices at either end
   of a serial cable must agree on what flow control is being used or
   else you can end up with data loss, unexplained pauses in the data
   stream, etc. See the man pages for stty and termio for more
   information on the available settings.
   [Table of Contents]
What do the terms UART, 8250, 16450 and 16550 mean?

   UART means Universal Asynchronous Receiver/Transmitter. This is a chip
   which receives and transmits data serially; each serial port you have
   will use one, though it is possible that several may be integrated
   into one chip.
   8250, 16450 and 16550 are all common types of UARTs. The 8250 is an
   old chip which cannot run at high speed. The 16450 is similar to the
   8250 except that it supports data communications at higher speeds.
   Both of these chips generate an interrupt for every character that is
   sent or received, which basically tells the CPU either "Here is some
   data for you" or "Feed me!" This is all very well, except that at high
   speed, the number of interrupts (nearly 4000 per port per second at 38
   400 bps) can overwhelm a CPU, bringing system performance way down.
   Also, if the CPU is busy servicing another interrupt at the time, the
   serial port's interrupt may not be serviced in time, which will cause
   a character to be lost.
   The 16550 is pin-compatible with the 16450 and, by default, runs in
   16450 mode. This makes it compatible with software which is not
   16550-aware. If your software is 16550-aware, it can turn on a special
   mode in which the 16550 buffers all data with 16-byte internal
   buffers. This not only allows the CPU to deal with far more bytes at a
   time, increasing efficiency, but also means that if the CPU can't
   service the interrupt before the next character comes in, there's
   still space in the buffer for it.
   16550 support was introduced in Xenix 2.3.4, ODT 1.1 and Unix 3.2.2.
   If you have these, or later, versions, your operating system will
   automatically detect 16550-equipped ports and will enable their
   buffering. A third-party serial driver called FAS includes 16550
   awareness in its feature set; you may wish to investigate this as
   well. FAS can be found at
   Note that the above is not really applicable to intelligent multiport
   serial cards. While these cards may well use 16550s, it is the
   processor on the serial card which is responsible for dealing with the
   serial ports it controls, and the main CPU has nothing to do with the
   [Table of Contents]
How do I adjust my 16550's trigger level?

   The answer is different for Unix and Xenix, but much of the
   information is the same, so it's been grouped together here. We will
   deal with the common information first, and the specific details for
   Xenix and Unix.
   By default, Xenix and Unix set the 16550's trigger level to 14. This
   means that once fourteen characters have been received, the 16550 will
   generate an interrupt (it will also generate an interrupt if the
   buffer is not full but serial data flow has stopped, so the system
   doesn't always have to wait until the trigger level is reached). This
   give the system two character times in which to begin to clear the
   buffer; at high speed on a highly loaded system, this may not be
   enough, and you may still lose characters even though you have a
   16550. On the other hand, this value should generally be set as high
   as possible to reduce the number of interrupts generated; servicing an
   interrupt is quite costly in terms of CPU time.
   There is an array in the kernel called sio_fifoctl[]. It is a 16-byte
   array with control values for different minor numbers. To find which
   array element will be used for a particular serial port, AND the minor
   number of the port with 0x0F (for example, /dev/tty2A has a minor
   number of 136 and /dev/tty2a of 8; either one ANDed with 0x0F yields
   8, so sio_fifoctl[8] controls this port).
   There are four different values you may wish to use for the entries in
   sio_fifoctl[]. A value of 0x0F sets the trigger value to 1; 0x4F sets
   it to 4; 0x8F sets it to 8; 0xCF sets it to 14 (these values are
   determined by the 16550 itself, not by SCO, and other values will not
   set the trigger level to intermediate values).
   In Xenix, this parameter is set by patching the disk image of the
   kernel (/xenix) using adb (the info on how to find adb is elsewhere in
   this FAQ). The following is a sample adb session to change the trigger
   level of /dev/tty2A to 8 from 14 (the line numbers in parentheses are
   for the explanation below); the asterisks are adb's prompt and should
   not be typed in:
    1. cp /xenix /
    2. adb -w /xenix -
    3. * sio_fifoctl+8/x
    4. sio_fifoctl+0x8: 0xcfcf
    5. * sio_fifoctl+0x8/w 0xcf8f
    6. sio_fifoctl+0x8: 0xcfcf= 0xcf8f
    7. * $q
   Line 1 makes a backup, and line 2 runs adb in write mode. Line 3 tells
   adb to print the current value of sio_fifoctl[8]. Line 4 is adb's
   reply, which includes two bytes from this array (the rightmost one is
   the value for sio_fifoctl[8], and the leftmost is for sio_fifoctl[9]).
   You must look at these carefully, as one half will have to be changed
   while the other will have to be left alone. In line 5, we write 0xCF8F
   into this location; note that the value for sio_fifoctl[9] is left
   unchanged at 0xCF. Line 6 is adb's reply giving the old and new
   values. Line 7 quits adb.
   For Unix, there is a table at the end of the text file
   /etc/conf/pack.d/sio/space.c which gives the same array. It is
   formatted in the same manner (to find the appropriate value, AND the
   minor device number with 0x0F).
   If you run Unix, check the man page for the sar command to see if you
   have the -g option to check for serial I/O overruns. If so, try
   running it. If you see overruns, this indicates that your trigger
   level is set too high and the system doesn't have adequate time to
   service the 16550. The cure is to turn the trigger level down one
   notch and try again.
   The information for Xenix in this answer is taken from the
   comp.unix.xenix.sco FAQ, maintained by Chip Rosenthal. The copyright
   for that document reads:
   This collection is Copyright 1992-1994, Unicom Systems Development,
   Inc. All rights reserved. Permission granted to reproduce and
   distribute this document provided this notice remains intact and any
   changes to the document are clearly marked. We have tried to review
   all information, but cannot guarantee it for any particular purpose.
   We do not offer any warranties or representations, nor do we accept
   any liability for any damage resulting from the use or misuse of
   information or procedures in this document. 
   [Table of Contents]
I can transfer small files via UUCP but large files won't go

I can transfer small files via UUCP but large ones go really slowly

   This may indicate a flow control problem. uucico, the program that
   actually performs UUCP transfers, turns off all hardware and software
   flow control on the port it is using (prior to 3.2v4.0, which allows
   you to specify what it should use). If your modem's buffers are too
   small, then the stream of data involved in a large file transfer may
   overflow them, causing transmission errors. This may just cause your
   throughput to go way down, or it may result in a total inability to
   transfer larger files. Run uucico with debugging (you may find
   /usr/lib/uucp/uutry to be useful) and watch for "alarm" messages. If
   you see these, it's an indication that some characters are likely
   being dropped during transmission.
   If you are using a serial port on a multiport serial card such as one
   from Equinox or Digi, your board may have shipped with a utility that
   lets you permanently set flow control on your port. Another
   alternative is to reduce uucico's window size.
   Under 3.2v4.0, uucico does not turn off flow control; it is left at
   whatever setting the dialer used. If you are using a compiled dialer
   and have the source and the development system, you can write in
   whatever stty settings you desire. Under 3.2v4.1, if you are using
   atdialer, you can specify stty settings in /etc/default/atdial*. Note
   that it has been reported that cu, even under 3.2v4.x, turns on
   XON/XOFF flow control and, in doing so, disables hardware flow
   In 3.2v4.x, a new stty setting has been added to perform bidirectional
   RTS/CTS flow control. This is CRTSFL. CTSFLOW and RTSFLOW do not
   perform proper bidirectional flow control; they allow the modem to
   signal the computer to stop sending, but not vice versa. Depending on
   what modem you have, you may need CRTSFL if your system can't accept
   characters as quickly as your modem can produce them.
   [Table of Contents]
How do I get better UUCP throughput?

   You may or may not be able to. Here are some rules of thumb which may
   or may apply to your situation:
   If you and the remote site both use Telebit modems, enable UUCP
   spoofing. This enables the modems to maintain the UUCP protocol
   between them, and means that your CPU's response time to individual
   UUCP packets is not as critical. Some sites can achieve higher
   throughput with a Telebit link than with a direct connection at the
   same baud rate.
   If you and the remote site are both running versions of UUCP which
   allow you to specify different protocols (SCO Unix 3.2v4.0 and above,
   for example), look through your release notes to find the
   highest-performing protocol that's applicable to your situation. For
   example, the standard g protocol has its own error detection and
   correction logic. If you are running over a guaranteed error-free
   link, this is unnecessary overhead, and eliminating it by selecting a
   protocol that relies on an error-free link can speed up transfers. Be
   careful that you don't specify such a protocol for a non-error-free
   link, or else your transmissions will occasionally be corrupted. Note
   that just because you are using error-correcting modems does not
   guarantee that your data will be error-free; there is a possibility of
   lost characters and flow control problems in the serial ports at both
   ends of the connection. While the link between the modems may well be
   error-free, the end-to-end link from one uucico to another may not.
   You should usually use g or G for modem links, and reserve t, e, f,
   etc. for network connections.
   If you are running over a link that uses MNP, V.42 or V.42bis, set
   your window size as high as possible to ensure that the modems have as
   much data to work with as possible. For further tips on high-speed
   modems, see the section on maximizing serial throughput. For
   information on changing uucico's window size, see below.
   If the site with which you are communicating sometimes drops packets,
   try adjusting your packet delay to a lower number. If you are
   operating over a link with high latency (i.e. it takes a long time for
   a packet to get from one site to the other - an example would be a
   satellite link), you may need to increase your packet delay. For more
   details, see below.
   See the note below on how to get the UUCP Internals FAQ.
   [Table of Contents]
How do I change uucico's window size?

   For OpenServer Release 5, see the man page for Configuration. For
   earlier versions, read on.
   You need to have adb or _fst to do this. See the information on
   getting these, which can be found in section 1. First, make a backup
   copy of /usr/lib/uucp/uucico! This is very important. Also, note its
   ownership and permissions. To change the window size to 7, run the
   following command from the Bourne shell:

adb -w /usr/lib/uucp/uucico - << EOF
_windows/w 7

   When you have done this, reset the ownership and permissions to what
   they were originally; this process will change them on you.
   Note that specifying a window size greater than seven may break
   uucico, as the g protocol is designed for a window size of no more
   than seven. Also, the documentation and/or scopatches that ship with
   some SCO products list the second line of the above as "%d". This, at
   least on the copy of adb I have, will fail; $d is correct. If you are
   using Unix 3.2v4, leave the underscore off the symbol name.
   On Xenix 2.3.4, you may be tempted to use the scopatch command to make
   this change. Don't bother; there are at least three bugs in the short
   script which does this work, and it's just as easy to do it manually
   as it is to fix the script.
   [Table of Contents]
I increased my window size but nothing changed

   When UUCP is negotiating a connection, each side will tell the other
   what window size to use when sending. Therefore, if your window size
   is 7 and the remote uses 3, you will be sending files using a window
   size of 3, but the other side may send with a window size of up to 7.
   Note that the UUCP on the other side may not support the window size
   you specify, and may send with a smaller window than you requested.
   While this should not cause problems, it may provide lower performance
   than you'd like.
   If your connection does not have data compression, error correction,
   or long transmission delays, and the two sites involved have
   sufficient CPU power to respond quickly to incoming packets, a window
   size of 2 or 3 should be sufficient to achieve streaming data flow. In
   this case, a larger window size will not provide any benefit.
   If you have a Telebit modem, see the Telebit notes below.
   [Table of Contents]
I increased my window size and UUCP broke!

   If your modem, or the modem on a remote site, has small data buffers,
   a large window size may cause the modem's buffers to overrun. If the
   site that broke polls your system, you may wish to create a separate
   copy of uucico with a smaller window size, and specify it as the login
   shell in /etc/passwd. If you are the polling site, you may have to
   restore your original uucico. Alternatively, you could try a window
   size of 4, then 5, then 6, then 7, and see at what point UUCP stops
   working. You will then know the maximum window size you can use. You
   may also wish to ask the sysadmin at the remote site if there is
   anything they can do, such as forcing flow control to be used on their
   modem, that may remedy the problem. You may, however, have no choice
   but to return to using a window size of 3. If you have a Telebit
   modem, see the notes below relating to Telebit modems.
   [Table of Contents]
UUCP frequently has to resend packets

   If you are using a modem with error correction and/or data
   compression, or if you are making a long-distance connection, there
   are delays inherent in your connection which may cause UUCP to timeout
   and resend packets. You may need to increase the packet timeout.
   See also the section above on problems in which UUCP can transfer
   small files but not larger ones.
   [Table of Contents]
How do I change uucico's packet timeout?

   For OpenServer Release 5, see the man page for Configuration. For
   earlier versions, read on.
   This is very similar to changing the window size; once again, you will
   need to have a copy of adb, and you must first make a backup copy of
   uucico. Then run the following Bourne shell command:

adb -w /usr/lib/uucp/uucico - << EOF
_pktime/w 5

   Replace 5 with the desired number of seconds. Note that you should set
   this parameter to the smallest value that works reliably. If you
   specify too large a value, it will reduce throughput if you encounter
   a bad line or other conditions that require packets to be resent. If
   you are running Unix 3.2v4, leave the underscore out of the symbol.
   Once again, restore the permissions and ownership once you're done.
   [Table of Contents]
What special considerations are there regarding my Telebit modem?

   If you are using Telebit UUCP spoofing (S111=30), the modem spoofing
   firmware will only negotiate a 3-window connection, so changing the
   window size to 7 will not do anything for spoofed connections. It
   will, however, be effective for non-spoofed connections (i.e. if you
   connect to a site which is not using a Telebit modem).
   Some people have reported problems with Telebit modems and UUCP-g
   spoofing when they change their window and/or packet sizes.
   Apparently, Telebits can handle requests for increased window sizes
   without error (though they will only use a maximum window size of 3),
   but will not work correctly with large packets (probably above the SCO
   default of 64 bytes).
   There is a bug in version LA 5.00W of the Telebit Worldblazer firmware
   that causes uucico to fail in startup when the answering uucico is set
   for windows=7.
   [Table of Contents]
What are all the V.something codes, MNP, HST, etc.?

   Here are the most common data modem signalling standards. Note that
   the descriptions are not complete technical descriptions, and only
   cover the major feature of the standard (i.e. no discussion is made of
   fallback data rates etc.)
     * Bell 103 - North American 0-300 bps
     * Bell 212A - North American 1200 bps
     * V.22 - International 1200 bps; not generally used in North America
     * V.22bis - 2400 bps
     * V.32 - 4800 & 9600 bps
     * V.32bis - 4800 - 14 400 bps
     * V.32terbo - Vendor standard (no formal recognition), 16.8 & 19.2
     * V.FC - Vendor standard (no formal recognition), up to 28.8 kbps
     * V.34 - International standard, up to 28.8 kbps; this has been
       extended to 33.6 kbps
     * HST - USRobotics' proprietary High-Speed Transfer, 9600 - 16 800
     * PEP - Telebit's proprietary standard; also Turbo PEP
     * X2 - USRobotics' asymmetrical high-speed modulation; up to 56 kbps
       downstream (limited to 53.3 kbps by legislation), V.34 upstream.
     * K56flex - same idea as X2, different implementation
   There are also numerous standard for error correction and data
   transmission. MNP (Microcom Networking Protocol) is a family of
   protocols with various levels. MNP levels 1 through 4 denote error
   correction schemes of increasing sophistication. MNP level 4 is the
   most common MNP error correction level; while there are higher levels,
   they are not terribly widespread. You may never see your modem report
   an MNP level 4 connection if you have data compression enabled; it
   will report level 5 instead. MNP level 5 is usually considered a 2:1
   compressor, meaning that it will generally compress your data by up to
   a factor of 2 (though it can exceed this on some data and not reach it
   on other data). Note that it does not check to ensure that it can
   actually compress the data; if you send precompressed data through it,
   it will actually increase the amount of data which must be transferred
   between modems, thereby decreasing throughput.
   V.42 is another error correction standard; unlike MNP, it is
   non-proprietary. Its primary error-control protocol is called LAP-M.
   It also includes a provision for falling back to MNP level 4 error
   correction should the remote modem not support V.42. V.42bis is the
   corresponding data compression standard. It is both more efficient
   than MNP level 5, providing up to a 4:1 rate (even higher on
   particularly repetitive data), and more intelligent, in that it can
   recognize whether or not it can compress data and send the data
   uncompressed if this makes the most sense.
   For further information on modems, see the newsgroup comp.dcom.modems.
   [Table of Contents]
How do I maximize serial throughput?

   This answer assumes that you have an error-correcting and/or
   data-compressing modem. The rule of thumb here is to feed data to the
   modem as fast as you can. The more data it has to work with, the more
   efficiently it can compress it. Not only that, but there is a
   more-or-less fixed overhead involved in bundling data into packets,
   which is how the modems transmit it, so when error correction and/or
   data compression is in use, you can reduce this overhead to a minimum
   by ensuring that the modem has as much data as possible to put into
   each packet. The usual rule of thumb is to feed the modem four times
   faster than the fastest connection rate it supports. If you have a
   V.32 modem, which supports connections of up to 9600 bps, you should
   communicate with it at 38 400 bps (assuming your hardware supports
   this rate). If you are using error correction but not data
   compression, the next speed up (19 200 bps, in this case) is generally
   The modem will have an internal data buffer of some size; it could be
   as large as a couple of kilobytes on better modems. If you are sending
   it data faster than it can transmit it (which you should be), this
   buffer will fill up over time. You will need to have handshaking
   between the modem and the computer so that the modem can signal to the
   computer to stop sending when the buffer is nearly full, and to start
   sending again once there is room in the buffer. This can be done in
   software (usually using the ASCII XON and XOFF characters), or in
   hardware (usually using the RS-232 CTS and RTS lines). The use of
   software handshaking requires less wires between the computer and the
   modem, but will interfere with the transmission of binary data. The
   use of hardware handshaking requires additional wiring, but will not
   interfere with binary data. There are advocates of both methods; I
   personally prefer hardware handshaking. Whichever method you choose,
   you must make sure that you configure both the modem and the computer
   (via stty settings) to use the same protocol.
   [Table of Contents]
My data-compressing modem doesn't work much faster than my old modem

   There are a couple of possible reasons for this. Firstly, you may be
   transferring data that has already been compressed and is therefore
   not compressible (compressed news batches, for example). If your modem
   connects to the remote site using V.42bis data compression, this will
   not adversely affect throughput. If, however, you are using an MNP
   level 5 connection, you will actually lose throughput when sending
   compressed data. If the majority of your transfers are already
   compressed, you should disable MNP level 5 data compression. Note that
   using MNP level 3 or 4 error correction, or V.42 error correction,
   without any compression will increase throughput regardless of the
   type of data being transmitted.
   Also, due to the way data compression and error correction in modems
   work, there are delays involved while the two modems agree on whether
   or not each packet of data was received correctly. If possible, you
   and the remote site should try to increase uucico's window size; this
   will cause more data to be transmitted at once, which will not only
   improve the efficiency of your modem's data compression, but will also
   often mean that the response to a previous packet arrives before the
   window has expired. I'm afraid a complete discussion of packetization
   and sliding window protocols is beyond the scope of this FAQ; just
   trust me on this one if you don't quite follow me. Further discussion
   can sometimes be found in the newsgroup comp.mail.uucp.
   [Table of Contents]
A BSD-based machine can't connect to mine via UUCP

   BSD-based UUCP sends data with even parity; SCO expects no parity. Add
   "" P_ZERO to the chat script in the BSD machine's Systems or L.sys
   file. For example:
xnxbox Any uucp 19200 5553333 "" P_ZERO "" \r in:--in: nuucp

   [Table of Contents]
Where can I get more information on UUCP protocols?

   There is a FAQ posted to the news group comp.mail.uucp which goes into
   a good deal of detail on the format of UUCP files, the handshake
   process at the start of a connection, what some of the debugging
   output from uucico -x? means, and the internals of numerous UUCP
   protocols including the common g protocol and several others.
   If you do not get this group, you can find the FAQ at
   ls_Frequently_Asked_Questions. If you do not have anonymous ftp
   access, send email to; include the words
   "help" and "index" in separate lines in the body of your message.
   [Table of Contents]
I edited my gettydefs and things broke

   You can check gettydefs using /etc/getty -c /etc/gettydefs; this
   command will print out everything you could possibly want to know, and
   then some. Common mistakes include not leaving a blank line between
   entries or having a cycle of settings but forgetting to close the loop
   (e.g. if 1 fails, use 2; if 2 fails, use 3; if 3 fails, you forgot to
   tell it to go back to 1).
   [Table of Contents]
I can't get shared dial-in and dial-out working

   Here are a few things to keep in mind. Under Unix, the entries in
   /etc/inittab and /usr/lib/uucp/Devices must match exactly; if one says
   "ttyi3" while the other says "/dev/ttyi3", getty won't consider them
   to be the same port, and your modem will not be sent the undialer
   Serial ports to be used by UUCP (or even just initialized with an
   undialer) should generally be owned by user uucp and group uucp. If
   you set it this way but it keeps being put back to something else,
   chances are you're suffering from the problem mentioned above.
   If you have several entries in /usr/lib/uucp/Devices for a port
   (specifying different dialers for different speeds or whatever), only
   the first one will actually be used to reset the port. Make sure the
   first one listed is the one you want - that's usually marked ACU, but
   local customs may vary.
   [Table of Contents]
What are some common settings for my modem?

   For the real answers, read your modem's manual. If you want to discuss
   modems, see comp.dcom.modems. Having said that, here are some common
   setup strings for various features on many modems; see your manual to
   determine which one(s) apply to your modem. Note that not all modems
   will accept the following commands; even the manual for one modem is
   too large to fit, let alone all possible modems.
     * Locked DTE rate - this causes your modem to always talk to your
       serial port at the same rate, regardless of the data transfer rate
       between modems. Try AT\J0, AT&Qn (n is a number which depends on
       other settings as well), (Multitech) AT$SB38400 or (USRobotics)
     * Hardware flow control - this uses out-of-band signalling on the
       RTS and CTS lines to perform flow control and will not interfere
       with the transmission of binary data, as software flow control
       will. Try AT&K3 or AT&E4.
     * Software flow control - particularly on interactive (cu)
       connections, you may wish to use software flow control in some
       cases. This is usually done with the same command as hardware flow
       control, but with a different number (e.g. AT&K4). One
       disadvantage is that if you get garbage characters (due to line
       noise, modem disconnection, etc.), you will sometimes get a flow
       control character as part of the garbage; the system doesn't know
       it's garbage and so it may appear to hang the port.
     * Correct use of carrier detect - the DCD line is used to indicate
       to the computer that the modem has established carrier. This
       setting is almost universally done with AT&C1.
     * Error control - this feature, if negotiated between modems, causes
       the modems to take care of retransmitting data when errors crop up
       on the phone line. Try AT&Qn (again, n depends on other settings),
       AT\Nn (ditto), or AT&E1. See the discussion elsewhere in this FAQ
       to help determine what, if any, error control you should use.
       Generally, though not always, you will want to enable all error
       control methods your modem supports, in order to be able to
       negotiate connections with other modems, but may need adjustment
       in some circumstances.
     * Data compression - this feature, if negotiated between modems,
       causes the modems to attempt to compress the data before sending,
       improving throughput. Try AT&Qn (n depends on other settings) and
       AT%C1; some modems also use registers such as S36 to fine-tune
       this. See the discussion elsewhere in this FAQ for more
       information on when you might or might not want to use data
     * Correct use of DTR - the DTR line, when dropped by the computer,
       should cause the modem to hang up (and, according to some
       opinions, reset entirely). This feature is almost universally done
       with AT&Dn, but the supported values of n may vary from modem to
       modem. Try AT&D2 to hang up and AT&D3 to hang up and reset.
     * Writing settings - Two cautions first. First, you do NOT want to
       do this every time you initialize the modem. The EEPROMs used in
       most modems to store this information have a lifetime of something
       like 10 000 writes. At 30 reinitializations a day, you'll burn out
       your EEPROM in around a year. Second, if you use this to do the
       initial setup of the modem, document your settings somewhere so
       that if your modem does die, you'll have the settings you used
       somewhere (I'd recommend in a comment in your
       /usr/lib/uucp/Dialers file). See AT&W; some modems have several
       settings available, written to with AT&W0, AT&W1, etc. See AT&Y on
       some modems to determine which settings are used upon reset, and
       ATZn for resetting the modem.
     * To Echo or Not To Echo - you can configure your modem to echo
       commands back, or not to echo commands back, with ATE1 and ATE0,
       respectively. You can control the sending of result messages with
       ATQ1 and ATQ0; some modems also use ATQ2 to disable result codes
       on incoming connections.
     * Enabling busy detection - ATXn controls both the range of result
       codes the modem sends (such as enabling the display of connect
       speed rather than simply CONNECT) and what phone company signals
       the modem detects (e.g. busy, dialtone). Most people use ATX4;
       check your manual for other options.
     * Auto-answer - use ATS0=n, where n is the number of rings to allow
       to pass before answering. ATS0=0 disables auto-answer. You may
       wish to disable auto-answer while calling out or at other times
       when you don't wish the modem to answer.
     * Escape code - most modems use a pause, followed by three plus
       signs, followed by a pause, as a signal from the computer that the
       modem should go into command mode while on-line. This may cause
       problems in some cases. To disable this escape sequence, use
   [Table of Contents]
Will a Winmodem work?

   No. It requires software drivers that aren't available (though SOME
   Winmodems can be made to work on Linux systems with special modules).
   Get a real modem. Preferably, get an external modem, because:
     * External modems are only a few dollars more than internal.
     * Internal modems take up a slot that you might need someday for
       something else.
     * Modems can get so confused that only shutting them off will clear
       their problem. You don't want to shut off your server when that
       happens, do you?
     * If lightning comes down your phone line (it happens) and you have
       an internal modem, your whole computer is likely to be fried. With
       an external modem, you'll lose the modem, but probably not
       anything else.
     * You can see what's going on with an external modem. You can see
       when the modem is receiving, transmitting, handshaking- much
       easier to diagnose problems.
     * You can share an external modem between multiple computers either
       manually or by an A/B box- again this facilitates testing and is
       sometimes very convenient.
     * When you upgrade your computer, swapping the modem is much easier.
     * When you finally get your cable modem, DSL line or T1 :-), you
       might actually be able to sell that external modem, but used
       internal cards are near worthless.
   [Table of Contents]
Why can't I get my dialin modem to work above 9600 baud?

   Because you need the modem speed in /etc/inittab to match the DTE rate
   that the modem is set for. If the DTE rate is fixed, the modem can
   connect with another modem at any speed. See for a full description of
   how to do this.
   [Table of Contents]
I've set the modem for 38400 in inittab, but stty shows it at some other speed

   You have a line in /usr/lib/uucp/Devices that references that modem
   line at some other speed, and the getty program is looking at that.
   See for a more detailed
   [Table of Contents]

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

Part1 - Part2 - Part3 - Part4 - Part5

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer: (Tony Lawrence)

Last Update March 27 2014 @ 02:12 PM