Netgear Aircard 341U in QMI mode, switching to 802.3

[Markus Gothe]

Ah... Yeah, I can see advantages of the driver being dynamic enough to handle raw-ip. 
I guess as for my embedded systems use-cases it doesnt matter much how this is done since the end-users never have to handle the setup of the devices. Im just afraid that the snooping would go wrong because of firmware issues.

I can confirm that you are correct about your nasty feeling; ZTE's MBIM stack as an example actually wraps around QMI and depending on probe it might end up in MBIM-, CWID- or QMI-mode. So you can always given the correct switch command switch them over to QMI (which, the switch commands, I suppose has been given to me under NDA, however I had to RE their MBIMd to see that it wrapped around QMI).

//M

Den 11 jun 2015 10:00 skrev Bjørn Mork <bjorn at mork.no>:
>
> 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.)
>
> 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...)
>
> Bjørn
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel