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