On Wed, Dec 20, 2023, 4:32 PM John Thacker <johnthac...@gmail.com> wrote:
> > On 6 Dec 2023, at 12:08, Ariel Burbaickij <ariel.burbaic...@gmail.com> >> 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 ? >> > > > I see you filed an issue. > https://gitlab.com/wireshark/wireshark/-/issues/19544 > > 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) > It works better when there are INIT chunks present, but your sample file only has DATA chunks, as you say. John >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
