Bad FTP session closing... - SGI

This is a discussion on Bad FTP session closing... - SGI ; Hello, I tried to be as expressive as possible in the title;-) and even after one hour of searching over posting.google.com didn't help. Shortly, I use a FTP client on Mac and Windows machines to upload/download stuff to/from my SGI. ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Bad FTP session closing...

  1. Bad FTP session closing...

    Hello,

    I tried to be as expressive as possible in the title;-) and even after
    one hour of searching over posting.google.com didn't help.

    Shortly, I use a FTP client on Mac and Windows machines to
    upload/download stuff to/from my SGI. Everything was doing fine up to
    recently when one of those clients badly crashed while connected (not
    doing a transfer if it matters).

    Since that event, it is impossible to log again on this account (get
    an error 530 telling me that my login/pwd are lame). All the others
    accounts are doing fine.

    It seems obvious that the server -somehow- is keeping the session
    "open" while my client is gone, dead, broke up... and don't accept a
    new connection to this account.

    Now, how can I reset this thing? I don't want to delete the account
    because a LOT of files are related to this account... Is there a
    simple solution?

    Thank you in advance!

    T

  2. Re: Bad FTP session closing...

    In article <761fbcee.0312080023.6b18a14b@posting.google.com>,
    ToTheEnd wrote:
    :Shortly, I use a FTP client on Mac and Windows machines to
    :upload/download stuff to/from my SGI. Everything was doing fine up to
    :recently when one of those clients badly crashed while connected (not
    :doing a transfer if it matters).

    :Since that event, it is impossible to log again on this account (get
    :an error 530 telling me that my login/pwd are lame). All the others
    :accounts are doing fine.

    :It seems obvious that the server -somehow- is keeping the session
    :"open" while my client is gone, dead, broke up... and don't accept a
    :new connection to this account.

    That doesn't make sense to me, unless you aren't using the SGI ftp
    daemon. The SGI ftp daemon does not prevent multiple users with the
    same account.

    All I can think of off-hand is that perhaps the passowrd on that
    account has expired.

    I suggest that you have root change the password on that account;
    I suspect you will be able to get in after that.
    --
    Most Windows users will run any old attachment you send them, so if
    you want to implicate someone you can just send them a Trojan
    -- Adam Langley

  3. Re: Bad FTP session closing...

    Walter Roberson wrote:

    > :It seems obvious that the server -somehow- is keeping the session
    > :"open" while my client is gone, dead, broke up... and don't accept a
    > :new connection to this account.
    >
    > That doesn't make sense to me, unless you aren't using the SGI ftp
    > daemon. The SGI ftp daemon does not prevent multiple users with the
    > same account.


    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!"


    Ok, ok, this would be in a perfect life... but life is not perfect.

    > All I can think of off-hand is that perhaps the passowrd on that
    > account has expired.


    No way. I set no "lease" for passwords on that machine...

    > I suggest that you have root change the password on that account;
    > I suspect you will be able to get in after that.


    I'll try, but I doubt it will fix something...

    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).

    Thanks...


  4. Re: Bad FTP session closing...

    In article ,
    ToTheEnd 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.

  5. Re: Bad FTP session closing...

    Hello Walter!!!

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

    T

    >>> Walter Roberson 09.12.2003 19:46:24 >>>

    In article ,
    ToTheEnd 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.



+ Reply to Thread