Re: Bad FTP session closing...

From: ToTheEnd (ToTheEnd_1_at_hotmail.com)
Date: 12/11/03 

Date: Thu, 11 Dec 2003 11:04:38 +0100

Hello Walter!!!

Thanks for the tips, you have been a great help!!!

T

>>> Walter Roberson<roberson@ibd.nrc-cnrc.gc.ca> 09.12.2003 19:46:24 >>>
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: Does OpenSSH use RCP?
    ... It's not "if I want to", it's rtfrfc: show me separate protocol ... I didn't say FTP was ugly, I said lack of another layer between ... >> One connection - one application model doesn't work, ... Same as FTP: multiple connections per session. ...
    (comp.security.unix)
  • 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: IPFW almost works now.
    ... Yes, I am the one running the FTP Daemon, and I want to access it from my ... > need to allow connections to all inbound ports above 1024. ... > Can't build data connection: ...
    (FreeBSD-Security)
  • 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)