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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] 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@wireshark.org > >>> 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@wireshark.org > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > _______________________________________________ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
