Questions and Answers about TCP/IP and NFS ****************************************** 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. ____________________________________________________________________________ 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. 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. ____________________________________________________________________________ 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. ____________________________________________________________________________ How do I get /etc/issue to print 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. ____________________________________________________________________________ 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. ____________________________________________________________________________ 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).