running libqmi on Android / qmuxd

[Dan Williams]

On Tue, 2016-12-20 at 21:54 +0100, Harald Welte wrote:
> Hi Reinhard,
> 
> thanks for your input.
> 
> On Tue, Dec 20, 2016 at 09:26:57PM +0100, Reinhard Speyerer wrote:
> > 
> > as can be seen from Core/Socket.h of the Gobi Extensible API the
> > QMUXD protocol uses these messages types
> > so the mapping should be pretty simple.
> 
> I will try this soon, hopefully tomorrow.
> 
> > 
> > One feature that seems to missing from both the GobiNet driver and
> > the
> > QMUXD protocol is an equivalent to QMI_CTL_GET_VERSION_INFO
> > however.
> 
> For qmuxd there is QMI_QMUX_IF_GET_VERSION_INFO which generates a
> QMI_CTL_GET_VER_INFO_MSG_ID towards the baseband processor.  So I
> think
> that also shouldn't be a problem.
> 
> My immediate goal is to find a way to establish a packet data
> connection
> (via WDS) from the Linux processor on a non-android qmuxd-based MDM
> chipset.  The bit question I've been wondering about is how to
> identify
> the network device via which the actual IP data of the PDP context
> will
> be received (e.g. rmnet0).  I was hoping the WDS Start Nework
> Interface
> message contains something like a port ID.  I found some referencs to
> a
> iface_handle and a data_call_origin field.

You do get a "Packet Data Handle" which you pass to StopNetwork to kill
the bearer.  I haven't seen anything about iface_handle or
data_call_origin in any of the public QMI documentation, Gobi source
code, or Android code.

> If the QMI request is issued on the control pipe associated with one
> particular network interface, I geuss it is implicit that at least
> the
> default is to transport the data over that interface, too.

Correct, at least that's how it works with qmi_wwan/cdc-wdm.  The
netdev and the WDM are tied together (since they are exposed by the
same USB interface #, except in the case of CDC unions where they are
obviously different interface, but the pairing is indicated by the USB
descriptor) and commands on one pair don't affect commands on the other
pair.

If you have a way of identifying pairs of SMD-based rmnet/qmiX devices,
then you'll know which netdev you're controlling from which qmiX.
 Hopefully that's not as awful as strcmp() on the device name index,
but I know some of the android sources (used to?) do that.  Ick.

> The next question is how to put different PDP contexts in different
> network devices...  But let's see how far I get in terms of the
> basics,
> first.

IIRC you get maximum of one IPv4 packet data handle and one IPv6 packet
data handle per interface pair.  You can optionally specify a "Profile
Index 3GPP" TLV to StartNetwork which I believe corresponds to the
AT+CGDCONT PDP/EPS context number.  Otherwise I think the firmware just
makes a new context or uses an existing one that matches the APN TLV.

Activating a dual-stack (eg IPV4V6) context requires separate WDS
clients and separate setup paths.  You create a first WDS client for
IPv4, call StartNetwork, then GetCurrentSettings.  Then you create
another WDS client for IPv6, call StartNetwork, then
GetCurrentSettings.  Then you can apply all those IP details (both v4
and v6) to the same netdev.  But if you try to create a third WDS
client and call StartNetwork on it one of the previous two will be
destroyed.

I have not tried dual-stack using separate PDP/EPS contexts and
"Profile Index 3GPP" (eg, one V4 and one V6), but I wouldn't be
surprised if it failed.  Would be interesting to know though!

The easiest path to multiple contexts is to use multiple net/control
pairs, if you have them.  The process would be the same for all pairs;
create WDS client on a pair's control pipe, call StartNetwork, then
GetCurrentSettings, then apply the settings to that pair's netdev.
 Repeat for the next pair using a different context.

At least I'm 90% sure of all this :)  If I'm wrong in some way, Bjorn
or Aleksander are fully capable of correcting me.

Dan