How does one integrate WIFI & GSM into a microcontroller project with LWIP/TLS?

[peter-h]

I have this 32F417 based board (FreeRTOS, LWIP, MbedTLS, FatFS). Ethernet 10/100. All working.

Add-ons are interfaced via SPI, up to 21MHz.

I have a customer enquiry for WIFI and 4G.

AFAICT 4G uses a module. U-BLOX do some. I am already using a U-BLOX SPI GPS module.

With a GSM modem, you send it ATDT*99# and then when it returns OK (it now has an IP connection, be it GPRS, EDGE, 3G, 4G, 5G, etc according to local availability) you connect the TCP stack to it. I suspect one just does new versions of the ETH low_level_input and low_level_output functions (which currently connect LWIP to the ETH controller in the CPU, and aren't particularly complicated).

WIFI I have no idea. How is that done? It could be vastly more complex than GSM. One extra is that you need a UI somewhere to configure the credentials, so the product needs an LCD, or a config via ETH or USB.

I would always want to leverage my existing product, because it works great, and doing all this from scratch would be a huge job. The ESP32 tends to draw these applications but that would be a huge engineering job with a lot of risk, compared to doing an SPI daughter board with two modules on it. And I've had so many bad experiences with Chinese vendors (which I have used extensively) and the severe degradation in their business ethics, plus the obvious political risk, that I don't want to go down that route. The Chinese are picking up a lot of business right now because they are shipping silicon, when Western companies are not.

Has anyone done this before, and what kind of extra software is needed?

[tellurium]

For WiFi, I'd look at the WiFi module used by the RP2040 Pico-W board.
https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html#raspberry-pi-pico-w-and-pico-wh
It uses CYW43439 Cypress module (now Infineon), https://www.infineon.com/cms/en/product/wireless-connectivity/airoc-wi-fi-plus-bluetooth-combos/wi-fi-4-802.11n/cyw43439/?redirId=216343

[Silenos]

So you want GSM or 4G? That's not the same thing. And for 4G: do you want short messages? voice? video? Internet? Mind GSM/UMTS is totally different to 4G + on everything, including UE interfacing. I'm not familliar with full-blown 4G modules, but if such exist, you propably can get away with 4G-specific nasty stuff, especially with at commands.
Also, good luck with handling multiple eth interfaces without linux.

[peter-h]

Just internet. It would be short messages. Telemetry.

The actual network connection is transparent to the TCP/IP stack, normally, but obviously anything less than 3G doesn't work at all for normal internet use since the protocol is so horrible (over https) that various things time out.

I said "GSM" because that is how you start. You start with a GSM (voice, SMS, and 9.6k data which used to be sold as "WAP") dial-up connection to the tower, and you dial ATDT*99# and then you get whatever there is for the IP connection. AFAIK you never just start with 4G. But this is implemented by the module, AFAIK, and some may do the dial-up internally. With the older GPRS modems, say the Siemens/Cinterion TC35 etc ones, *99# would get you only GPRS (because that was all the modem did) which at ~20kbits/sec is absolutely fine for talking to private servers but probably not for TLS and it is almost totally useless for the open internet. Messaging (e.g. Telegram) works over GPRS, eventually, but websites don't.

Probably the ETH v. GSM selection would be done with a config file i.e. not auto config.

[nctnico]

Likely any 'GSM modem' (whatever is underneath it) talks to a host using PPP protocol so the microcontroller side would need to be able to work with that.

[peter-h]

LWIP includes PPP: https://lwip.fandom.com/wiki/PPP

Never used it though.

[rf-fil]

I used STM32 with LWIP with PPP (serial port) over a 4G modem on a project before. I now recommend against it in any non-hobby use cases. Reasons:

- This solution cannot be easily (or at all?) secured from bad actors accessing the system over public internet. First reason is that LWIP was (probably still is) full of security holes. Secondly, TLS can be quite slow on an MCU. Like, unusably slow. Maybe both of those issues got fixed since I used it a few years ago? The last reason is that in order to ensure security, the system must be able to be patched to fix security holes, at any time. That means, over your 4G connection. Being able to re-program the firmware locally over a cable only works for hobby applications. There are many crappy insecure hacked IoT devices making up botnets out there already. Let's not add another one.

