Re: TCP and SCTP sequence analysis code

[Resending since my first attempt died a horrible 
SMTP-server-not-relaying-for-ethereal.com death.]

Hi Michael,

I guess that's true that this goes hand-in-hand with reassembly.  :-)

In terms of finding all the packets, I've usually had 2 cases: 1) where
I'm seeing retransmissions in a single capture file and 2) where I've
got 2 capture files that might have retransmissions.  For (2) I usually
use 'mergecap' to make one file and go from there.  But (1) usually
trips me up more because, when looking at/for higher layer problems, I
tend to skip details like verifying the peer is actually sacking us in a
timely manner--so a color filter would be useful to bring the
retransmissions to my attention.

Regards,
-Jeff

Michael Tuexen wrote:
> Hi Jeff,
> 
> one of the problems is that you need all packets on the trace. Since SCTP
> supports multihoming, this might be more difficult to achieve.
> 
> It is also harder to find associations... The graphical analysis tool
> does this based on two facts:
> 1. If it has the INIT and INIT-ACK in the trace, it analyses them and
>    uses the IP-addresses (multiple), port numbers and V-Tags.
> 2. If not all addresses are available (for example, the INIT or
>    INIT-ACK has not been seen, it uses the port numbers and V-Tags
>    only. The critical point here is that you do not have all information
>    in one packet (like in the TCP case) except for the INIT-ACK.
> 
> If you want to see how this works, have a look at the code the the
> SCTP association analysis tool. It provides really nice graphics which
> we use to find retransmissions and so on. You can also filter for 
> associations.
> 
> For the experience we made, the above method 2 is very good.
> 
> A student of mine is going to implement reassembly for SCTP DATA chunks and
> also therefore also needs some way of finding associations, the first step
> will be to integrate SCTP in the conversation concept...
> 
> After that in place, doing a sequence number analysis and having a 
> tracefile
> covering all paths should be as hard as for TCP. So it is on the agenda, 
> but
> the problem is the time. In the meantime, have a look at the GUI tool. It
> really helped us to find a lot of bugs...
> 
> Best regards
> Michael
> 
> On May 4, 2006, at 9:32 AM, Jeff Morriss wrote:
> 
>>
>> So if I were to ever actually find the time to study the TCP sequence 
>> analysis code (which detects retransmissions, associates acks with the 
>> acked data, etc.) in the hopes of doing something similar in SCTP, is 
>> there anything I should know about the TCP code?  Any known 
>> deficiencies or things that could be done better?
>>
>> (Of course I'm probably kidding myself that I'll ever find the time, 
>> but I keep getting confused by retransmissions that I didn't notice 
>> were retransmissions the first N times I looked at them.)