Re: lynx-dev Why is Lynx listening on port 11xx ?

[Klaus Weide]

On Mon, 27 Nov 2000, Isaac wrote:

> What I fail to understand is why Lynx is continuing to LISTEN on my
> external interface despite the FTP transfer being long finished.
> If I make another FTP connection, the port it is listening to changes.
> 
> I don't like this at all. If it weren't for my firewall, anybody could
> just telnet in to my running Lynx and...well, I dread to think.

If you are using a firewall, I wonder why you don't use lynx in passive
mode?  There shouldn't be any listening FTP data sockets at all then.

> Does anybody know why Lynx is doing this, and more importantly, how I can
> stop it ? OTTOMH, it looks like the socket bound for a LISTEN to the
> FTP data channel is not being closed when it should be.

Lynx keeps one open FTP socket around in LISTEN state, even after having
accept()ed (and finished) a connection to that ephemeral port.  Lynx will
never read or accept from that socket again, the only thing that it may
do later to that socket is a close() - either at cleanup before exiting,
or before it prepares a *new* listening socket for the next FTP request.
So keeping that listening socket open is quite pointless.

This wastes some system resources - the ones associated with that one
socket, plus possibly some (half-open?) sockets in the listen queue
for that socket in case there ever are SYN packets (connection attempts)
for that port.  I don't see what other harm it does, since whatever
anyone may send to that listening socket won't get processed by any app.
If this (bounded) waste of socket(s) is a problem, it should be
significant mostly for multi-user systems with many lynx processes
running simultaneously.  (And I am not aware that anybody has complained
about it in the old days of shell accounts, when that kind of usage
of lynx was more common than today.)

I've made some patches to the FTP module in the past to prevent some 
socket fd leaks.  I noticed the behavior of keeping the listening
socket around then, but didn't try to do anything to prevent it -
after all it didn't seem to lead to any accumulating leak of open socket
descriptors.  And it looked like the behavior has been in lynx "forever",
i.e., as long as lynx has been using some form of the CERN-lib derived
HTFTP.c.  It seemed to be a leftover from some prehistoric version of
that file that would re-use FTP connections (never used in lynx afaik,
and against the specs for FTP URLs anyway).


   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden