Adding support for Quectel modem

[David Drinnan]

The Quectel EC21 LTE modem (for example), with a Qualcomm chip under the hood, provides an AT command interface as well as QMI (Qualcomm binary interface). I'm more familiar with the AT command interface at the moment, but the QMI interface looks interesting.

Quectel provides an AT command set for several of the common protocols -- TCP/IP (including ping support, DNS support, and socket support), HTTP(S), MQTT, PPP, FTP, and so on. These command sets so far seem pretty effective at basic use cases for each protocol, including SSL authentication in many cases. 

But I'm struggling with figuring out how to properly integrate a modem like this into the NuttX network driver stack. I've searched around the net, and the NuttX wiki, and the Google group here, and took a look at the code in 'nuttx/drivers/net', and I just can't seem to get a foothold on a good place to start. The best examples I've found in the NuttX codebase that seem to "talk" AT commands are pppd and chat, which are well outside my experience, but from what I can tell don't really help if you want to talk TCP/IP and HTTP(S).

So at the moment, as much as I hate to do it, I'm planning on just creating a tight integration between apps and the Quectel modems, instead of tightly integrating it into the NuttX TCP/IP network stack. I hate it to do this because of the obvious benefits of being able to support practically any network app that can talk TCP/IP, instead of having to port every app to use a Quectel API.

One path forward I'm considering is porting `libqmi` from Linux to NuttX, but that would be my first foray into porting a library, and I don't really know where to begin there, or how big of a can of worms that is.

Feeling lost. Hoping someone has some pointers!

[Ramtin Amin]

Can you have raw TCP/IP ? in this case you could consider TUN/TAP 

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gregory Nutt]

Hi,

The Quectel EC21 LTE modem (for example), with a Qualcomm chip under the hood, provides an AT command interface as well as QMI (Qualcomm binary interface). I'm more familiar with the AT command interface at the moment, but the QMI interface looks interesting.

Very big difference.  If you are using an AT command interface, then the code is probably an application that you would put under apps/.  If you are using a lower, level, real binary interface, then it would go under drivers/... somewhere.

Same is true with other AT network or wireless parts.  Serial AT is an application that interfaces via drivers in /dev/ttySN.  Lower level interfaces would be in drivers/... somewhere.  Other modem driers are in drivers/modem but depending on the nature of the part drivers/wireless or  drivers/net are possibilities.

Quectel provides an AT command set for several of the common protocols -- TCP/IP (including ping support, DNS support, and socket support), HTTP(S), MQTT, PPP, FTP, and so on. These command sets so far seem pretty effective at basic use cases for each protocol, including SSL authentication in many cases.

This is via serial, right?  So that is application layer stuff.

But I'm struggling with figuring out how to properly integrate a modem like this into the NuttX network driver stack. I've searched around the net, and the NuttX wiki, and the Google group here, and took a look at the code in 'nuttx/drivers/net', and I just can't seem to get a foothold on a good place to start. The best examples I've found in the NuttX codebase that seem to "talk" AT commands are pppd and chat, which are well outside my experience, but from what I can tell don't really help if you want to talk TCP/IP and HTTP(S).

You can look at apps/netuitisl/esp82866.  There is another networking devices that interacts through serial.  Your code might go in apps/netutils too???

So at the moment, as much as I hate to do it, I'm planning on just creating a tight integration between apps and the Quectel modems, instead of tightly integrating it into the NuttX TCP/IP network stack. I hate it to do this because of the obvious benefits of being able to support practically any network app that can talk TCP/IP, instead of having to port every app to use a Quectel API.

The AT interface is part of the application and does not belong in the networking layer.  I think are going in the right direction if AT is what you plan to use for the interface.

One path forward I'm considering is porting `libqmi` from Linux to NuttX, but that would be my first foray into porting a library, and I don't really know where to begin there, or how big of a can of worms that is.

You are talking about stuff that I am unfamiliar with.  "What is QMI?  QMI is a binary protocol designed to replace the AT command based communication with modems, and is available in devices with Qualcomm chipsets... This protocol is easily accessible in recent enough Linux kernels ... through the cdc-wdm and qmi_wwan drivers. Once these drivers are in place and the modem gets plugged in, the kernel will expose a new /dev/cdc-wdm device which can talk QMI, along with a wwan interface associated to each QMI port." https://sigquit.wordpress.com/2012/08/20/an-introduction-to-libqmi/

