Hi all,
After the OsmoDevCon 2024, I have set up a repository containing the GSMTAPv3 WIP version: https://gitea.osmocom.org/peremen/gsmtapv3
There is a Redmine ticket for GSMTAPv3: https://osmocom.org/issues/6445
Currently only the global header structure and types/subtypes are defined, and detailed explanation of what each data type stands for is still WIP. Also, GSMTAPv3 will use T16L16V dynamic metadata instead of fixed metadata structure, and the metadata definition is still in early stage.
Having a structure definition is the very begging, which will be followed by additional works to actually use the new GSMTAPv3 format (APIs, Wireshark dissector, ...). Any form of help will be much appreciated.
Best, Shinjo
Hi Sinjo,
I wonder whether we should be allocating gsmtap types for protocols which had to use alone so far. For instance in GSM I see RLC/MAC, LLC, SNDCP, etc. but those were never really necessary afaik because they always come on top of Um, which is the protocol we encapsulate with gsmtap. I understand that somebody may want to encapsulate eg LLC directly, but until there's a explicit need for it I'd perhaps avoid adding them to the list.
AFAIU "uint8_t metadata[0];" is where the T16L16V is placed?
Regards, Pau
Hi Pau,
On 13.05.2024 10:50, Pau Espin Pedrol wrote:
I wonder whether we should be allocating gsmtap types for protocols which had to use alone so far. For instance in GSM I see RLC/MAC, LLC, SNDCP, etc. but those were never really necessary afaik because they always come on top of Um, which is the protocol we encapsulate with gsmtap. I understand that somebody may want to encapsulate eg LLC directly, but until there's a explicit need for it I'd perhaps avoid adding them to the list.
I think this is for QMI tools like scat, QCSuper, or osmo-qcdiag, which can obtain raw PDUs from various protocol stack layers. Those PDUs are not always complete, e.g. you may get only the LLC alone.
Best regards, Vadim.
Hi,
Good to know those can be retrieved by QMI related tools. As mentioned I'm fine to include those if there's already a use for them planned. I just wanted to raise the general concern.
Regards, Pau
Hi Pau,
For instance in GSM I see RLC/MAC, LLC, SNDCP, etc. but those were never really necessary afaik because they always come on top of Um, which is the protocol we encapsulate with gsmtap.
What Vadim said explains my intention. I want to avoid attaching unneeded pseudo-Um header when only RLC/MAC, LLC, SNDCP, (even RR) PDUs are available.
AFAIU "uint8_t metadata[0];" is where the T16L16V is placed?
Yes, exactly.
Best, Shinjo
2024년 5월 13일 월요일 오전 10시 50분 12초 CEST에 Pau Espin Pedrol 님이 쓴 글:
Hi Sinjo,
I wonder whether we should be allocating gsmtap types for protocols which had to use alone so far. For instance in GSM I see RLC/MAC, LLC, SNDCP, etc. but those were never really necessary afaik because they always come on top of Um, which is the protocol we encapsulate with gsmtap. I understand that somebody may want to encapsulate eg LLC directly, but until there's a explicit need for it I'd perhaps avoid adding them to the list.
AFAIU "uint8_t metadata[0];" is where the T16L16V is placed?
Regards, Pau
Hi Shinjo,
thank you for working on that!
On 12.05.2024 00:47, Shinjo Park wrote:
After the OsmoDevCon 2024, I have set up a repository containing the GSMTAPv3 WIP version:https://gitea.osmocom.org/peremen/gsmtapv3
Looking at the proposed structure of the GSMTAPv3 header:
``` /*! Structure of the GSMTAP pseudo-header */ struct gsmtap_hdr_v3 { uint8_t version; uint16_t hdr_len; uint8_t res;
uint16_t type; uint16_t sub_type;
uint8_t metadata[0]; } __attribute__((packed)); ```
I suggest to re-order fields a bit, more specifically to place field 'res' before field 'hdr_len', so that the later is at least WORD-alighed (just like all the other fields).
``` /*! Structure of the GSMTAP pseudo-header */ struct gsmtap_hdr_v3 { uint8_t version; - uint16_t hdr_len; uint8_t res; + uint16_t hdr_len; ```
This way the structure would be identical to its unpacked equivalent, and, in theory, accessing those fields for storing and loading values would be faster.
http://www.catb.org/esr/structure-packing/ -- nice read about struct padding in C/C++ and manual field reordering.
Best regards, Vadim.
Hi Shinjo,
Currently only the global header structure and types/subtypes are defined, and detailed explanation of what each data type stands for is still WIP. Also, GSMTAPv3 will use T16L16V dynamic metadata instead of fixed metadata structure, and the metadata definition is still in early stage.
I would like to dump QMI (Qualcomm MSM Interface) messages. How would you dump them with GSMTAPv3?
Best, lynxis
Hi lynxis,
I can think two ways based on whether using a subtype within the QMI is required: - Use type as GSMTAPV3_TYPE_BASEBAND_DIAG and define another subtype there, for e.g. GSMTAPV3_BASEBAND_DIAG_QMI if no further subtype definition is required - Define another GSMTAPV3_TYPE_QMI in 0x00 range, and use subtypes to differentiate QMI messages if it is necessary.
Shinjo
2024년 5월 19일 일요일 오후 4시 2분 57초 CEST에 Alexander 'lynxis' Couzens 님이 쓴 글:
Hi Shinjo,
Currently only the global header structure and types/subtypes are defined, and detailed explanation of what each data type stands for is still WIP. Also, GSMTAPv3 will use T16L16V dynamic metadata instead of fixed metadata structure, and the metadata definition is still in early stage.
I would like to dump QMI (Qualcomm MSM Interface) messages. How would you dump them with GSMTAPv3?
Best, lynxis
-
Alexander 'lynxis' Couzens -
Pau Espin Pedrol -
Shinjo Park -
Vadim Yanitskiy