I got it clear now.
But I have thought of another way to relate both sides: TSN.
Other than the table indexed by [spt,dpt,vtag] from where we look for
known "half associations" we can have a table indexed by
(spt,dpt,highest_tsn_seen_so_far).
If we find an entry in that table that is equal to the
cummulative_tsn_ack of a sack's half association, its very unlikelly
that we get anything but the right other half.
I have traces where there's no way to correlate the IP of two different paths.
IP_A1->IP_B1 PT_A PT_B VTAG_AB
IP_A2->IP_B2 PT_B PT_A VTAG_BA
on the other hand for all traces I have TSN values are different (by
far) for every direction on every association.
Is there any reason why this should not work?
n 2/24/07, Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
Hi Luis,
see my comments in-line.
Best regards
Michael
On Feb 23, 2007, at 11:14 PM, Luis Ontanon wrote:
> It's heuristic, not having the setup of the association.
>
> I mantain two tables.
> pl_table conatinig a list of assocs indexed by "port_labels" a 32bit
> label out of the ports being used (low_pt << 16 | high_pt)
THis will break in scenarios where the same port is used on
both sides and on multiple associations. This is pretty common
on SIGTRAN szenarios where all sides use the registered port.
>
> and plvt_table indexed by port_label and verification_tag of one
> direction which I assume to be unique.
That is OK. Experience has shown that you can use the port number pair
and the vtag as an identifier for one direction of an association.
>
> if match in plvt_table then we got it.
>
> if match on pl_table then
> for each assoc in list
> if assoc is missing the other direction then
> we got this and add it to the plvt_table.
>
> if no assoc was found so far
> this is a new assoc add it to both tables
>
>
> I'm not sure it will always work, but so far (with the traces I have
> available) it appears to do so... at least the perl prototype against
> which I played text files derived from captures did.
>
I think what you need to do is the following:
- Identify one direction of an association by the pair of port numbers
and the v-tag.
- Add information about the addresses to it while you are going through
the trace file.
- Connect both directions based on IP-addresses. For example if you
find DATA chunk from A -> B and a SACK from B->A, the port numbers
are OK, then tie the two association directions together.
This is done (and more complex stuff) in the sctp related code
in the gtk directory.
> AFAIU, there's very little chances to have two different associations
> match... if I actually see it happening I'll start to play the
> lottery!
From what I understand this is pretty likely: You assume that there
in randomness in the port numbers. This is recommended in general but
not used in the SIGTRAN scenarios. It is pretty likely that
multiple association use all the same port number.
>
> I have still problems matching the CTSN ack to the right TSN frames
> without falling in an infinite loop but that's another story. And
> serial arithmetic makes that a hard thing to deal with.
>
> BTW, if you have captures where the counter cycles I would love to
> have them. Or else I'll have to hope that an association on the lab
> I'm working stays up long enough and does not catch me unprepared when
> it happens.Or I'll have to generate fake packets but my experience as
> a telecom troubleshooter tells me that the fact that something works
> with generated traffic does not imply it will work in the real world.
I think I can provide you with a trace. The BSD stack (which runs on
Mac OS X) has a socket option to set the Initial TSN for debugging....
>
> As per Association Restart I do not think I'll ever implement it, I'll
> treat the restarted Association as a new one (I need traces for this
> too, but this given slack time in the lab I can force it to happen).
We consider it also a new association...
>
> Luis.
>
> On 2/23/07, Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
>> Hi Lego,
>>
>> I'm wondering how you tie together both directions of an SCTP
>> association?
>>
>> Best regards
>> Michael
>>
>> On Feb 23, 2007, at 8:57 PM, lego@xxxxxxxxxxxxx wrote:
>>
>>> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?
>>> view=rev&revision=20908
>>>
>>> User: lego
>>> Date: 2007/02/23 08:57 PM
>>>
>>> Log:
>>> fix some bugs introduced in the latest releases and add
>>> value_strings for param, evt, sig and stat ids s well as "sub-
>>> parameters".
>>>
>>> Directory: /trunk/epan/dissectors/
>>> Changes Path Action
>>> +39 -33 packet-h248.c Modified
>>> +20 -14 packet-h248.h Modified
>>> +103 -39 packet-h248_3gpp.c Modified
>>> +4 -4 packet-h248_annex_c.c Modified
>>> +83 -30 packet-h248_annex_e.c Modified
>>> +23 -11 packet-h248_q1950.c Modified
>>> +486 -52 packet-sctp.c Modified
>>>
>>> Directory: /trunk/asn1/h248/
>>> Changes Path Action
>>> +36 -30 packet-h248-template.c Modified
>>> +20 -14 packet-h248-template.h Modified
>>>
>>> _______________________________________________
>>> Wireshark-commits mailing list
>>> Wireshark-commits@xxxxxxxxxxxxx
>>> http://www.wireshark.org/mailman/listinfo/wireshark-commits
>>
>>
>
>
> --
> This information is top security. When you have read it, destroy
> yourself.
> -- Marshall McLuhan
>
>
> --
> This information is top security. When you have read it, destroy
> yourself.
> -- Marshall McLuhan
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
