Hi Luis, see my comments in-line.
Best regards Michael On Feb 25, 2007, at 6:20 PM, Luis Ontanon wrote: > Yes you are right I have to re-design the matching (and grouping!) of > paths in an association. > > I did not understand from the RFC the fact that vtags were relative > just to a direction of a path and not to all the paths of one > direction in an association. As soon as I started to analyze captures Not sure what you mean... An association has two endpoints. Each endpoint has one port number and a list on IP-addresses. So assume we have endpoint A and B. So all packets from A to B will have src_port A_port and dst_port B_port. Packets from B to A have it with the port numbers exchanged. Now the V-tags come into the play. Allmost all (but all DATA and SACK related packets) packets from A to B will have one V-tag, lets say Vtag_A and all packets from B to A will have Vtag_B. Since the Vtags are selected randomly you can use as a heuristic to say, that all packets of an association from A to B are the packets with src_port A_port, dst_port B_port and V-tag A_Vtag. All packets in the other direction can be found by using the ports exchanged and the B_Vtag. The problem is to tie both things together. The only packet which has both tags is the packet containing the INIT-ACK chunk, but you can not rely on capturing it. So the only way is to record the IP-addresses and and to use that information to find the other half of the association. > with a high volume of traffic I noticed that I would be getting SACKs > coming back from a different path for the same association. > > Now my problem is in cases like one capture I have (I can't make it > public) I have 2 endpoints for each node of an association and 2 paths > in each direction of an association each with its own vtag. > > (A1->B1, A2->B2 and B1->A1, B2->A2) > > In fact Analyze->SCTP->Show All Associations sees it as 4 > associations. So this looks like 4 associations between four single homed end-points. So there is always one path. > As SACKs to an upstream TSN might come from whichever of the 2 > downstream paths I cannot just use the vtag. Using IP addresses > doesn't help either as there's no way to relate them. I'm not sure if you use the terms "association" and "path" correctly. You do not have a V-Tag per path (which is just a remote IP address), but per end-point. > > So, per my understanding I have to implement helper tables to match > the various paths of an association. The table will have the following > fileds: srcport, dstport, src_address_list, dst_address_list You need the V-tag, because it gives you one "half"-association without knowing the addresses. You need the addresses to tie both "half"associations together, which you need because you have to relate the DATA chunks to the SACK chunks. > Luis. > > P.S. > I bought my first lottery ticket ever. > > On 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 >>>>> [email protected] >>>>> 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 >>> [email protected] >>> http://www.wireshark.org/mailman/listinfo/wireshark-dev >> >> _______________________________________________ >> Wireshark-dev mailing list >> [email protected] >> 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 > [email protected] > http://www.wireshark.org/mailman/listinfo/wireshark-dev _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
