Netgear Aircard 341U in QMI mode, switching to 802.3

[Dan Williams]

On Thu, 2015-06-11 at 22:16 +1000, David McCullough wrote:
> Bjørn Mork wrote the following:
> > Markus Gothe <nietzsche at lysator.liu.se> writes:
> > 
> > > Well, I dare you on this.
> > > Go show me a PoC and I’ll consider it.
> > 
> > It's possible, but I agree that it quickly will become ugly.
> > 
> > I tried something like this for MBIM IP session IDs while experimenting
> > with different ways to solve the MBIM multiplexing.  As you know now, I
> > ended up dropping all that. Instead userspace have to syncronize netdev
> > creation with MBIM session creation.  I'm still not sure which solution
> > is best/worst.  Both have their advantages and disadvantages.  But I
> > know why I selected the one I did:  It was the simplest one for me :)
> > 
> > Do note though, that there aren't yet any userspace implementation of
> > the MBIM multiplexed sessions (AFAIK).  Adding some userspace PoC for
> > this has been on my TODO list for quite a while, but is still not done.
> > That's also a factor to consider here.
> > 
> > > What I’ve in mind is this:
> > > http://www.spinics.net/lists/linux-usb/msg58432.html where Björn
> > > showed us off...
> > 
> > Which has the disadvantage that it adds yet another userspace API, with
> > strict rules on how it should interact with the existing API, while
> > offloading all the policing to userspace.  Not nice.
> > 
> > The userspace QMI offloading was a success, but if we go too far in that
> > direction then we risk making it impossible to create userspace tools.
> > Having a single well-defined management protocol managed by userspace is
> > fine.  Combining it with rules on how to configure the netdev is not.
> > (Which means that the qmi_wwan driver ideally should do the MTU setup
> > for example.  But it doesn't.)
> 
> My .2c,  people think of these things as network interfaces,  its nice if
> you can use standard network tools / apps when dealing dealing with them.
> For me,  not being able to run dhcp is a deterent.  Any thing that
> unifies any part of the already widely varying modem API's is a good thing.

They are network interfaces, but they are not necessarily *ethernet*
interfaces, nor do they necessarily support DHCP.  But that's fine,
neither did PPP-based modems.  I agree that having an ethernet-based
DHCP-capable network interface is somewhat simpler, but the additional
complexity of DHCP and ethernet encap/decap has to come from somewhere,
since no modems are ethernet-based nor do they use DHCP.

(well OK, they are supposed to do passthrough DHCPv6 but that still
isn't ethernet.  Plus CDMA devices actually do use PPP over the air, but
I doubt they just pass through PPP packets from the host's pppd...)

And since we don't control the firmware, we obviously have to handle
cases where the firmware doesn't support DHCP or doesn't support 802.3
mode, or both...  yay for networking.

TLDR; yeah DHCP + ethernet would be nice but supporting these
"standards" is more work for the firmware writers, and we cannot count
on them to do it, or do it well.  At some point we'll find modems that
don't do DHCP or don't do ethernet, and we'll need to talk to them too.

Dan

> > I tend to agree with Dan on the raw-ip issue.  Snooping on the device
> > setup in the driver will allow all existing QMI userspace
> > implementations to use raw-ip without any major changes.
> > 
> > But I do still hope we can avoid doing the raw-ip support at all.
> > 
> > 
> > (I have a nasty feeling that we compete with the firmware setup here,
> > and that the reason the 802.3 commands fail is that there is some
> > firmware application needing the modem in raw-ip mode.  We risk that new
> > firmware revisions will try even harder...)
> 
> Not sure this applies here,  but our 341u implementation uses current libqmi
> and used to always pass the 802.3 flags to all calls.  This seemed to make it
> behave consistently in normal operation.  However, when the 341u is in IPPT
> mode,  it didn't matter,  it always seemed to run in raw-ip mode, so we
> just stopped using the 802.3 flags on the 341.
> 
> IPPT mode can be enabled with:
> 
> 	at!ippassthrough=1
> 
> and disabled with:
> 
> 	at!ippassthrough=0
> 
> Cheers,
> Davidm
>