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