Question about Gobiserial Vs qmi_wwan

Fri Aug 15 06:52:41 PDT 2014

Thanks for the very detailed reply Bjorn !!

>>> No, I Sierra Wireless do definitely test their Linux drivers.  And they
do provide support for them (in the embedded market).  So the
GobiSerial/GobiNet drivers *might* be the correct choice for some users,

So does the Gobinet driver that I get for example from the Netgear AC340U
product page - does that work for ALL classes of Sierra devices or does
Netgear or other vendors (huawei etc..) put in their own fixes on top and
repackage it and put it on their website ? Or is there some other place
where qualcomm maintains a gobinet driver which is the latest and greatest
and supports netgear and huawei and pantech and etc.. etc.. ?

>>> QMI devices support many different framing modes, but the qmi_wwan
driver supports only a single well-defined mode: 802.3 frames with no
additional headers in both directions.

Is this true for ALL Sierra devices ? Can ALL of them (which we can buy in
market today from netgear/huawei/pantech etc..) work in the 802.3 mode ? In
otherwords, is it safe to add the qmicli you suggested to set the 802.3
option as soon as it detects a Sierra device (from udev or some early
bootup script) ?

As for the design, I really really agree that the qmi_wwan design looks
very neat - the kernel part doing just enough and just the right things,
and I agree thats the right thing to do. I wish Gobinet had done the same
rather than packing everything into a kernel module. Do you know whether
this heavy-kernel-module design of Gobinet has historically been more bug
prone ? Are there reports of kernel crashes/hangs/freezes etc. caused by
Gobinet ?

Rgds,
Gopa.

On Fri, Aug 15, 2014 at 1:56 AM, Bjørn Mork <bjorn at mork.no> wrote:

> Gopakumar Choorakkot Edakkunni <gopakumar.c.e at gmail.com> writes:
>
> > So now the question is - for changes like this where the firmware makes
> the
> > default to be raw-ip etc.., do you think the Gobiserial/Gobinet driver
> that
> > Netgear packages on their website would take care of such things ?
> > Obviously, the windows/mac drivers they provide would have taken care of
> > this , but from your experience, is their level of commitment to Linux
> > drivers equally good ? Or are they just packaging some
> > untested/not-so-tested version of Gobi drivers and throwing them on the
> > website ?
>
> No, I Sierra Wireless do definitely test their Linux drivers.  And they
> do provide support for them (in the embedded market).  So the
> GobiSerial/GobiNet drivers *might* be the correct choice for some users,
> typically embedded integrators requiring a combination of commercial
> support and old kernel versions...
>
> > I am guessing the reason why the entire qmi_wwan project started
> > would have been probably because the vendor support for linux drivers was
> > not good ?
>
> Mostly because I couldn't get the GobiNet driver working with the Huawei
> E392 I used at the time.  Which likely was more a problem with my
> attempt to forward port it than anything else :-)
>
> Anyway, it just seemed simpler to write a new driver (and of course it
> wasn't :-) But at the end we had the qmi_wwan driver in the mainline
> kernel, which made it all worth it.  We do want drivers in mainline so
> that they are available in all distros and to all users. Out-of-tree
> drivers are not an option for the majority of users. Noone builds their
> own kernel anymore, and the distros have limited resources available to
> support such drivers.  So although it is a nice gesture from vendors to
> provide out-of-tree drivers, these do not really help much unless they
> can be mainlined.
>
> There had already been a couple of failed attempts to get a version of
> the GobiNet driver into mainline at the time I wrote qmi_wwan.  But it
> was not accepted even if the developer had put a lot of effort into
> cleaning it up and making it conform to the kernel coding style. I
> wasn't involved in this at all, but my impression was that the userspace
> API design was fundamentally unacceptable in the mainline kernel.  So
> was my initial attempts...  But I had the advantage that I could
> redefine the userspace API as I wanted, because I had no existing
> userspace to support.  So after a couple of rounds we ended up with the
> driver looking the way it does today.
>
> > The reason I ask is because in general, if after a firmware upgrade, if
> we
> > run into issues, from your experience, is the Gobi driver provided by
> > quallcom/vendor (netgear/huawei/..) will be a good bet to get things
> going
> > while the qmi_wwan experts like you all catch up with the changes ? Does
> > such "changes/catch-up" happen often ? Please let me know your thoughts.
>
> The userspace/kernel API of qmi_wwan delegates *all* QMI configuration
> and management to the userspace management application. Configuring the
> supported data frame mode is part of this management task.  QMI devices
> support many different framing modes, but the qmi_wwan driver supports
> only a single well-defined mode:
>
>  802.3 frames with no additional headers in both directions.
>
> This is a deliberate choice. It's not that this is the "correct" mode or
> anything.  The choice is quite arbitrary. But prior to the WDA subsystem
> being added there was no way to detect which mode the device was
> configured for.  And we still have to support such firmwares.  This
> implies that the driver has to choose one mode and stick with that.  We
> started out with 802.3, so that became the choice.
>
> The setting is "sticky" (saved in NVRAM on the device) and most devices
> are already preconfigured for the wanted mode.  This has left the
> impression that you can use a QMI device without first setting the
> appropriate mode.  This has in fact never been true! You should always
> configure the device for the appropriate mode before you initiate the
> first data session.  You can never know whether some other application
> has changed the mode since the last time you used the device.  This
> could be a firmware upgrade application, but it could also be a Windows
> driver or some other QMI application.  Simply dualbooting could cause
> the setting to be wrong if the installed Windows driver use raw IP
> frames.
>
> AFAIK, ModemManager does this correctly.  Your problem was caused by
> using a "debug utility" like qmicli.  This gives you a lot of freedom,
> but it also makes you responsible for proper configuration of the
> device.  Including the framing.  qmicli provides all the necessary
> requests, but you are resposible for using them in the appropriate
> order.
>
> Normal users, depending on ModemManager for management, would not notice
> that there was an issue at all.  And that's the way it is supposed to
> work.
>
> I hope this clears up stuff a bit.
>
>
>
> Bjørn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20140815/072fe1ce/attachment.html>