Newsgroups: comp.unix.sco.announce,comp.answers,news.answers
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!howland.erols.net!nntp.primenet.com!nntp.gblx.net!feeder.via.net!enews.sgi.com!coop.net!world!apl
From: [email protected] (Tony Lawrence)
Subject: comp.unix.sco Technical FAQ (4/7)
Message-ID: <[email protected]>
Approved: [email protected]
Date: Thu, 12 Oct 2000 23:31:17 GMT
Organization: http://www.aplawrence.com
Keywords: FAQ SCO Xenix Unix Frequently Asked Questions
Followup-To: comp.unix.sco.misc
Lines: 352
Xref: senator-bedfellow.mit.edu comp.unix.sco.announce:2480 comp.answers:42687 news.answers:193881

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

  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
  [email protected] (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: [email protected]
250 [email protected]... Sender ok
rcpt to: [email protected]
550 [email protected]... Relaying denied
rcpt to: [email protected]
250 [email protected]... 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]
    _________________________________________________________________
    _________________________________________________________________

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.