doug@ICASE.EDU (Doug Peterson) (10/20/88)
My aplogies to those who see this more than once.
Given the following configuration of Sun's (except for A) The Sun's run
Sun OS 3.5.1, and the nameserver patch kit. The nameserver appears to
work fine. We've been using it for about 6 weeks. "A" is any Internet
site.
---------------------------|~|----------------------
| |Any.site.domain
|128.102.23.51 ---------
----------- | |
| 3/180 | | A |
| | ---------
------------
|
| 192.42.142
------------------------------------------------
| | |
| | |
-------- --------- --------
| 3/50 | | 3/50 | | 3/50 |
-------- --------- --------
work1
Ftp from the 3/180 (ICASE.EDU) to A works fine. Ftp from any 3/50 to A
(in this case csab.larc.nasa.gov) is shown below.
work1% ftp csab.larc.nasa.gov
Connected to csab.larc.nasa.gov.
220 csab FTP server (Version 4.148 Mon Mar 21 10:01:27 PST 1988) ready.
Name (csab.larc.nasa.gov:doug):
Password (csab.larc.nasa.gov:doug):
331 Password required for doug.
230 User doug logged in.
ftp> ls
ftp: bind: Can't assign requested address
ftp> quit
221 Goodbye.
I'd appreciate any suggestions to help solve this problem. Mail, rlogin
et. al. appear to be working fine.
Doug Peterson
Systems Manager
ICASE
Mail Stop 132C
NASA Langley Research Center
Hampton, VA 23665-5225
(804) 865-4090
FTS: 928-4090
doug@icase.edusteve@umiacs.UMD.EDU (Steven D. Miller) (10/20/88)
You should check your ifconfigs in /etc/rc.boot to be sure they're really happening. (Best check: type b -sb at the monitor prompt, then do the stuff in rc.boot by hand, including the ifconfig.) I've seen (and reported to Sun) a problem where diskless nodes will seem to work OK if they learn their IP address purely via reverse ARP, but the address in the ifnet structure has garbage where it should have zeroes, and binding local addresses fails when that garbage gets compared to zeroes somewhere else. The ifconfig stuffs the address into the interface structure properly. I suspect that this problem is in all SunOSes up to (but possibly not including) 4.0. I'll also bet that the ifconfig is failing on the clients because of some interaction with YP and the nameserver. You might try putting the client IP addresses directly into their ifconfig lines in rc.boot and see if that helps. (Does it sound like this has happened to me before?) -Steve Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
doug@ICASE.EDU (Doug Peterson) (10/21/88)
My ftp problem is fixed. Here's the sequence of events that led to is conception. I changed my workstation net to a new Class C address, updated /etc/hosts on my server, and rebult my YP database. I made all the other required changes (I thought). However, I overlooked the /etc/hosts on all my diskless clients. (After all, they boted, rlogin, rsh, et. al. worked) No user here initiated an ftp session FROM THEIR WORKSTATION until yesterday. A few days after installing the new IP address, someone noticed that /etc/hosts on their workstation still had the old IP addresses in it. I replaced those tables with the current ones just for consistency's sake, but didn't reboot the workstations. (I use an rcp script for such things.) It turns out that ypserv (and related daemons) use an image of the YP database (on the clients, anyway), that they get when they first start up. If any of the files are changed, they don't update their image. The bizarre thing here is that the daemons on the clients get their image from the client copy of the host tables, not the YP database, but only when they start up. Thus, ftp would use the nameserver to get a connection to a remote host, but the ftp sub-command (e.g. ls) would use the CLIENT version of the data, which was apparently obtained from a different source than the ftp command itself. Is this a bug in the ftp-YP interface??? Restarting the daemons (read rebooting the workstations) fixed everything! The credit for this discovery goes to Sharon Beskenis (sdo@csab.larc.nasa.gov) a long-time friend and colleague. She talked me into trying a reboot. Thanks, Sharon!! Doug Peterson Systems Manager ICASE Mail Stop 132C NASA Langley Research Center Hampton, VA 23665-5225 (804) 865-4090 FTS: 928-4090 doug@icase.edu
ced@bcstec.uucp (Charles Derykus) (04/13/91)
We've encountered a problem ftp'ing from an RS/6000 AIX 3.1 running the 3003 update. No matter what Unix platform is the target, the login fails as though an extra carriage return were appended to the account name. A sample session is included: srloads:/u/sks6373> ftp n1 Connected to n1.ca.boeing.com. 220 n1 FTP server (IBM RT) ready. Name (n1:root): sks6373 331 Password required for sks6373. 500 'PASS ': command not understood. Login failed. ftp> The target here was an IBM/RT but other unix platforms behave identically or pretty near. Has anyone encountered this? Other than a ".netrc" file are there any workarounds? Thanks, Charles DeRykus Internet: ced@bcstec.boeing.com Boeing Computer Services UUCP: ...!uunet!bcstec!ced Renton, WA. M/S 6R-37 (206) 234-9223