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
faqs.org - Internet FAQ Archives

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

( Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Cities ]
Archive-Name: comp.unix.sco Technical FAQ 4/7
Posting-Frequency: Monthly (mid month)
Last-modified: Oct 12



comp.unix.sco Technical FAQ 4/7

See reader questions & answers on this topic! - Help others by sharing your knowledge
   Questions and Answers about TCP/IP and NFS
   
   FAQ Starting Page http://aplawrence.com/SCOFAQ/index.html
   
   These FAQS were developed and maintained for years by
   steved@ussinc.com (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

   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
   functionality; it will not work for Xenix.
   
   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 (89.27.01.07) to decimal (137.39.1.7). 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
   inconfig.
   
   [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:
   
   #!/bin/sh
   # name of file with banner
   BANNER_FILE=/etc/telbanner
   # name of telnet daemon
   TELNETD=/etc/telnetd
   # 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 www.foo.com
   aaa.bbb.ccc.ddd).
   
   [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 http://aplawrence.com/Unixart/network.html 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 10.1.36.1

   would set the default route to 10.1.36.1, but that would not survive a
   reboot.
   
   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 OpenServer 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 10.1.1.3
   # it's smart enough to delete the previous default
   net default 192.168.1.2
   # routes to specific hosts
   host 192.168.1.8 10.1.1.7
   # netmasks optional
   net 192.168.1.0 10.1.1.3 255.255.255.0
   # if field 1 isn't host or net, it's ignored
   happiness 172.16.80.10 10.1.1.1
   sanjose 172.16.80.10 10.1.1.1

   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
   list
   - server will show you size of each message
   retr 1
   - first message will be displayed
   quit

   [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:

   10.1.36.5 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->Run, 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
   greater?

   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
   like:

   #      @(#)hosts,v 6.1 1993/08/21 02:17:48 stevea Exp - STREAMware TCP/IP  sour
   ce
   #      SCCS IDENTIFICATION
   127.0.0.1       localhost
   10.1.36.8       scobox scobox.fredness.com
   10.1.36.7       scobox scobox.fredness.com

   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]
     _________________________________________________________________
   
   What do "can't get passwd for local host" messages in syslog mean?

   SCO PPP will generate messages like this in syslog:
      pppd[296]: can't get passwd for local host
      pppd[296]: getppphostent: no local host id


   Evan Hunt of SCO explains: Those refer to PAP/CHAP passwords in
   /etc/pppauth--it basically just means you haven't configured SCO PPP
   to use PAP/CHAP for authentication. You can ignore them. I really
   ought to demote those messages to a lower debug level so they don't
   show up unless you ask for them. (Scribble note to self.) 
   
   [Table of Contents]
     _________________________________________________________________
   
   How do I test a smtp connection?


 $ telnet mail.somewhere.com 25
 Trying 192.168.75.194...
 Connected to smtp.somewhere.com.
 Escape character is '^]'.
 220 smtp.somewhere.net ESMTP Sendmail 8.9.3+Sun/8.9.1; Thu, 12 Oct 2000 04:39:
   40 -0700 (PDT)
 mail from: tony@aplawrence.com
 250 tony@aplawrence.com... Sender ok
 rcpt to: foobah@aplawrence.com
 550 foobah@aplawrence.com... Relaying denied
 rcpt to: foobah@somewhere.com
 250 foobah@somewhere.com... Recipient ok
 data
 354 Enter mail, end with . on a line by itself
 test
 look ma no headers!
 .
 250 HA00945 Message accepted for delivery
 quit
 221 smtp.somewhere.com closing connection


   [Table of Contents]
     _________________________________________________________________
     _________________________________________________________________

User Contributions:

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

CAPTCHA




Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7

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

Send corrections/additions to the FAQ Maintainer:
apl@world.std.com (Tony Lawrence)





Last Update March 27 2014 @ 02:12 PM