Re: [Non-intrusion Q] Is this normal FTP and TCP"underneath it" behavior?
Stef <[email protected]>
| Newsgroups | gmane.comp.security.intrusions |
|---|---|
| Message-ID | <[email protected]> |
I understood this (my explanation of client and server was more along the lines of "who is the "owner" of server (<1023) ports), but my question was about the ACK=0 in the RST sent by the "server" (client with port 20, if you will). I do not remember having seen ACK=0, except for when the numbers would "wrap around". Then - on the "client" side (server with ephemeral port) - why would it send an ACK of its own data? I guess what I am saying is that I would have expected it to ACK (perhaps again, if nothing else, and as a RST does not take seq. nb.) the server (client wirh port 20) last successful data segment?!? On Sat, 18 Sep 2004 18:05:05 -0400, Bill Royds <[email protected]> wrote: > Remember that in standard FTP (not passive with PASV), the data connection is > initiated by the server with the FTP client as listener (reversing the standard > client-server relationship). So what you are seeing is the server (as client in > the data connection) sending the reset saying it is out of synch and your client > (as server) agreeing with indication of last data received (or sent). > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Stef > Sent: Saturday, September 18, 2004 12:48 PM > To: Intrusions List (GCIA Practicals) > Subject: [Intrusions] [Non-intrusion Q] Is this normal FTP and TCP"underneath > it" behavior? > > This is a non-intrusion question, which, though, I have thought of > being worth debating with you - TCP/IP gurus. I have an odd behavior > of an FTP server-client communication, which I call "odd" because I > have not found anything in the RFCs I tried, or in Steven's book, > explaining the following: > > - in a scheduled (every hour) ftp "conversation" between a client and > a server (which conversation consists in a simple upload and download > of some files, each one taking approximately 2 minutes), every once in > a while such a session fails with the following last packets: > > server --> client packet: flags: RST, ACK=0 (! - the ACK in those RSTs > is always 0) > client --> server packet: flags: RST(!!! -as if there is a standard to > force a RST from the client, in response to a RST from server?!?) and > SEQ = "number", ACK = "number" (!! - the ACK in the client "reply" > RSTs is always equal to its own sequence number, and not related to > the SEQ of the server) > > NOTE1: the above is always happening over the data connections (never > over the control one) > > NOTE2: normal traffic ends ... well, normally: FIN --> ACK --> FIN --> ACK > > Could anyone tell me what they think of this, or point me to the place > where the above may be explained?!? > > TIA, > Stef _______________________________________________ Intrusions mailing list [email protected] http://www.dshield.org/mailman/listinfo/intrusions