Who generates answer on "Get Current Data Bearer Technology" (--wds-get-current-data-bearer-technology)? It seems to occur only with qmimux...
Aleksander Morgado
aleksandermj at chromium.org
Tue Oct 24 10:05:44 UTC 2023
Hey,
The format of the "Current" TLV is as follows in the database:
{ "name" : "Current",
"id" : "0x01",
"type" : "TLV",
"since" : "1.0",
"format" : "sequence",
"contents" : [ { "name" : "Network Type",
"format" : "guint8",
"public-format" : "QmiWdsNetworkType" },
{ "name" : "RAT Mask",
"format" : "guint32" },
{ "name" : "SO Mask",
"format" : "guint32" } ],
So both RAT mask and SO mask are 32-bit unsigned values.
> Here two answers of the error case with qmimux:
> <<<<<< type = "Current" (0x01)
> <<<<<< length = 9
> <<<<<< value = 02:20:00:00:00:00:00:00:00
> <<<<<< translated = [ network_type = '3gpp' rat_mask = '32' so_mask =
> '0' ]
>
> [/dev/cdc-wdm0] Data bearer technology (current):
> Network type: '3gpp'
> Radio Access Technology: 'lte'
The translation works in this case:
0x00000020 = 32 = LTE
> <<<<<< type = "Current" (0x01)
> <<<<<< length = 9
> <<<<<< value = 02:00:04:00:00:00:00:00:00
> <<<<<< translated = [ network_type = '3gpp' rat_mask = '1024' so_mask
> = '0' ]
>
> [/dev/cdc-wdm0] Data bearer technology (current):
> Network type: '3gpp'
> Radio Access Technology: 'none'
In this case, the translation doesn't work.
0x00000400 = 1024 = none (wrong)
We use qmi_wds_rat_3gpp_build_string_from_mask() to translate the
bitmask into a string because we expect the values to come from the
QmiWdsRat3gpp enum, which has the following values:
QMI_WDS_RAT_3GPP_NONE = 0,
QMI_WDS_RAT_3GPP_WCDMA = 1 << 0,
QMI_WDS_RAT_3GPP_GPRS = 1 << 1,
QMI_WDS_RAT_3GPP_HSDPA = 1 << 2,
QMI_WDS_RAT_3GPP_HSUPA = 1 << 3,
QMI_WDS_RAT_3GPP_EDGE = 1 << 4,
QMI_WDS_RAT_3GPP_LTE = 1 << 5,
QMI_WDS_RAT_3GPP_HSDPAPLUS = 1 << 6,
QMI_WDS_RAT_3GPP_DCHSDPAPLUS = 1 << 7,
QMI_WDS_RAT_3GPP_64QAM = 1 << 8,
QMI_WDS_RAT_3GPP_TDSCDMA = 1 << 9,
QMI_WDS_RAT_3GPP_NULL_BEARER = 1 << 15
As you can see we're missing the "1 << 10" value, which would be the
one required to translate the 0x00000400 in your result. I'd guess
this is a 5G related value.
>
> Is this something libqmi generates? Or is such an answer directly coming
> from the used modem (in this case a Quectel RM520N-GL)
>
> and therefore I must clarify with support of Quectel?
>
We need to know what that flag value is, and just add a new item in
the QmiWdsRat3gpp enum type.
--
Aleksander
More information about the libqmi-devel
mailing list