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 <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
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
