qmapv5 and qmi_wwan

[Bjørn Mork]

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?  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?



Bjørn