LYNX-DEV Lynx hangs on FTP URLs

[Rob Puller]

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/

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