RE: Logging retransmitted pkts.

["Joe Patterson" <jpatterson () asgardgroup com>]

Actually, ethereal does this.  Looking at the thread, running ethereal with
a read filter of "tcp.analysis.retransmission" should get exactly what the
initial poster wants.  Actually, running with the read filter
"tcp.analysis.flags" is quite illuminating.  Ethereal does keep a fairly
large amount of state information (which can be its downfall, as state tends
to accumulate, and memory expands, and eventually, malloc fails).  But, I
would have to say, in addition to generally aggreeing with you that snort
isn't the right tool for this job, the ability to do this in Ethereal is
even more reason not to hack up snort to try and do it.  :)

-Joe

> -----Original Message-----
> From: snort-users-admin () lists sourceforge net
> [mailto:snort-users-admin () lists sourceforge net]On Behalf Of Matt
> Kettler
> Sent: Tuesday, February 01, 2005 12:13 PM
> To: Mike Mestnik; snort-users () lists sourceforge net
> Subject: Re: [Snort-users] Logging retransmitted pkts.
>
>
> At 09:33 PM 1/31/2005, Mike Mestnik wrote:
> > I see this as being one more field in the connection tble for the current
> > end of the window.  If we see data less then this number it's old data
> > being sent again.
>
> True.. As I said, you might be able to hack snort's stream4 to do this.
>
> However, since it has nothing to do with intrusion detection, it
> really has
> nothing to do with Snort's purpose in life. Hence, it's a waste of memory
> and CPU time for Snort to check for this, no matter how small the
> overhead.
>
> Don't get me wrong in thinking I'm staying such a patch is useless. It
> would be useful for network analysis and monitoring, but it's not
> useful to
> an IDS.
>
> I think the main reason such a tool does not exist is visible
> when you look
> at the market of existing products:
>
> I know of no sniffers other than IDS's maintain any sort of state
> table at
> all. tcpdump, etherreal, etc are stateless. Thus, plain "packet
> dump" tools
> can't do this. They are trying to be fast and easily readable,
> nothing more.
>
> Many IDS's are stateful, but are focused on a completely
> different mission
> and need to be tuned to be as fast as possible for that mission.
> Thus IDS's
> won't do this because it slightly hurts their performance and offers no
> benefit in terms of their actual purpose.
>
> I don't know of any "stateful network performance analysis"
> products, which
> is where such a tool as you describe would fit. Perhaps there is such a
> tool out there, but it's not within my knowledge.
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users