Question about Gobiserial Vs qmi_wwan

[Bjørn Mork]

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