[Snort-users] curious packets with no Snort alert?

Matt Kettler mkettler at ...4108...
Mon Nov 19 12:57:04 EST 2001

Disclaimer: These are only semi-educated opinions. I work with TCP a lot, 
but I'm no true expert. The following is what seems to be going on, based 
on the information I have available to me, and me being only somewhat 
educated on the topic. But the advice is free, so what did you expect :)

This is a pretty weird behavior, but it seems one, or both, of your 
machines has a broken TCP stack, causing them to engage in an endless 
conversation which roughly looks like this in English:

pc: "be quiet!"
router: "I hear you"
pc: "be quiet!"
router: "I hear you"
pc: "be quiet!"
router: "I hear you"
pc: "be quiet!"

Normally a RST packet (which is what the PC is sending) indicates that the 
other end should terminate the connection and issue no further 
communication (not even an acknowledgement). However, the receiver of a RST 
segment may ignore it if the ACK field doesn't match the SEQ of the packet 

I suspect the win98 machine is the one misbehaving most, those RST packets 
do not look like they are proper since their ACK field is well ahead of the 
SEQ of the packet triggering them, and it should not be. Then again, broken 
behaviors from the win98 TCP stack are reportedly common so this is no 

However if the receiver (the router in this case) chooses to ignore a RST 
packet, it should drop it entirely. It looks like your router is just 
ignoring the RST flag, processing the packet, and issuing a fresh ACK 
packet to try to get the PC back to the correct sequence number. How they 
got out of synch in the first place is beyond me.

So the win98 box is trying to tell the router to get lost, but the RST 
segment is malformed. Thus the router ignores the malformed RST, and 
(strangely) tries to send a fresh ack.. which prompts the 98 box to try to 
RST the connection again, but it's still malformed. This appears to be 
occurring as fast as the wire allows. I wonder why RFCs specify behaviors 
when so many Microsoft implementations choose to ignore, or misinterpret them.

in depth information on reset packets can be found in the TCP RFC:


What I cannot explain is your claim that this continues with the win98 box off.

At 02:05 PM 11/16/2001, Matija Exel wrote:
>I am receiving this week blasts of apparently spoofed packets of the type 
>"TCP   1334 > 2000" and vice versa,
>at about a rate of 2000/sec!
>The packets are between:
>pcexel.ensieg.inpg.fr      and  xyplex-ensiegd.ensieg.inpg.fr
>of which the first is a PC Win98 and the second is a Xyplex9000 router 
>(who uses the 2000 port for telnet).
>The pcexel must be forged, as i see the packets when pcexel is down.
>Snort is giving no alerts and i wonder if anyone has any idea ...........?

More information about the Snort-users mailing list