Re: TCP and SCTP sequence analysis code

Hi Jeff,

I have to analyze a lot of trace files and found the graphical
stuff very helpful to find the interesting places in the trace file.
Have you tried it? If you miss a feature there, Irene can implement  
it...
if it does not take too much time.

Best regards
Michael

On May 10, 2006, at 12:09 PM, Jeff Morriss wrote:

>
> [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.)
>
>
> _______________________________________________
> Ethereal-dev mailing list
> [email protected]
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>