qmapv5 and qmi_wwan

[Daniele Palmas]

Hi Bjørn,

Il giorno sab 30 ott 2021 alle ore 16:23 Bjørn Mork <bjorn at mork.no> ha scritto:
>
> So I have no idea how and why this broke, but I was suddenly unable to
> get anything through when I picked up the ZyXEL NR7101 with a Quectel
> RG502Q-EA again yesterday.
>
> Doing a bit more research today I snooped on the USB link and saw this
> received from the modem when pinging it from the outside:
>
> 00000000  40 01 00 54 04 00 00 00  45 00 00 54 29 4e 40 00  |@..T....E..T)N at .|
> 00000010  3a 01 be 09 94 7a fc 01  25 fd a2 d8 08 00 7b 23  |:....z..%.....{#|
> 00000020  fe ce 00 02 c6 4c 7d 61  00 00 00 00 70 8a 0b 00  |.....L}a....p...|
> 00000030  00 00 00 00 10 11 12 13  14 15 16 17 18 19 1a 1b  |................|
> 00000040  1c 1d 1e 1f 20 21 22 23  24 25 26 27 28 29 2a 2b  |.... !"#$%&'()*+|
> 00000050  2c 2d 2e 2f 30 31 32 33  34 35 36 37              |,-./01234567|
> 0000005c
>
>
> So what I see there is 4 bytes between the map header and the IP
> packet.  This makes sense when looking at include/linux/if_rmnet.h :
>
>
> struct rmnet_map_header {
>         u8 flags;                       /* MAP_CMD_FLAG, MAP_PAD_LEN_MASK */
>         u8 mux_id;
>         __be16 pkt_len;                 /* Length of packet, including pad */
> }  __aligned(1);
>
> /* rmnet_map_header flags field:
>  *  PAD_LEN:      number of pad bytes following packet data
>  *  CMD:          1 = packet contains a MAP command; 0 = packet contains data
>  *  NEXT_HEADER: 1 = packet contains V5 CSUM header 0 = no V5 CSUM header
>  */
> #define MAP_PAD_LEN_MASK                GENMASK(5, 0)
> #define MAP_NEXT_HEADER_FLAG            BIT(6)
> #define MAP_CMD_FLAG                    BIT(7)
>
>
>
> And here we have MAP_NEXT_HEADER_FLAG set.  And the header seems sane,
> although redundant.  Decoding 0x04000000 based on:
>
>
> /* MAP CSUM headers */
> struct rmnet_map_v5_csum_header {
>         u8 header_info;
>         u8 csum_info;
>         __be16 reserved;
> } __aligned(1);
>
> /* v5 header_info field
>  * NEXT_HEADER: represents whether there is any next header
>  * HEADER_TYPE: represents the type of this header
>  *
>  * csum_info field
>  * CSUM_VALID_OR_REQ:
>  * 1 = for UL, checksum computation is requested.
>  * 1 = for DL, validated the checksum and has found it valid
>  */
>
> #define MAPV5_HDRINFO_NXT_HDR_FLAG      BIT(0)
> #define MAPV5_HDRINFO_HDR_TYPE_FMASK    GENMASK(7, 1)
> #define MAPV5_CSUMINFO_VALID_FLAG       BIT(7)
>
> #define RMNET_MAP_HEADER_TYPE_CSUM_OFFLOAD 2
>
>
> results in
> - no next header
> - header type csum offload
> - csum info not valid
>
> Is this correct?

Looks like it is.

> Does this mean that I should implement some basic
> support for these dummy headers in qmi_wwan?  Or are we so ready to
> deprecate the internal qmap handling there that we should rather just
> detect this and warn about it instead?
>

If you ask me, I think it could make sense to add basic support for
this: my perception is that qmi_wwan qmap handling is still used.

Regards,
Daniele

>
>
> Bjørn