12 May
2024
12 May
'24
1:47 a.m.
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
13 May
13 May
11:50 a.m.
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
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
7:06 p.m.
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.
--
- Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/
========================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
7:14 p.m.
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
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
14 May
14 May
7:49 p.m.
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
13 May
13 May
7:55 p.m.
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.
--
- Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/
========================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
19 May
19 May
5:02 p.m.
New subject: Developing GSMTAP version 3 / QMI
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
20 May
20 May
2:27 p.m.
New subject: Developing GSMTAP version 3 / QMI
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
28
days inactive
37
days old
7 comments
4 participants
participants (4)
-
Alexander 'lynxis' Couzens -
Pau Espin Pedrol -
Shinjo Park -
Vadim Yanitskiy