Building up a connection with QMAP enabled (but qmimux in Linux Kernel not yet enabled)

Wed Aug 20 20:24:00 UTC 2025

Hello Martin,

Il giorno lun 18 ago 2025 alle ore 22:32 Martin Maurer
<martin.maurer at mmeacs.de> ha scritto:
>
> Hello Daniele,
>
> many thanks for your feedback and the link to the page about QMAP.
>
> I am currently using a Linux Kernel 6.6.23, but 6.6.52 is also possible,
>
> and today looked into a 6.12.x kernel, which I also can use on a
> different test board.
>
> When searching over all kernel switches, I found one hit "RMNET":
>
> https://www.kernelconfig.io/config_rmnet
>
> But it seems to have a dependency on Ethernet? Or at least in category
> "Ethernet"?
>

Yes, that's the right one, probably the category "ethernet" is a bit misleading.

> Can it still be used over USB? USB3 especially?
>

Yes, it is bus-agnostic, for example it works also with mhi.

> When looking into lsusb -t of my current system
>
> /:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
>      |__ Port 001: Dev 002, If 0, Class=[unknown], Driver=option, 5000M
>      |__ Port 001: Dev 002, If 1, Class=[unknown], Driver=option, 5000M
>      |__ Port 001: Dev 002, If 2, Class=[unknown], Driver=option, 5000M
>      |__ Port 001: Dev 002, If 3, Class=[unknown], Driver=option, 5000M
>      |__ Port 001: Dev 002, If 4, Class=[unknown], Driver=qmi_wwan, 5000M
>
> I see qmi_wwan is used as driver.
>

qmi_wwan takes care of the USB part, rmnet just of the QMAP protool.
QMAP netdevices are stacked on top of the qmi_wwan netdevice.

> Do I then need to disable qmi_wwan (in Kernel) and rmnet will take over instead?
> Or is there a different way? Do I need to tell the radio module to use something different?
>

The QMAP netdevices are created through netlink, you can see how this
is done in libqmi. Both ip or qmicli can be used as a high-level tool,
see command link-add.

> I think when I remember correctly, I select rmnet in radio module and get qmi_wwan???
> Is the word "rmnet" used for different modes?
> Or all the same on device side and differences are only on host side?
> Discarding one driver and using another one?
>

qmi_wwan and rmnet should be used together, since they have different roles.

> Is there perhaps also some documentation/examples about how to use rmnet, instead of "None"/QMAP/QMIMUX?

As suggested in my previous mail, it's not much different than qmimux,
just set the passthrough file
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-class-net-qmi#n62)
and create the QMAP netdevice with one of the previously mentioned
methods.

> Can you tell me if QMI commands can still be used? Or is the usage of QMI/qmicli then also obsolete?

Yes, QMI is still the management protocol for the modem.

>
> I have already python code which handles all the connection establishment,
> as well as querying a lot of info parallel/periodic to the IP connection (like reception quality,
> neighbour cells, and much more...)
> But if it is a dead horse, not sure, if it is still worth to continue...
> I don't want to use ModemManager, if not really needed or gives me advantages.

That's ok, with qmicli it's for sure possible to setup QMAP data calls.

Regards,
Daniele

