Re: TCP and SCTP sequence analysis code

Hi Michael,

Yes, I've used it before.  My main problem with it then was that the 
zoom in/out buttons don't work for me so the graph was too large to show 
the details I was interested in.  (This was probably with GTK1 on 
Solaris though I just tried 0.99.0 on Windoze with, I think, GTK-Wimp, 
and had the same problem.)  Do the zoom buttons work for you?

Regards,
-Jeff

Michael Tuexen wrote:
> 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.)