Re: [Wireshark-dev] wireshark handles SCTP association indexing wrong under some circumstances -- multi-homing is wrongly reported where there is none
Hi, With what Wireshark version in this? And a (synthetic) sample capture would go a long way investigating this. Thanks, Jaap > On 6 Dec 2023, at 12:08, Ariel Burbaickij 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: > > 0x0303 from 3.3.3.3 to 4.4.4.4 > and > 0x0404 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 0x0303) > Endpoint 2 is 2.2.2.2 and 4.4.4.4 (vtag 0x0404) > > so, why does analysis fail here, where it should not ? > > Kind Regards > Ariel Burbaickij > ___ > Sent via:Wireshark-dev mailing list > 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 ___ Sent via:Wireshark-dev mailing list 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
Re: [Wireshark-dev] SCTP association analysis & selection does not work correctly
On Wed, Dec 6, 2023 at 12:15 PM Cristian Constantin via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > Hi, > > I am trying to look at all SCTP associations (lots of them) in an pcap. > However, none of the "Analyse/SCTP/..." menu options work correctly. > It shows only _one_ association whereas there are many in the pcap. > > Pls. see an attachment with a screenshot of "Analyse/SCTP/Show All...". > What happened? This used to work perfectly... > You *may* (I'm not sure) need to enable Association Indexing (in the SCTP protocol preferences). This used to be the default behavior but it was made optional for performance reasons. ___ Sent via:Wireshark-dev mailing list 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
[Wireshark-dev] SCTP association analysis & selection does not work correctly
Hi, I am trying to look at all SCTP associations (lots of them) in an pcap. However, none of the "Analyse/SCTP/..." menu options work correctly. It shows only _one_ association whereas there are many in the pcap. Pls. see an attachment with a screenshot of "Analyse/SCTP/Show All...". What happened? This used to work perfectly... Wireshark version as reported by the GUI: 3.6.2 (Git v3.6.2 packaged as 3.6.2-2) Compiled (64-bit) using GCC 11.2.0, with Qt 5.15.2, with libpcap, with POSIX capabilities (Linux), with libnl 3, with GLib 2.71.2, with zlib 1.2.11, with Lua 5.2.4, with GnuTLS 3.7.3 and PKCS #11 support, with Gcrypt 1.9.4, with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.43.0, with brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.9.12, with libsmi 0.4.8, with QtMultimedia, without automatic updates, with SpeexDSP (using system library), with Minizip. Running on Linux 6.2.0-36-generic, with 12th Gen Intel(R) Core(TM) i7-1270P (with SSE4.2), with 31754 MB of physical memory, with GLib 2.72.4, with zlib 1.2.11, with Qt 5.15.3, with libpcap 1.10.1 (with TPACKET_V3), with c-ares 1.18.1, with GnuTLS 3.7.3, with Gcrypt 1.9.4, with nghttp2 1.43.0, with brotli 1.0.9, with LZ4 1.9.3, with Zstandard 1.4.8, with libsmi 0.4.8, with light display mode, without HiDPI, with LC_TYPE=en_US.UTF-8, binary plugins supported (19 loaded). Thank you, Cristian ___ Sent via:Wireshark-dev mailing list 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
[Wireshark-dev] wireshark handles SCTP association indexing wrong under some circumstances -- multi-homing is wrongly reported where there is none
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: 0x0303 from 3.3.3.3 to 4.4.4.4 and 0x0404 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 0x0303) Endpoint 2 is 2.2.2.2 and 4.4.4.4 (vtag 0x0404) so, why does analysis fail here, where it should not ? Kind Regards Ariel Burbaickij ___ Sent via:Wireshark-dev mailing list 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
