Comments in-line. Best regards Michael
On Feb 26, 2007, at 5:32 PM, Luis Ontanon wrote: > 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. You are assuming one thing: You do not see multiple association using the ame TSN range. This is true when 1. you have short captures 2. the initial TSN is selected by random The second point is true for a lot of implementations but I know of implementations which always start with TSN=0. This is fully compliant with the SCTP spec. > > 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 > Are you sure? Are you talking about two end-points A and B having port number PT_A and PT_B. So the situation should look like IP_A1->IP_B1 PT_A PT_B VTAG_AB IP_B2->IP_A2 PT_B PT_A VTAG_BA RFC 2960 states that if a packet with DATA chunks is sent from IP_A1 to IP_B1 the corresponding SACK should be sent to IP_A1. But this might not apply if both send continuously data and A uses IP_B1 as its primary and B uses A_2 as its primary path. This is valid. However, this would mean the A should send HEARTBEATS to IP_B2. and you should be able to tie both halves together by these messages. So I think the following would be appropriate: - consider triple od src port, dst port and v-tag identifying half associations. - use the addresses to typ two half associations together by looking at at INIT-ACK chunks, DATA/SACK pairs, HEARTBEAT/HEARTBEAT-ACK pairs, INIT-ACK/COOKIE pairs, COOKIE/COOKIE-ACK pairs. The pairing is based on IP-addresses. This should be a pretty good heuristic. If you are not able to tie two half associations together, you could try to use DATA/SACK paris based on TSN, as you are suggesting. But I would only do this if the above does not work out. This heuristic makes assumptions which are not covered by the RFC, but if you only us it when the rest is not working, it is better to do something which is possibly wrong, than to do nothing. > 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 _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