So you also have to write those drivers.  Still libqmi is a user application.  the cdc-wdm and qmi-wwan would reside in the OS.  I assume that these are character drivers and would still not involve the networking layer.  In stead of using the ASCII AT commands through a serial driver, you would use these binary protocols through a custom character drivers.  Not much difference architecturally.

I will look at the part in a little more detail and see if there is anything more I could offer.

Greg

[Brennan Ashton]

Almost all LTE modems with USB interfaces support NDIS which is supported by Nuttx, you should be using that for providing the network interface. From the application layer you can use the AT interface to control the modem function over a standard serial interface. 

[patacongo]

Can you have raw TCP/IP ? in this case you could consider TUN/TAP 

If you just want to use NuttX BSD sockets you could also consider the USRSOCK implementation that provides network socket interface to an external TCP/IP stack th is managed by userspace applications.  There is a "proxy" fo the user space sockets in the OS (see nutt/net/usrsock), but the actual hardware interface via a character driver in in application space.  See for example, apps/examples/usrsocktest.

Ramtin is suggesting that you use the NuttX TCP/IP stack.  Is that possible?  My understanding from the trivial amount that I have learned from you is that the TCP/IP stack SSL, etc. reside in the part and you interface to it via AT commands or via a custom binary interface.  If the former is the case, then TUN/TAP network devices are an option.  Otherwise, you need to consider either (a) a custom application interface, or (b) usrsocks.

[David Drinnan]

On Wednesday, October 10, 2018 at 10:39:45 AM UTC-7, yek owt wrote:

Can you have raw TCP/IP ? in this case you could consider TUN/TAP 

I'm pretty inexperienced in dealing directly in the TCP/IP layer, so I'm not sure what "raw TCP/IP" means exactly, but I suspect the answer is, "No", since the lowest level the Quectel AT command set seems to support is sockets, with the below service types (per their docs):

<service_type>

“TCP” - Start a TCP connection as a client

“UDP” - Start a UDP connection as a client

“TCP LISTENER” - Start a TCP server to listen to TCP connection

“UDP SERVICE” - Start a UDP service

[Brennan Ashton]

According to the datasheet this does support ndis. Is there a reason you do not want to use this interface?

[patacongo]

Can you have raw TCP/IP ? in this case you could consider TUN/TAP 

Weird, my last response was lost.  I will try to summarize:

Using a TAP/TUN interface is something that you can do if you can support raw TCP/IP sockets.  But I suspect that you cannot do that because the TCP/IP stack, SSL, etc. is inside the chip.

That means you have two options:

1. A custom application layer interfaces as been dicussed, or

2. If you really want to integrate with the NuttX networking and use the NuttX BSD socket layer, then you should look into the user space sockets usrsock.  These are hooks that let you provide a user space interaface to a external network device.  The socket implementation is here:  nuttx/net/usrsock and there is an example here apps/examples/usrsock.

So you would have to implement the usrsock client that is basically an RPC for the OS.  socket operations will be forwarded to the usrsock implementations where your are free to use any command interface you like to implement the socket operations.

USB RNDIS was also mention.  NuttX does support device-side (only) RNDIS.  If the devices supports a USB host function and can communicate with a RNDIS USB device, then that an option.

[David Drinnan]

On Wednesday, October 10, 2018 at 10:51:35 AM UTC-7, patacongo wrote:

This is via serial, right?  So that is application layer stuff.

Yes, indeed. I've got it communicating over `/dev/ttyS0`. 

You can look at apps/netuitisl/esp82866.  There is another networking devices that interacts through serial.  Your code might go in apps/netutils too???

Thx for the tips, I'll take a look at those more closely!

 

The AT interface is part of the application and does not belong in the networking layer.  I think are going in the right direction if AT is what you plan to use for the interface.

Ok, that's good to have that sanity check, thx.

 

So you also have to write those drivers.  Still libqmi is a user application.  the cdc-wdm and qmi-wwan would reside in the OS.  I assume that these are character drivers and would still not involve the networking layer.  In stead of using the ASCII AT commands through a serial driver, you would use these binary protocols through a custom character drivers.  Not much difference architecturally.

Ok, so I'll scrap that idea, too big a can of worms for little benefit if any.

 

[David Drinnan]

Ah, I didn't know about NDIS!!! Ok, that might be the key, let me take a look. Thanks very much!

[Oleg Evseev]

