Re: LYNX-DEV Lynx hangs on FTP URLs

[Benjamin C. W. Sittler]

On Wed, 23 Oct 1996, Rob Puller wrote:

> 
> Ok, the FTP URL hanging problem is solved.  It appears that it resulted
> from a peculiarity, but not a bug, in Lynx.
> 
> On Mon, 21 Oct 1996, Rob Puller wrote:
> 
> > Lynx hangs when I try to connect to an FTP URL.  It connects to all other
> > URLs without trouble.  It completes the login to the FTP URL, then hangs
> > until the remote FTP server times out.  Here are the last few lines of the
> > exchange as reported by "trace":
> > [snip]
> 
> On Mon, 21 Oct 1996, Klaus Weide wrote:
> 
> > > HTFTP: Opened master socket number 4
> > > HTFTP: This host is 0.0.163.134
> >                       ^^^^^^^^^^^
> > [snip]
> >
> > Is that a valid address for "This host"?
> > [snip]
> 
> I, too, thought that the 0.0.163.134 was an odd expression of an address,
> which I recognised as the domainless part of the address assigned to me by
> my Internet Service Provider (ISP).
> 
> Before I start this long-winded explanation, be advised that this problem
> is not likely to be encountered by most Lynx Users unless they operate
> "standalone" systems, i.e., systems that are not permanently connected to
> the Internet.  The problem may also be specific to CMU_OpenVMS/IP, though I
> doubt that.  It might be worth documenting somewhere, however, to prevent
> another occurance.  I'll be happy to clean this posting up (significantly
> shorten it) and integrate it into a FAQ, or the Installation guide, or
> wherever, if those of you who are assuming most of the development and
> maintenance burden will tell me where you want it.  I'll also see about
> getting this into the CMU_OpenVMS/IP FAQ.
> 
> The HTFtp module in the WWW library which Lynx uses apparently acquires the
> IP Address assigned to the network interface device by searching for
> information which is made available by the TCP/IP package.  I have no idea
> what actual mechanisms are used (it does not seem to be environmental
> variables [logicals on VMS]).
> 
> At any rate, I have a small local area network which is interfaced to an
> ethernet adapter on my VAX.  The IP Addresses of the devices on the
> ethernet are chosen by me from the reserved addresses which are not allowed
> to be used on the Internet (see RFC1918).  I connect to the Internet via a
> dialup line with modems.  Upon logging into my account on the ISP's system,
> I can initiate a SLIP connection for which the ISP issues a temporary IP
> Address for my Serial Link network interface device; thus I have two IP
> address for the two network interface devices on my machine.
> 
> LOCAL_DOMAIN is defined in userdefs.h as rsp.eng.com (hey, I had to name it
> something) and rsp.eng.com is defined to CMU_OpenVMS/IP as mapping to an
> address of 198.163.100.100.  HTFtp uses these addresses to make the
> connection to a remote FTP URL, *BUT*, after login it somehow grabs the
> address of the device through which it is communicating, which, of course,
> does not have a fully qualified domain name associated with it on my
> machine (the ISP owns the domain name associated with his address).  HTFtp
> can't pass (or accept, I don't know which) data to/from the remote FTP host
> without the network interface device being fully defined, so it hangs until
> one or the other times out.
> 
> The solution is to define the temporarily assigned IP Address to the TCP/IP
> package by including it the Name Resolver configuration file.  I give it
> the same LOCAL_DOMAIN name as the ethernet device, which I think is correct
> because both devices interface to the same machine and both addresses point
> to different networks which happen to intersect at my machine.  Of course
> this address changes each time I connect, so I have written a DCL command
> procedure that automates the whole process of dialing into the ISP,
> acquiring the IP Address, modifying the INTERNET.CONFIG and NAMRES.CONFIG
> files, defining required (but temporary) logicals, etc.  If any other Lynx
> (or CMU_OpenVMS/IP) Users want it,
> 
> SLIP_Extensions.ZIP is available from:
> 
> http://www.afn.org/~rpuller/
> 
> WARNING: Don't download this file until Version 2.4 is posted (in a day or
> two), version 2.3 doesn't incorporate the needed fixes for Lynx).  I've
> finished the code fixes, but the documentation is a bitch... which I've
> observed more often than not in the commercial packages.
> 
> Thanks to Klause Weide for redirecting me to the real problem and to Brian
> Tillman for letting me know that Lynx at least worked on one VMS/SOCKETSHR
> configuration.
> 
> Rob Puller          Consulting Engineer, Gainesville, Florida
> <address@hidden>   http://www.afn.org/~rpuller/

Actually, the message above is applicable to anyone running Lynx on a
machine which serves as a network gateway, regardless of operating system.
Basically, you need to make sure you send the right 'return address' to
the FTP PORT command. For this to work well, both of your machine's
addresses would be listed in the domain server immediately above you.
Alternatively, you could set up an FTP firewall (or an httpd firewall that
handles FTP URLs) on the machine with two network interfaces, and talk
through that. (I assume the firewall code can handle multiple interfaces.)
The particulars for different OS/driver/hardware combinations differ, and
this is an area badly in need of a FAQ.

I realize that this isn't Lynx-specific, as it affects all network
software... but I get the feeling that the target audiences may be largely
composed of the same individuals.


;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;