Re: Bad FTP session closing...

From: Walter Roberson (roberson_at_ibd.nrc-cnrc.gc.ca)
Date: 12/09/03 

Date: 9 Dec 2003 18:46:24 GMT

In article <br2u6l$2up$1@newshispeed.ch>,
ToTheEnd <ToTheEnd_1@hotmail.com> wrote:
:I believe I didn't make myself clear. i'm using the SGI ftp daemon.
:Thing is, the server doesn't allow me to get in again after the client's
:crashed. It seems that the server kept the connection alive... (sort of,
:because the connection was dead long ago). But is seems the daemon
:doesn't know it. It is like it's waiting for something that would tell
:it: "Look, the connection is finished... go to bed and make yourself
:ready for the next connection!"

No, that explanation makes no sense. First off, ftp normally runs
out of inetd.conf, which is completely accustomed to handling
multiple requests to the same port (you can have multiple ftp users
after all). You can have multiple users from the same source IP to
the same destination, so it would only distinguish by port -- and
you are going to have a different source port every time you make an
attempt.

Secondly, if it was a connection problem, it wouldn't get as far
as the 530 you report.

Thirdly, SGI's FTP daemon makes no attempt to control multiple accesses
by the same user.

:Excuse this novice question but: is there any way to stop this deamon
:and start it again??? Like this it will reset its connection(s)... (I hope).

Start with ps -fe |grep ftpd to try to locate an ftpd process.
If you find one, you can send it signals using 'kill'. But your
hypothesis of a hung connection really does not sound right to me.

If you manually ftp from the SGI machine to itself, then you
will generate an ftp daemon to handle the connection. You can locate
that session using ps; once you have it located, then you can go
in as root and use 'par' to trace its system calls; for example,

par -s -SSS -i -o /tmp/ftpd.parlog -p 87312

to trace the activity of process 87312 and write that activity
to the file /tmp/ftpd.parlog . You would then proceed with the
ftp login sequence, and after you get the 530 response, exit
the ftp session and then browse through /tmp/ftpd.parlog to figure
out what is going on. 

-- 
Inevitably, someone will flame me about this .signature.

Relevant Pages

  • Re: Bad FTP session closing...
    ... i'm using the SGI ftp daemon. ... It seems that the server kept the connection alive... ... multiple requests to the same port (you can have multiple ftp users ... SGI's FTP daemon makes no attempt to control multiple accesses ...
    (comp.sys.sgi.admin)
  • RE: Telnet/ftp problems SBS2000
    ... Please make sure your client computers are configured as both Firewall ... will find two options "Enable folder view for FTP sites" and "Use Passive ... that the control connection has been successfully established, ... (other than port 21) ...
    (microsoft.public.windows.server.sbs)
  • Re: IPSwitch, Inc. WS_FTP Server
    ... > bounce attack as well as PASV connection hijacking. ... > The FTP bounce vulnerability allows a remote attacker to cause the ... > anonymously along with any internal addresses that the FTP server has ... That means it's got to handle a PORT ...
    (Bugtraq)
  • Re: FTP question
    ... |> I have one server that has had connectivity issues this past week ... |> directed at trying yet another ftp software. ... |> or an error about the socket connection. ... |> own modem and a Linksey router using Xp 64bit system. ...
    (microsoft.public.windowsxp.network_web)
  • Re: Does OpenSSH use RCP?
    ... TCP connection can be tuned for optimal performance. ... FTP command ... And then ssh comes along and crams interactive logins, ... straightjacket, but it's a really comfy and warm straightjacket, and the world ...
    (comp.security.unix)