Apologies if this has already been answered somewhere, but I spent quite
a while Googling and searching the archives for an answer and found nothing.
When I start up Lynx, and go to (e.g.) www.google.com, all is fine:
> root@myhost$ netstat --tcp -alp
> Proto Recv-Q Send-Q Local Address Foreign Address State
>PID/Program name
> tcp 0 0 myhost:smtp *:* LISTEN
>663/tcpserver
If I then go to an FTP site (e.g. ftp.gnu.org), things change:
> root@myhost:~# netstat --tcp -alp
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> PID/Program name
> tcp 0 0 myhost.mydomain:1114 gnudist.gnu.or:ftp-data CLOSE
> -
> tcp 0 0 myhost.mydomain:1114 *:* LISTEN
> 706/lynx
> tcp 0 0 myhost.mydomain:1113 gnudist.gnu.org:ftp TIME_WAIT
> -
> tcp 0 0 myhost:smtp *:* LISTEN
> 663/tcpserver
And then a few minutes later, once the TIME_WAITs and CLOSEs have finished,
it looks like this:
> root@myhost:~# netstat --tcp -alp
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> PID/Program name
> tcp 0 0 myhost.mydomain:1114 *:* LISTEN
> 706/lynx
> tcp 0 0 myhost:smtp *:* LISTEN
> 663/tcpserver
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.
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.
Thanks in advance,
Isaac Wilcox
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