- LWIP is just the TCP/IP stack. Then you have TLS. However, in practice, you often need other services or protocols. All of the common internet protocols that are available out of the box on Linux don't exist in the MCU world. For example, we had to write nsupdate from scratch (no, I didn't design the system architecture. Nsupdate was a requirement.)

In most cases, it's better to use a single board computer with Linux for anything that needs TCP/IP comms. There are SBCs out there that are cheap, tiny, and fairly low power nowadays. They are harder to design, hardware-wise, if you plan to build one from scratch.

Some 4G modems used to be Linux-based and able to run your application, and communicate with the rest of the world over UART, SPI, GPIOs, etc. I haven't checked for these in a few years (out of that industry) but they seem worth checking out as well. These came up management systems that let you patch the system to keep the devices secure.

[peter-h]

This solution cannot be easily (or at all?) secured from bad actors accessing the system over public internet.

This is a problem with all IOT applications. They should never be open to the public. They should only be clients, accessing a private server, from behind NAT. That server, in turn, may be public facing.

LWIP was (probably still is) full of security holes.

See above. However, I have not found a list of these. I am assuming it will indeed be full of holes (actually I would expect any embedded system to be full of holes like buffer overflow issues in the low level ETH area, but this should not matter. Can you find a list? LWIP is about 15 years old so the most obvious stuff should have been done. It seems to be running utterly reliably.

Secondly, TLS can be quite slow on an MCU.

That's true but probably not bad enough. I have a 168MHz 32F417 running MbedTLS, accessing two websites over HTTPS. One has a certificate chain of 3 and the other is 4. The TLS time is 2 and 5 secs, including the server time. This is the setup. Then the session crypto, which is usually negotiated to AES256 (which I have in hardware, but even the software version in MbedTLS does 800kbytes/sec) or Chachapoly (in software, also very fast). The session speeds are vastly greater than any realistic application will be needing (or getting) over the internet. It also seems reliable, in the private server single certificate scenario at least.

There are many crappy insecure hacked IoT devices making up botnets out there already.

Can you give examples?

How can an IOT box be a bot if there is no operating system? The "OS" in my case is FreeRTOS but good luck installing another task remotely, by flashing the CPU.

Anyway, just because some people buy an IP webcam and install it with port 80 open with the default password so google can find it and then any hacker can see your house doesn't mean that a proper installation (client only, etc, as above) will do that.

Most telemetry type applications are just clients uploading to a private server, and they are behind NAT. Anything on 4G, unless specially set up, will be behind NAT, and the channel closes after ~ 3 minutes.

I think a lot of 4G modems are linux based. I have used the RUT240 and similar and all have UIs so unbelievable slow they must be linux based

These came up management systems that let you patch the system to keep the devices secure.

OTA updates are a huge admin task which I would always avoid. It has the potential to kill your company if you brick a load of devices which then need a site visit. Same with anything doing TLS to some server which you don't control; you need a means of updating the root certificate chain (a ~200k file). Using a linux board means you have a relatively secure solution for running a public server (which itself is dumb with IOT) but a month down the road you face these same challenges.

It is interesting that 4G would be done over PPP. It looks like it might even coexist with ETH, which is interfaced to LWIP differently.

[fchk]

With PCs and embedded Linux systems nobody actually uses PPP due to latency issues. There are QMI and MBIM interfaces that are much more efficiant, and some M.2 and MiniPCIe cards even provide a CDC-ECM or RNDIS network interface via USB.

M.2 and MiniPCIe LTE cards usually use USB, WiFi/BT cards either USB or SDIO for Wifi and UART for BT.

I'd use a small Linux system for networking. This saves you tons of work, has already all the required infrastructure, and the IP stack is much better than LWIP.

fchk

[peter-h]

OK, but let's say I don't want to do this, and I want to "leverage" (to use the fashionable term) my existing hardware, analog interfaces, long term manufacturability (try that with a "PC") and even the neat and tidy packaging.

I have an SPI interfaced 4G modem module. Does one really talk PPP protocol to that? I guess it might be PPPOE - same as 4G routers.

[fchk]

OK, but let's say I don't want to do this, and I want to "leverage" (to use the fashionable term) my existing hardware, analog interfaces, long term manufacturability (try that with a "PC") and even the neat and tidy packaging.

I have an SPI interfaced 4G modem module. Does one really talk PPP protocol to that? I guess it might be PPPOE - same as 4G routers.

These modules usually don't use SPI. Either USB (preferred, fastest) or UART.
The serial commiunication works just with an old analogue modem with AT commands. And yes, it's standard PPP.

Some modems also have a built-in IP stack and high level AT commands for FTP, SMTP, HTTP and generic TCP connections.

fchk

[tszaboo]

This solution cannot be easily (or at all?) secured from bad actors accessing the system over public internet.

This is a problem with all IOT applications. They should never be open to the public. They should only be clients, accessing a private server, from behind NAT. That server, in turn, may be public facing.

Usually the telco will take care of this when you buy an M2M simcard. It's literally a non issue most of the cases. Unless you do roaming and go to countries where the setups are sometimes wrong.
About the connection to the modules, use UART. The I2C or SPI is often times isn't implemented correctly, or there are missing features. Have a very good understanding about how to do FW updates on the module. I had this Linux SBC that was connecting to a modem with USB. Wanted to do a FW update on it, got an .exe file to do it. I asked them how they expect me to run this: "Oh, we only support windows for FW updates through USB and microcontroller code with serial port." :palm
With Wifi, you can either use a side channel to configure it. Or have host a webpage where users can enter credentials to their network with their phone. Honestly, if you already have a 4G module, just skip Wifi. With an esim, you have a device which always works, and customer doesn't start complaining when they change their wifi router.

[peter-h]

Some modems also have a built-in IP stack and high level AT commands for FTP, SMTP, HTTP and generic TCP connections.

I used the Siemens TC35 which did GSM (SMS basically, and FAX which actually worked!! - we implemented that, with fonts and all, about 15 years ago) and GPRS, and contained enough the IP stack to do, via AT commands, email sending. We never implemented email receive. I think it could retrieve from a POP box. But these were horrible boxes, totally non-futureproof (not just due to the totally weird use of AT commands to access IP) and after going through ~3 changes of company, ending with a Cinterion BGS2T, disappeared. Clumsy and expensive, due to being external. Nobody wants that today.

I would rather use the like of a RUT240 which connects via ETH and already works with my product, but again is external and clumsy. IME every product which uses an external modem has failed to sell.

I have four UARTs so that is OK.

Usually the telco will take care of this when you buy an M2M simcard. It's literally a non issue most of the cases

I would suggest because nobody is implementing a server with a SIM card device, especially not a public facing one, with a public DNS and a fixed IP

The I2C or SPI is often times isn't implemented correctly,

Indeed, the U-BLOX GPS SPI is horrible.
https://portal.u-blox.com/s/question/0D52p0000CL5I0OCQV/neom9n-and-spi-does-it-work-with-proprietary-ubx-packets
https://portal.u-blox.com/s/question/0D52p0000AOH1lzCQD/neom9n-spi-am-i-reading-the-manuals-correctly
etc etc. But it works, if a suitable clock speed is chosen to throttle the data sent to it. And if you avoid using data packets potentially containing 0xFF

Honestly, if you already have a 4G module, just skip Wifi

Interesting. I will try to push that.

IMHO with 4G or WIFI there may well be a need for OTA updates eventually, whereas with an embedded box one can usually avoid that can of worms.

A really easy way to do WIFI is to buy a WIFI AP, config it for a fixed IP, or DHCP server, and connect it to my box with an ethernet cable It's a case of convincing the customer to accept a multi box solution.