>
> Many thanks!
>
> Best regards,
> Martin
>
> Am 18.08.2025 um 22:03 schrieb Daniele Palmas:
> > Hi Martin,
> >
> > Il giorno lun 18 ago 2025 alle ore 10:01 Martin Maurer
> > <martin.maurer at mmeacs.de> ha scritto:
> >> After creating a usbmon trace and letting ChatGPT-5 analyze it:
> >>
> >> Short answer: your pings stopped working because you told the modem to expect QMAP frames, but the host is still sending plain raw‑IP on wwan0. With WDA set to ul-protocol=qmap, dl-protocol=qmap, the device will drop raw‑IP uplink packets as “incorrectly received”, which matches the counter you’re seeing. On Linux, adding the 4‑byte QMAP header on TX (and stripping it on RX) only happens if you either:
> >>
> >> create a qmimux interface (kernel’s built‑in QMAP multiplexer), or
> >>
> >> put the device into pass‑through and let rmnet handle QMAP.
> >>
> >> If you enable QMAP in the modem but keep using wwan0 directly without qmimux/rmnet, uplink traffic won’t be accepted.
> >>
> > The qmi_wwan QMAP implementation is not used anymore, I suggest using
> > the rmnet module if your kernel supports that.
> >
> > If you use ModemManager the whole process will become much simpler,
> > since it takes care of all the details for you.
> >
> > When using qmicli there are a few not obvious things (e.g. setting the
> > value of the various sysfs files, changing the MTU of the parent
> > netdevice...), but if you want to go with that you can find a starting
> > point at https://paldan.altervista.org/linux-qmap-qmi_wwan-multiple-pdn-setup/
> >
> > That is a post I wrote in the past and still refers to the qmi_wwan
> > QMAP implementation. The main differences are in setting the value of
> > the passthrough file and in the rmnet netdevices creation that could
> > be done with ip.
> >
> > Hope it helps!
> >
> > Regards,
> > Daniele
> >
> >>
> >> Am 18.08.2025 um 08:35 schrieb Martin Maurer:
> >>
> >> Here is an additional note:
> >>
> >> I was missing
> >>
> >> ip route replace default dev wwan0
> >>
> >> but this does not make it going.
> >>
> >> I tried:
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# qmicli --device=/dev/cdc-wdm0 --device-open-proxy --wds-get-packet-statistics
> >> [/dev/cdc-wdm0] Connection statistics:
> >>          TX packets OK: 1
> >>          RX packets OK: 2
> >>          TX packets dropped: 0
> >>          RX packets dropped: 0
> >>          TX bytes OK: 79
> >>          RX bytes OK: 223
> >> root at test-phyboard-pollux-imx8mp-3:~# ping -4 -I wwan0 8.8.8.8
> >> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> >> ^C
> >> --- 8.8.8.8 ping statistics ---
> >> 19 packets transmitted, 0 packets received, 100% packet loss
> >> root at triorail-phyboard-pollux-imx8mp-3:~# qmicli --device=/dev/cdc-wdm0 --device-open-proxy --wds-get-packet-statistics
> >> [/dev/cdc-wdm0] Connection statistics:
> >>          TX packets OK: 1
> >>          RX packets OK: 2
> >>          TX packets dropped: 0
> >>          RX packets dropped: 0
> >>          TX bytes OK: 79
> >>          RX bytes OK: 223
> >> root at test-phyboard-pollux-imx8mp-3:~#
> >>
> >> Packet statistics does not see my sent "TX packets"...
> >>
> >> I see the outgoing packets on
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# tcpdump -i wwan0
> >> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> >> listening on wwan0, link-type RAW (Raw IP), snapshot length 262144 bytes
> >> 06:09:34.870791 IP 192.0.0.2 > dns.google: ICMP echo request, id 29726, seq 0, length 64
> >> 06:09:35.871287 IP 192.0.0.2 > dns.google: ICMP echo request, id 29726, seq 1, length 64
> >> 06:09:36.871728 IP 192.0.0.2 > dns.google: ICMP echo request, id 29726, seq 2, length 64
> >> 06:09:37.871891 IP 192.0.0.2 > dns.google: ICMP echo request, id 29726, seq 3, length 64
> >> 06:09:38.872373 IP 192.0.0.2 > dns.google: ICMP echo request, id 29726, seq 4, length 64
> >> 06:09:39.872843 IP 192.0.0.2 > dns.google: ICMP echo request, id 29726, seq 5, length 64
> >> 06:09:40.873290 IP 192.0.0.2 > dns.google: ICMP echo request, id 29726, seq 6, length 64
> >> 06:09:41.873740 IP 192.0.0.2 > dns.google: ICMP echo request, id 29726, seq 7, length 64
> >> 06:09:59.055705 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from b6:39:cb:24:ba:d2 (oui Unknown), length 318
> >> 06:11:03.278826 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from b6:39:cb:24:ba:d2 (oui Unknown), length 318
> >> 06:12:06.785606 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from b6:39:cb:24:ba:d2 (oui Unknown), length 318
> >> 06:13:10.620266 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from b6:39:cb:24:ba:d2 (oui Unknown), length 318
> >> 06:14:14.162927 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from b6:39:cb:24:ba:d2 (oui Unknown), length 318
> >> 06:15:17.190064 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from b6:39:cb:24:ba:d2 (oui Unknown), length 318
> >> 06:15:55.451557 IP 192.0.0.2 > dns.google: ICMP echo request, id 30052, seq 0, length 64
> >> 06:15:56.452021 IP 192.0.0.2 > dns.google: ICMP echo request, id 30052, seq 1, length 64
> >> 06:15:57.452453 IP 192.0.0.2 > dns.google: ICMP echo request, id 30052, seq 2, length 64
> >> 06:15:58.452888 IP 192.0.0.2 > dns.google: ICMP echo request, id 30052, seq 3, length 64
> >> 06:15:59.453035 IP 192.0.0.2 > dns.google: ICMP echo request, id 30052, seq 4, length 64
> >> 06:16:00.453468 IP 192.0.0.2 > dns.google: ICMP echo request, id 30052, seq 5, length 64
> >> 06:16:01.453912 IP 192.0.0.2 > dns.google: ICMP echo request, id 30052, seq 6, length 64
> >> 06:16:02.454560 IP 192.0.0.2 > dns.google: ICMP echo request, id 30052, seq 7, length 64
> >> 06:16:03.455017 IP 192.0.0.2 > dns.google: ICMP echo request, id 30052, seq 8, length 64
> >> 06:16:04.455342 IP 192.0.0.2 > dns.google: ICMP echo request, id 30052, seq 9, length 64
> >> ^C
> >> 24 packets captured
> >> 24 packets received by filter
> >> 0 packets dropped by kernel
> >> root at test-phyboard-pollux-imx8mp-3:~#
> >>
> >> Checking again:
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# qmicli -d /dev/cdc-wdm0 --wda-get-data-format
> >> [/dev/cdc-wdm0] Successfully got data format
> >>                     QoS flow header: no
> >>                 Link layer protocol: 'raw-ip'
> >>    Uplink data aggregation protocol: 'qmap'
> >> Downlink data aggregation protocol: 'qmap'
> >>                       NDP signature: '0'
> >> Downlink data aggregation max datagrams: '1'
> >> Downlink data aggregation max size: '8192'
> >> root at test-phyboard-pollux-imx8mp-3:~# cat /sys/class/net/wwan0/qmi/raw_ip
> >> Y
> >> root at test-phyboard-pollux-imx8mp-3:~#
> >>
> >>
> >> Do I need a call to
> >>
> >> --wds-bind-data-port
> >>
> >> ?
> >>
> >>
> >> So I assume routing of data packet to radio module is working, outgoing packets arrive at radio module, but radio module is still in some mode,
> >>
> >> where it assumes a different packet format than the host sends?
> >>
> >>
> >> Best regards,
> >>
> >> Martin
> >>
> >>
> >> Am 17.08.2025 um 21:12 schrieb Martin Maurer:
> >>
> >> Hello,
> >>
> >> due to a bug with USB3 and default settings, I am currently trying to establish a connection with QMAP enabled.
> >>
> >> (see my previous message here in this mailing list)
> >>
> >> I don't need multiple connections, one fast stable connection is enough for the moment.
> >>
> >> It looks like qmimux is not enabled in my used Linux kernel(s). I hope my current test work also without it?
> >>
> >> I can set QMAP mode, able to establish an Internet connection,
> >>
> >> but ping is not working.
> >>
> >> See here what I am doing:
> >>
> >> (I repeated some command, just to be sure, the settings are still there like I set before)
> >>
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# qmicli --version
> >>
> >> qmicli 1.36.0
> >> Copyright (C) 2012-2023 Aleksander Morgado
> >> License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
> >> This is free software: you are free to change and redistribute it.
> >> There is NO WARRANTY, to the extent permitted by law.
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~#
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# cat /sys/class/net/wwan0/qmi/raw_ip
> >> N
> >> root at test-phyboard-pollux-imx8mp-3:~# echo Y | tee /sys/class/net/wwan0/qmi/raw_ip
> >> Y
> >> tee: /sys/class/net/wwan0/qmi/raw_ip: Device or resource busy
> >> root at test-phyboard-pollux-imx8mp-3:~# ip link set wwan0 down
> >> root at test-phyboard-pollux-imx8mp-3:~# cat /sys/class/net/wwan0/qmi/raw_ip
> >> N
> >> root at test-phyboard-pollux-imx8mp-3:~# echo Y | tee /sys/class/net/wwan0/qmi/raw_ip
> >> Y
> >> root at test-phyboard-pollux-imx8mp-3:~# cat /sys/class/net/wwan0/qmi/raw_ip
> >> Y
> >> root at test-phyboard-pollux-imx8mp-3:~# ip link set wwan0 up
> >> root at test-phyboard-pollux-imx8mp-3:~# cat /sys/class/net/wwan0/qmi/raw_ip
> >> Y
> >> root at test-phyboard-pollux-imx8mp-3:~# qmicli -d /dev/cdc-wdm0 --wda-get-data-format
> >> error: couldn't create client for the 'wda' service: CID allocation failed in the CTL client: Transaction timed out
> >>
> >> => First QMI transaction seems to be always timeout out (but not relevant for my question, just doing command again...)
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# qmicli -d /dev/cdc-wdm0 --wda-get-data-format
> >> [/dev/cdc-wdm0] Successfully got data format
> >>                     QoS flow header: no
> >>                 Link layer protocol: 'raw-ip'
> >>    Uplink data aggregation protocol: 'disabled'
> >> Downlink data aggregation protocol: 'disabled'
> >>                       NDP signature: '0'
> >> Downlink data aggregation max datagrams: '0'
> >> Downlink data aggregation max size: '0'
> >> root at test-phyboard-pollux-imx8mp-3:~# qmicli -d /dev/cdc-wdm0 --wda-set-data-format="link-layer-protocol=raw-ip,ul-protocol=qmap,dl-protocol=qmap,dl-datagram-max-size=8192,ep-type=hsusb,ep-iface-number=4,ul-datagram-max-size=8192"
> >> [/dev/cdc-wdm0] Successfully set data format
> >>                          QoS flow header: no
> >>                      Link layer protocol: 'raw-ip'
> >>         Uplink data aggregation protocol: 'qmap'
> >>       Downlink data aggregation protocol: 'qmap'
> >>                            NDP signature: '0'
> >> Downlink data aggregation max datagrams: '1'
> >>       Downlink data aggregation max size: '8192'
> >>    Uplink data aggregation max datagrams: '1'
> >>         Uplink data aggregation max size: '8192'
> >> root at test-phyboard-pollux-imx8mp-3:~# qmicli -d /dev/cdc-wdm0 --wda-get-data-format
> >> [/dev/cdc-wdm0] Successfully got data format
> >>                     QoS flow header: no
> >>                 Link layer protocol: 'raw-ip'
> >>    Uplink data aggregation protocol: 'qmap'
> >> Downlink data aggregation protocol: 'qmap'
> >>                       NDP signature: '0'
> >> Downlink data aggregation max datagrams: '1'
> >> Downlink data aggregation max size: '8192'
> >>
> >>
> >> => I have set downlink and uplink parameter. They are outputted with "set", but "get" does not display "uplink". Just printing missing? Error in libqmi?
> >>
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# qmicli -d /dev/cdc-wdm0 --wda-get-data-format
> >> [/dev/cdc-wdm0] Successfully got data format
> >>                     QoS flow header: no
> >>                 Link layer protocol: 'raw-ip'
> >>    Uplink data aggregation protocol: 'qmap'
> >> Downlink data aggregation protocol: 'qmap'
> >>                       NDP signature: '0'
> >> Downlink data aggregation max datagrams: '1'
> >> Downlink data aggregation max size: '8192'
> >> root at test-phyboard-pollux-imx8mp-3:~# cat /sys/class/net/wwan0/qmi/raw_ip
> >> Y
> >> root at test-phyboard-pollux-imx8mp-3:~#
> >>
> >> Some queries just to be sure, the parameters are now like they were set...
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# ./connection_up.sh
> >> CID=15
> >> [/dev/cdc-wdm0] Network started
> >>          Packet data handle: '3800235120'
> >> [/dev/cdc-wdm0] Client ID not released:
> >>          Service: 'wds'
> >>              CID: '15'
> >>
> >>
> >> => Shell script which gets a WMD-CID, start-network, and printing some commands which could be the next commands
> >>
> >> but must be manually entered -> just for testing!
> >>
> >>
> >> rem qmicli --device=/dev/cdc-wdm0 --device-open-proxy --wds-get-current-settings
> >> rem ip link set dev wwan0 down
> >> rem ip addr add 192.0.0.2 dev wwan0
> >> rem ip link set mtu 1472 dev wwan0
> >> rem ip link set dev wwan0 up
> >> rem ping -4 -I wwan0 8.8.8.8
> >> root at test-phyboard-pollux-imx8mp-3:~# qmicli --device=/dev/cdc-wdm0 --device-open-proxy --wds-get-current-settings
> >> [/dev/cdc-wdm0] Current settings retrieved:
> >>             IP Family: IPv4
> >>          IPv4 address: 192.0.0.2
> >>      IPv4 subnet mask: 255.255.255.224
> >> IPv4 gateway address: 192.0.0.1
> >>      IPv4 primary DNS: 192.0.0.30
> >>                   MTU: 1472
> >>               Domains: none
> >>
> >> => seems to be correct, parameters like I have seen earlier
> >>
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# cat /sys/class/net/wwan0/qmi/raw_ip
> >> Y
> >>
> >> => still ok, good!
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# qmicli -d /dev/cdc-wdm0 --wda-get-data-format
> >> [/dev/cdc-wdm0] Successfully got data format
> >>                     QoS flow header: no
> >>                 Link layer protocol: 'raw-ip'
> >>    Uplink data aggregation protocol: 'qmap'
> >> Downlink data aggregation protocol: 'qmap'
> >>                       NDP signature: '0'
> >> Downlink data aggregation max datagrams: '1'
> >> Downlink data aggregation max size: '8192'
> >>
> >> => still ok
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# ip link set dev wwan0 down
> >> root at test-phyboard-pollux-imx8mp-3:~# ip addr add 192.0.0.2 dev wwan0
> >> root at test-phyboard-pollux-imx8mp-3:~# ip link set mtu 1472 dev wwan0
> >> root at test-phyboard-pollux-imx8mp-3:~# ip link set dev wwan0 up
> >> root at test-phyboard-pollux-imx8mp-3:~# ping -4 -I wwan0 8.8.8.8
> >> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> >> ^C
> >> --- 8.8.8.8 ping statistics ---
> >> 22 packets transmitted, 0 packets received, 100% packet loss
> >>
> >>
> >> => This is my current problem. Ping is not working with "qmap" enabled.
> >>
> >> Without qmap, I have an error with USB3 under certain (rare) circumstances.
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# cat /sys/class/net/wwan0/qmi/raw_ip
> >> Y
> >>
> >> => still ok
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~# ping -4 -I wwan0 8.8.8.8
> >> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> >> ^C
> >> --- 8.8.8.8 ping statistics ---
> >> 14 packets transmitted, 0 packets received, 100% packet loss
> >>
> >> => Also second try it not working
> >>
> >> root at test-phyboard-pollux-imx8mp-3:~#
> >>
> >>
> >> Is QMAP perhaps needing qmimux for sure, and I must then add qmimux1 and work over this?
> >>
> >> So wwan0 is then not working anymore when activating QMAP?
> >>
> >> As far as I remember there are different ul/dl-protocols. Is "qmap" the right one? Or do I need "qmapv5"? What is the difference?
> >>
> >> ul-protocol (disabled|tlp|qc-ncm|mbim|rndis|qmap|qmapv5), dl-protocol (disabled|tlp|qc-ncm|mbim|rndis|qmap|qmapv5)
> >>
> >> /:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
> >>      |__ Port 001: Dev 002, If 0, Class=[unknown], Driver=option, 5000M
> >>      |__ Port 001: Dev 002, If 1, Class=[unknown], Driver=option, 5000M
> >>      |__ Port 001: Dev 002, If 2, Class=[unknown], Driver=option, 5000M
> >>      |__ Port 001: Dev 002, If 3, Class=[unknown], Driver=option, 5000M
> >>      |__ Port 001: Dev 002, If 4, Class=[unknown], Driver=qmi_wwan, 5000M
> >>
> >> I use a Quectel RM520N-GL for this test. If is 4. Is ep-iface-number=4 correct? "ep" for it is I think higher like 0x07 or even 0x14???
> >>
> >> Are my used numbers (sizes and datagrams dl/up) useable for my use case? Or do I need to take different ones?
> >>
> >> Many thank!
> >>
> >> Best regards,
> >>
> >> Martin
> >>
> >>
> >>