> On 6 Dec 2023, at 12:08, Ariel Burbaickij <ariel.burbaickij@xxxxxxxxx> wrote:
>
> Hello all,
>
> we have a special setup here: SS7 E1 is converted to SCTP traffic with the following basic schema (I cannot share capture itself, just in case):
> -- there are no INITs, HEARTBEATs/ACK, SACKs, just DATA chunks sent in both directions as containers then for the traffic on higher layers .
> --each linkset, of which there are many, is represented like this:
> 1.1.1.1 <-> 2.2.2.2
> 3.3.3.3 <-> 4.4.4.4
> 5.5.5.5 <-> 6.6.6.6
> etc.
> so, that one and the same IP address is never re-used for several associations and <-> means bidirectional traffic. All associations use the same port 2904 on both sides.
>
>
> vtags used per direction are last two bytes of the source IP in the least significant bytes of vtag field, so for the second association it is:
>
> 0x00000303 from 3.3.3.3 to 4.4.4.4
> and
> 0x00000404 from 4.4.4.4 to 3.3.3.3
> etc.
>
> and TSNs are verified to be accurate too.
>
> Now, upon selecting the packet from, say 3.3.3.3 to 4.4.4.4 and "Analyse this Association", we get multi-homed association reported with always larger vtag reported as part of association, so as a matter of example:
>
> Endpoint 1 is 1.1.1.1 and 3.3.3.3 (vtag 0x00000303)
> Endpoint 2 is 2.2.2.2 and 4.4.4.4 (vtag 0x00000404)
>
> so, why does analysis fail here, where it should not ?
After fixing the issues with truncated associations, I see that the way the analysis is done it won't work if the same port is used on both sides, as you mentioned and as I see in the sample.
The ports are used as keys for the association (because it accepts the possibility that the same association could be used on multiple IP addresses on one side). Also the most recently created associations are searched for first.
In your sample file, what happens is something like:
Frame 1, port 2904 vtag 0x0204 -> 2904, create association #1 with other side vtag unknown. (IP addresses are ignored)
Frame 2, port 2904 vtag 0x021c -> 2904, there's an existing association with matching ports and an unknown vtag, assume this is the other direction of #1 (it is not.)
Frame 3, port 2904 vtag 0x0202 -> 2904, doesn't match the association above because it matches neither of the vtags, create new association #2 with other side vtag unknown
Frame 4, port 2904 vtag 0x0204 -> 2904; finds association #2 first (searches from the end) with an empty vtag, assumes this is the other direction of #2, fills in other vtag as 0x204.
...
The addresses don't come into play at all.
On the second pass, Frame 1 will find association #2 before association #1 and it will have a different association index on the second pass.
The whole thing needs to be rewritten (it's quite slow anyway - it looks through the entire list of associations for each packet, and does so each dissection.)
It needs to use a map for lookups, and for your case to work needs to also consider addresses (only decide that this is the opposite side of an association if an address used in the other direction matches). That can run into problems if the reply comes back from a different IP address than the original destination, as unrelatedly is allowed to happen in GTPv1, which causes requests and replies not to be associated. (In GTPv1 the Destination Address of a response has to be the Source Address of the request, but the Source Address of the response doesn't have to be the Destination Address of the Request, except for Echos, 3GPP TS 29.060 10.1.2.2)