Also you can take a look on library for controlling u-blox Cellular Modem that uses usrsock  https://github.com/thingsee/thingsee-sdk/tree/master/apps/system/ubmodem (haven't test it)

---

With regards, Oleg.

ср, 10 окт. 2018 г. в 21:10, David Drinnan <dsdri...@gmail.com>:

--

[Brennan Ashton]

I did a couple products using LTE modems and if bandwidth is at all a concern you will want to use it. I thought that the host side had been done for NDIS, but Greg seems to think it was device only so we must have done that internally unfortunately. The protocol is actually quite simple, so I suspect it would not take too much work to extend the existing one to support host mode. 

--

[patacongo]

I was poking around in https://github.com/thingsee/thingsee-sdk/tree/master/ to see if I could find a real world implementation of usrsock's.  But I don't know exactly where to look.

But anyone interested in networking and/or IoT with NuttX should look at the SDK.  There is a a lot of very cool add-ons to NuttX  and especially to apps/ there.

[David Drinnan]

On Wednesday, October 10, 2018 at 10:57:47 AM UTC-7, patacongo wrote:

If you just want to use NuttX BSD sockets you could also consider the USRSOCK implementation that provides network socket interface to an external TCP/IP stack th is managed by userspace applications.  There is a "proxy" fo the user space sockets in the OS (see nutt/net/usrsock), but the actual hardware interface via a character driver in in application space.  See for example, apps/examples/usrsocktest.

Ok, I didn't think to look at USRSOCK, I'll take a look there. Thx.

 

Ramtin is suggesting that you use the NuttX TCP/IP stack.  Is that possible?  My understanding from the trivial amount that I have learned from you is that the TCP/IP stack SSL, etc. reside in the part and you interface to it via AT commands or via a custom binary interface.  If the former is the case, then TUN/TAP network devices are an option.  Otherwise, you need to consider either (a) a custom application interface, or (b) usrsocks.

Yes, indeed the TCP/IP stack, SSL, etc. all reside in the Quectel part, with a somewhat limited API to use each of them. You can activate a "PDP context" to a specific Access Point Name (APN) -- I'm using "vzwinternet" -- and it assigns you an IP, not real configuration there besides the choice of APN and username, password. 

Once you have an IP, you can open and close sockets with "service type" option mentioned above, remote IP address/port and domain name, local port, and then you chuck data over to the Quectel via another AT command to send over the socket for you, and another AT command to receive data from the Quectel.

There's also QMI as I mentioned, and now I've heard of NDIS, which sounds promising.

[Alan Carvalho de Assis]

Hi David,

There is an interesting thread discussion here:

https://forum.netgate.com/topic/129994/qmi-mbim-ncm-rndis-protocols/12

On FreeBSD they use "usb_modeswitch" to switch the modem to NDIS mode.

BR,

Alan

PS: thanks to subscribing to NuttX Channel few hours ago.

[spudaneco]

Sent from Samsung tablet.

> On FreeBSD they use "usb_modeswitch" to switch the modem to NDIS mode.

The Linux commnd?  https://linux.die.net/man/1/usb_modeswitch

[Alan Carvalho de Assis]

Hi Greg,

I was thinking FreeBSD used a self implemented version, but it is the
same Linux program:

http://www.draisberghof.de/usb_modeswitch/

BR,

Alan

[David Drinnan]

Just reporting back. The `ubmodemd` and related libraries so far port very well to Quectel, with just some changes to AT command names and command flows. I've got it up and running to the point where it registers the Quectel to the Verizon network and gets an IP. I'm now busy turning on the network bits needed to get USRSOCK up and running, and updating the AT commands for that part.

Anyway, so far, so good. Thanks for the tips, everyone!

[Alan Carvalho de Assis]

Kudos David!

If you can please create a blog explain how to do it, could be useful for people using NuttX and this Quectel modem.

BR,

Alan

On Thursday, October 18, 2018, David Drinnan <dsdri...@gmail.com> wrote:

Just reporting back. The `ubmodemd` and related libraries so far port very well to Quectel, with just some changes to AT command names and command flows. I've got it up and running to the point where it registers the Quectel to the Verizon network and gets an IP. I'm now busy turning on the network bits needed to get USRSOCK up and running, and updating the AT commands for that part.

Anyway, so far, so good. Thanks for the tips, everyone!

--

You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

[Gregory Nutt]

> If you can please create a blog explain how to do it, could be useful
> for people using NuttX and this Quectel modem.

Or a Wiki Page?