[Snort-devel] Yet more data corruption in stream4/snort-2.0.5
elof at ...969...
Wed Dec 3 03:44:01 EST 2003
On Tue, 2 Dec 2003, Andrew Rucker Jones wrote:
> 3) One data corruption problem remains for sure, which i mentioned in
> the comments in the spp_stream4.c patch: if snort picks up a session in
> the middle, and nonzero window scales are in use, snort will not know
> that, and data corruption is certain to occur if large amounts of data
> are being transfered. As i also say in the comments, this is kind of
Yes, I have noticed this as well. It's very annoying when you have a merge
of two sessions in one alert payload.
> 2) Has anyone ever seen a case where one side of a connection
> acknowledges data that have not yet been sent? I swear that i have a
> real world capture (an e-mail to a Yahoo! address) in which the client
> sends data up to sequence number X, after which the server sends two
> ACKs right after each other: one for X, and one for X+1024 or so. Right
> after that, the client sends the next 1024 bytes. There are no
> retransmits involved. Of course, that causes data corruption, too, but
> snort can hardly be blamed for that. That entire conversation was just
> as weird as can be, i have to say.
Now, you seem to know your RFCs and TCP/IP in general, so I guess it is
not as easy as this, but given your description it could be:
If your client send a TCP packet with 1024 bytes of data, and this packet
have sequence number X, then the server will acknowledge this packet with
an ack number of X+1024.
Take a look at the three way handshake plus 1024 bytes of data:
---> SYN Seq: X Ack: 0 (nothing to ack yet)
<--- SYN ACK Seq: Y Ack: X+1 (SYN counts as 1)
---> ACK Seq: X+1 Ack: Y+1
---> PSH ACK Seq: X+1 Ack: Y+1 Data: <1024 bytes>
<--- ACK Seq: Y+1 Ack: X+1+1024
More information about the Snort-devel