Question about Gobiserial Vs qmi_wwan

Markus Gothe nietzsche at lysator.liu.se
Sat Aug 16 10:01:39 PDT 2014


Some corrections/clarifications to the assumptions.

The old AT+CGDATA wants PPP to entering data mode. The old 2G and 3G networks backhaul is circuit switched (contrary to LTE, which is packet switched) and based on PPP.

To have a PPP-server/-client built-in on the firmware is a de facto standard way to acheive this. The modem hence works as a relay.

AT-commands are given their own TTY and CnS/HIP shares the channel with data (read: DirectIP) afaik. Check the sierra_net.c for this.

The qmi_wwan.c piggybacks on two drivers, namely usbnet.c and cdc-wdm.c

The cdc_ether.c driver implements CDC ECM like cdc_ncm.c implements CDC NCM.

The CDC MBIM is much more like QMI in "raw ip" mode than any other protocol / driver.

In fact both drivers use CDC WDM to encapsulate their commands / non-IP data (read: WMC) over the same channel.

To understand how this all work together don't limit yourself to Sierra. Check out how other vendors implement this and read up a lot ob how the backend in both 3G and 4G (including WiMax) works.

//M

Skickat ifrån min mobil.
Den 16 aug 2014 00:50 skrev Gopakumar Choorakkot Edakkunni <gopakumar.c.e at gmail.com>:
>
> Thanks again for the info. I was reading through the "AirCard / AirPrime USB Driver Developer’s Guide" from Sierra, this explanation put together with that makes things a lil bit more clearer now ! So if I summarise what I understand
>
> 1. sierra_net.c imlpemented direct-ip where there was one channel on which the AT/CnS commands were used for control, and the direct-ip channel was used for sending IP data to the modem (over a wwan0 interface created by sierra_net.c). The modem probably ran its own pppd server and then sent these packets over ppp anyways.
>
> 2. With QMI, the usbnet.c driver creates a wwan0 interface. The cdc_ether.c + qmi_wwan.c + libqmi alltogether implements the QMI control protocol. And if I understand correctly from the sierra pdf document, the IP data and QMI control are sent on the same USB channel, so I guess even data has some kind of qmi encaps which distinguishes data Vs qmi control.
>
> Rgds,
> Gopa.
>
>
> On Fri, Aug 15, 2014 at 12:13 PM, Markus Gothe <nietzsche at lysator.liu.se> wrote:
>>
>> sierra_net.c uses “DirectIP” which basically is a Sierra Wireless protocol built on-top of their proprietary CnS-proctol suite. 
>>
>> What one will realise is that DirectIP is just an encapsulation of the PPP backhaul as used in 3G. I think they “invented” this driver and technology to accelerate slow MCUs/CPUs running Linux (read: embedded systems) and letting the modems firmware handle the PPP-connection without the need of pppd (and no need to involve Qualcomm because of QMI).
>>
>> One big drawback is that like PPP you cannot do ethernet-bridging (dev->net->flags |= IFF_NOARP; which is true for PPP). If you look at older modems you will see that sierra_net.c implemented a DHCP-server using CnS/HIP (both proprietary protocols of Sierra) to give out the IP-addreses received from the GGSN.  Your default route using “DirectIP” will be your IP hence the assumption that it is PPP.
>>
>> Another driver with pretty much the same behaviour is ‘hso.c’. 
>>
>> sierra.c was used instead of option.c/qcserial.c once, I don’t really see any point in still using it.
>>
>> //M
>>
>> On 15 Aug 2014, at 20:30 , Gopakumar Choorakkot Edakkunni <gopakumar.c.e at gmail.com> wrote:
>>
>>> Thanks for the response, great blog post ! Even for the Gobinet driver, for some devices like Pantech UML295, I dont even see them putting a linux gobi driver for that in their webpage .. Looks like other than netgear (ie old sierra wireless), no one seems to be really putting the vendor specific version of GobiNet driver on their website !!
>>>
>>> Now in this whole scheme of things, where does the sierra_net.c stand ? I see that netgear  packages sierra.c (serial) and sierra_net.c (direct ip) as their drivers for some of their models, and GobiNet as their driver for some other models. So is sierra.c and sierra_net.c the driver which was created before GobiNet and then later GobiNet became the standard vendor provided driver which provides the same functionality as sierra.c and sierra_net.c ?  Also I see that the sierra_net.c is still used along with qmmi/cdc modules - I guess the sierra_net.c is used for the ethernet/data portion and qmmi/cdc is purely for management/control ?
>>>
>>> Rgds,
>>> Gopa.
>>>
>>>
>>>
>>> On Fri, Aug 15, 2014 at 9:31 AM, Aleksander Morgado <aleksander at aleksander.es> wrote:
>>>>
>>>> On Fri, Aug 15, 2014 at 3:52 PM, Gopakumar Choorakkot Edakkunni
>>>> <gopakumar.c.e at gmail.com> wrote:
>>>> >
>>>> >>>> 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.. ?
>>>>
>>>>
>>>> More or less on-topic, I wrote a blogpost about this not long ago:
>>>> https://sigquit.wordpress.com/2014/06/11/qmiwwan-or-gobinet/
>>>>
>>>> There is a 'qualcomm' GobiNet, in the CodeAurora project page, but
>>>> every vendor keeps its own. E.g. Sierra will modify the stock GobiNet
>>>> at least to add their specific VID/PID matches as well as their unique
>>>> USB interface layouts. I guess others do this as well. Sierra actually
>>>> also decided to port a fix that Bjørn did in the upstream qmi_wwan
>>>> driver, but don't know if others did that as well.
>>>>
>>>> From my POV, there are reasons to use GobiNet instead of qmi_wwan
>>>> (e.g. if you're looking for the vendor-provided product support), or
>>>> other things which we currently don't support yet (like firmware
>>>> loading)... apart from those, I'd really suggest to use qmi_wwan and
>>>> libqmi (with qmicli and/or ModemManager :) ).
>>>>
>>>> --
>>>> Aleksander
>>>> https://aleksander.es
>>>
>>>
>>> _______________________________________________
>>> libqmi-devel mailing list
>>> libqmi-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>>
>>
>>
>>
>> //Markus - The panama-hat hacker
>>
>


More information about the libqmi-devel mailing list