EM9190 usbcomp settings

IoT Modules
6

Yes, it most certainly can. IP/PDN session multiplexing was always part of the MBIM protocol from the beginning, and it has been supported from the very first version of the Linux driver.

The userspace ABI is akward though. Not the best idea I’ve had. But it’s what we are stuck with now: MBIM IP sessions are mapped to VLANs with IDs matching the MBIM session ID. Except for session 0 of course, which by default is mapped as untagged. This is how everything just works for a single session without caring about the VLANs. But personally I find this very confusing when I use multiplexing. It is also inconvenient to use the main netdev for one of the sessions. You can’t take that interface down for example. So I added VLAN ID 4094 as an alternative mapping of MBIM session 0. If you create a subinterface with this ID then it will take over the session 0 traffic and no packets go untagged anymore.

Yes, this is much too magic. And it should have had its own userspace ABI instead of overloading VLANs this way. Too late for that.

I’ve tried to document the mapping etc here:
https://www.kernel.org/doc/html/latest/networking/cdc_mbim.html#mbim-data-channel-userspace-abi

The way I use this is typically

  1. create network devices. E.g. using MBIM sessions 0, 1 and 2:
ip link add wwan0.0 link wwan0 type vlan id 4094
ip link add wwan0.1 link wwan0 type vlan id 1
ip link add wwan0.2 link wwan0 type vlan id 2
  1. Connect the sessions to their appropriate APN:
mbimcli -p -d /dev/cdc-wdm0 --query-subscriber-ready-status --no-close
mbimcli -p -d /dev/cdc-wdm0 --attach-packet-service --no-close --no-open=42 
mbimcli -p -d /dev/cdc-wdm0 --connect=apn=myapnA,session-id=0,ip-type=ipv4v6 --no-close --no-open=42 
mbimcli -p -d /dev/cdc-wdm0 --connect=apn=myapnB,session-id=1,ip-type=ipv4v6 --no-close --no-open=42 
mbimcli -p -d /dev/cdc-wdm0 --connect=apn=myapnC,session-id=2,ip-type=ipv4v6 --no-close --no-open=42
  1. Configure the IP interfaces using the addressing info received from the connect request:
ip addr add 10.0.0.42/32 dev wwan0.0
ip addr add 2001:db8::42/64 dev wwan0.0
ip addr add 10.1.1.42/32 dev wwan0.1
ip addr add 2001:db8:1::42/64 dev wwan0.0
ip addr add 10.2.2.42/32 dev wwan0.2
ip addr add 2001:db8:2::42/64 dev wwan0.0
  1. Configure routing policies for the PDNs.
ip route add default dev wwan0.0 table 100
ip -6 route add default dev wwan0.0 table 100
ip route add default dev wwan0.1 table 101
ip -6 route add default dev wwan0.1 table 101
ip route add default dev wwan0.2 table 102
ip -6 route add default dev wwan0.2 table 102
ip rule from .... add pref 1000 lookup table 100
etc..

Yes, it’s a mess. But it’s actually simpler than using the QMI QMAP.

And you do still have access to all the powers of QMI using the EXT_QMUX MBIM service if you like. I can’t imagine Qualcomm killing that. They don’t have any replacement. You can qmicli with an MBIM device (as long as the device supports this service):

root@miraculix:/tmp# qmicli -p  --device-open-mbim -d /dev/cdc-wdm0 --nas-get-lte-cphy-ca-info
[/dev/cdc-wdm0] Successfully got carrier aggregation info
DL Bandwidth: '20'
Primary Cell Info
        Physical Cell ID: '176'
        RX Channel: '1450'
        DL Bandwidth: '20'
        LTE Band: 'eutran-3'
Secondary Cell Info
        Physical Cell ID: '284'
        RX Channel: '3050'
        DL Bandwidth: '20'
        LTE Band: 'eutran-7'
        State: 'deconfigured'
Secondary Cell index: '1'
1 Like