Mongoose
Embedded TCP/IP Stack Comparison
Choosing a TCP/IP stack for an embedded product affects every networked feature the device ships. This article compares six stacks - lwIP, FreeRTOS+TCP, Zephyr, NetX Duo, CycloneTCP, and Mongoose - on integration model, hardware driver requirements, RTOS dependency, protocol coverage, memory footprint, security, licensing, and long-term maintenance cost.
Maintained by Cesanta, the team that develops Mongoose. We have aimed to represent each stack accurately based on public documentation and source code. If you find an error, please open an issue.
Last updated: May 2026.
Stack Summary
| lwIP | FreeRTOS+TCP | Zephyr | NetX Duo | CycloneTCP | Mongoose | |
|---|---|---|---|---|---|---|
| Homepage | nongnu.org/lwip | freertos.org | zephyrproject.org | threadx.io | oryx-embedded.com | mongoose.ws |
| Code | Savannah Git | GitHub | GitHub | GitHub | GitHub | GitHub |
| License | BSD | MIT | Apache 2.0 | MIT | GPLv2 or commercial | GPLv2 or commercial |
| Developer | lwIP developers | Amazon | Zephyr Project | Eclipse ThreadX | Oryx Embedded | Cesanta |
| Drivers | No | Yes | Yes | No | Yes | Yes |
| RTOS | Yes, any | Yes, FreeRTOS | Yes, Zephyr | Yes, ThreadX | Yes, any | Yes, any |
| Baremetal | Yes | No | No | No | Yes | Yes |
| IPv6 | Yes | Yes | Yes | Yes (dual-stack) | Yes | Yes |
| HTTP, WebSocket, MQTT API | No - demos only | No | Yes | Yes, add-ons | Yes | Yes, built-in |
| Protocol API complexity | n/a | n/a | High | High | Medium | Low |
| HTTP API size (*) | n/a | n/a | 20 funcs / 28 structs | 92 funcs / 13 structs | 61 funcs / 13 structs | 21 funcs / 4 structs |
| Source files | src/core, src/api, src/netif/ethernet.c | source/*.c, source/portable/BufferManagement | subsys/net/ip, subsys/net/lib/sockets | common/src/nx_*.c | core, ipv4, ipv6, igmp, mld | net_builtin.c, l2*.c |
| Source size | ~44.4k LoC | ~39.6k LoC | ~47.1k LoC | ~63.0k LoC | ~53.8k LoC | ~3.3k LoC |
| Flash footprint † | ~40–80 KB | ~30–55 KB | OS-coupled | ~40–70 KB | ~60–120 KB | ~20–40 KB |
| Tuning complexity | High | Medium | Medium | High | Medium | Low |
| Since | 2001 | 2014 | 2016 | 2008 | 2013 | 2004 |
HTTP API size is the number of public HTTP API functions and structures counted
in the cloned stack headers. Stacks without a production HTTP API are marked
n/a.
† Flash footprint is approximate for Arm Cortex-M at -Os, TCP/IP core only,
measured on each project's main branch in April 2025. Exact size depends on
enabled features, compiler toolchain, and target MCU. Source line counts were
measured with cloc on .c and .h files in the directories listed under
"Source files", excluding tests, examples, docs, and port-specific code.
Overview
The important question is not only which project can send TCP packets. It is where the stack stops. lwIP and FreeRTOS+TCP stop at TCP - every layer above the socket is your problem. Zephyr, NetX Duo, CycloneTCP, and Mongoose go further, but each brings tradeoffs: OS lock-in, source size, or a commercial license.
lwIP
lwIP is the old workhorse in this list. Adam Dunkels originally wrote it in the early 2000s, and it has since ended up in a huge number of embedded products, MCU vendor SDKs, board examples, and generated networking projects. Most firmware teams using lwIP did not choose it - it came with the SDK. It is the default in ESP-IDF, STM32CubeIDE, NXP MCUXpresso, and most industrial Ethernet BSPs. That ubiquity is both its biggest strength and the main reason it ends up in products where it is not the best fit.
Layer coverage:
| Layer | In a production device | Provided by lwIP |
|---|---|---|
| Application | Your product code | No |
| Application protocols | HTTP, WebSocket, MQTT, OTA, management | No, demos only |
| TLS | TLS library and integration | No |
| TCP/IP stack | IP, ICMP, TCP, UDP, sockets | Yes |
| Driver | Ethernet or Wi-Fi driver from SDK, BSP, or product | No |
The catch is the boundary. lwIP is mostly the TCP/IP stack, not the whole connected-device layer. It does not give you production Ethernet or Wi-Fi drivers, and it does not include TLS. In real products those pieces usually come from the MCU vendor SDK, a board support package, a TLS library, or custom glue code.
The same applies above TCP. lwIP has examples and demo applications, but it does not provide a production HTTP, WebSocket, MQTT, OTA, or management API. Those demos are useful references. They are not a finished product layer, especially once authentication, TLS, diagnostics, error handling, and long-term maintenance enter the picture.
| Pros | Cons |
|---|---|
| Twenty years of production use means the edge cases are well-documented and the sharp bugs are long fixed. | No Ethernet or Wi-Fi drivers. You get those from the MCU vendor SDK, which varies enormously in quality. |
| Solid TCP/IP core - IP, ICMP, TCP, UDP, DHCP, DNS, sockets - with a footprint that fits constrained MCUs. | No TLS. Plan for mbedTLS or WolfSSL plus the glue code, certificate storage, entropy source, and memory tuning. |
| No HTTP, WebSocket, MQTT, or OTA. The demo code in the lwIP tree is not a production API. | |
| Hard to tune: lots of compile-time options that few people really understand. | |
| Hard to debug: when something breaks, it is unclear who to ask; there is no commercial support. |
FreeRTOS+TCP
FreeRTOS+TCP makes the most sense when the product is already built around FreeRTOS. The stack uses the same tasking, timers, memory model, and general runtime assumptions, so network events come through FreeRTOS queues, not a separate event loop. Amazon maintains the stack; it is used in FreeRTOS-based designs on STM32, NXP, Microchip, and Espressif hardware, particularly in AWS IoT-connected products.
Layer coverage:
| Layer | In a production device | Provided by FreeRTOS+TCP |
|---|---|---|
| Application | Your product code | No |
| Application protocols | HTTP, WebSocket, MQTT, OTA, management | No |
| TLS | TLS library and integration | No |
| TCP/IP stack | IP, ICMP, TCP, UDP, sockets | Yes |
| Driver | Ethernet or Wi-Fi driver from SDK, BSP, or product | Yes |
The coupling cuts both ways. FreeRTOS is the platform here, not just the RTOS. HTTP, WebSocket, MQTT, OTA, and device management still need to come from somewhere else - other FreeRTOS libraries, third-party middleware, or your own code.
| Pros | Cons |
|---|---|
| Fits naturally into a FreeRTOS project - same queues, same heap, same timing model as the rest of the firmware. | Useless outside FreeRTOS. Bare-metal, Zephyr, or ThreadX projects should look elsewhere. |
| BSD sockets API keeps the learning curve low for engineers coming from Linux networking. | No TLS, no HTTP, no MQTT. The application layer is entirely your responsibility. |
| RAM footprint scales down well for small MCUs; unused features can be disabled. | Driver quality still depends on the MAC/PHY/DMA combination and the vendor SDK. |
| Amazon publishes MISRA compliance work, CBMC proofs, and protocol test results - useful evidence for safety-critical or audited projects. |
Zephyr
Zephyr is different from lwIP or FreeRTOS+TCP because the networking code is not a library you casually drop into another firmware platform. It is part of the Zephyr OS. In return, you get the stack, sockets, network interfaces, protocol libraries, device model, Kconfig configuration, and driver support moving together. It is the foundation for Nordic Semiconductor's nRF Connect SDK and is supported by STMicroelectronics, NXP, Renesas, and Intel, among others.
Layer coverage:
| Layer | In a production device | Provided by Zephyr |
|---|---|---|
| Application | Your product code | No |
| Application protocols | HTTP, WebSocket, MQTT, OTA, management | Yes, libraries and samples |
| TLS | TLS library and integration | Yes, via Zephyr TLS infrastructure |
| TCP/IP stack | IP, ICMP, TCP, UDP, sockets | Yes |
| Driver | Ethernet or Wi-Fi driver from SDK, BSP, or product | Yes, via Zephyr drivers |
If the firmware is already Zephyr, networking comes with the platform - this is a non-decision. If you arrived hoping to drop a TCP/IP library into a bare-metal project, Zephyr is the wrong tool; you would be adopting an OS to solve a library problem.
| Pros | Cons |
|---|---|
| Everything - networking, drivers, sockets, protocol libraries, TLS, shell, test infrastructure - moves together in one versioned platform. | This is an OS, not a library. You get the kernel, Kconfig, devicetree, and the build system whether you want them or not. |
| Unused features compile out; the IP stack footprint is configurable down to what the product actually uses. | The learning curve is real. Kconfig and devicetree mistakes are silent until something does not work at runtime. |
| Nordic nRF Connect SDK, STM32, NXP, and Renesas all ship Zephyr support - broad board coverage if you commit to the platform. | If the product just needs Ethernet and TCP/IP, Zephyr is a lot of OS for a small networking problem. |
| Strong trajectory for teams building new products on a modern open-source RTOS with a long support horizon. |
NetX Duo
NetX Duo comes from the ThreadX world. It has a native NetX API, BSD-like socket support, and optional add-ons for higher-level protocols such as HTTP and MQTT. For teams already using ThreadX, especially through a silicon vendor SDK, it can be a familiar and well-integrated choice. STMicroelectronics ships it as part of X-CUBE-AZRTOS for STM32; Silicon Labs and Renesas have also offered ThreadX SDK integrations that include NetX Duo.
Layer coverage:
| Layer | In a production device | Provided by NetX Duo |
|---|---|---|
| Application | Your product code | No |
| Application protocols | HTTP, WebSocket, MQTT, OTA, management | Yes, add-ons |
| TLS | TLS library and integration | Yes, via NX Secure |
| TCP/IP stack | IP, ICMP, TCP, UDP, sockets | Yes |
| Driver | Ethernet or Wi-Fi driver from SDK, BSP, or product | No, BSP or port required |
It is not a bare-metal component, though, and the core stack is not a universal driver package. Driver work still lives in the RTOS port, BSP, or hardware integration. Since the move from Azure RTOS to Eclipse ThreadX, check whether your silicon vendor's SDK has actually followed. Several still ship the old Azure RTOS packaging; upstream ThreadX is ahead of what those SDKs include.
| Pros | Cons |
|---|---|
| Solid choice when ThreadX is already in the vendor SDK - STM32 X-CUBE-AZRTOS users get it pre-integrated. | Requires ThreadX. Not an option for bare-metal or non-ThreadX RTOS projects. |
| NX Secure covers TLS; add-ons cover HTTP, MQTT, and other protocols - no need to source those separately. | Ethernet drivers are BSP-specific. The core stack does not include a universal driver package. |
| MIT license under Eclipse ThreadX is a genuine improvement over the old commercial-only Azure RTOS model. | The NetX API is unlike lwIP and BSD sockets. Engineers coming from either will need time to adjust. |
| Vendor SDK support post-Azure-RTOS transition varies by silicon vendor - verify before committing to a new design. |
CycloneTCP
CycloneTCP is the broad commercial-stack option in this comparison. Oryx Embedded ships it as a standalone TCP/IP stack for bare-metal and RTOS projects, with a large set of protocol modules, drivers, and application APIs, including HTTP, WebSocket, and MQTT. It is used in industrial Ethernet controllers, building automation, and medical equipment where a single vendor covering the full networking surface - including TLS, SSH, IPsec, and secure boot - is a project requirement.
Layer coverage:
| Layer | In a production device | Provided by CycloneTCP |
|---|---|---|
| Application | Your product code | No |
| Application protocols | HTTP, WebSocket, MQTT, OTA, management | Yes |
| TLS | TLS library and integration | Yes, with CycloneSSL integration |
| TCP/IP stack | IP, ICMP, TCP, UDP, sockets | Yes |
| Driver | Ethernet or Wi-Fi driver from SDK, BSP, or product | Yes |
Oryx also has adjacent products such as CycloneSSL, CycloneSSH, CycloneCRYPTO, CycloneIPSEC, CycloneACME, and CycloneBOOT. That matters because many products need more than TCP/IP: TLS, SSH/SFTP, cryptography, IPsec, certificate handling, or secure bootloading may all be part of the same device plan.
One vendor owning TCP/IP, TLS, SSH, IPsec, and secure boot removes integration seams - and adds a single point of failure. Closed-source products pay for a commercial license. The protocol breadth is genuinely wide, but so is the source surface and the vendor dependency.
| Pros | Cons |
|---|---|
| Protocol breadth is unmatched: HTTP/HTTPS, WebSocket, MQTT, FTP, CoAP, SNMP, Modbus/TCP, PPP, mDNS, LLMNR - and more. | Closed-source products need a commercial license. Budget for it from the start. |
| Driver list covers a wide range of MCU MACs, PHYs, Ethernet controllers, Wi-Fi modules, and cellular modems. | Oryx is the single vendor for everything. If support or licensing terms change, there is no community fallback. |
| Oryx's companion libraries cover TLS, SSH, IPsec, ACME, and secure boot - one vendor for the full security stack. | |
| Runs on bare metal or any RTOS. No OS coupling. |
Mongoose
Mongoose takes a different angle: it tries to cover the common connected-device path in one small library. Alongside its built-in TCP/IP stack it includes APIs for HTTP, WebSocket, MQTT, DNS, SNTP, TLS integration, OTA-oriented workflows, and device dashboards. It can run on bare metal, with an RTOS, over OS sockets, or on top of another networking stack. It runs on STM32, NXP, Renesas, Infineon, ESP32, Raspberry Pi, and other Cortex-M and Linux targets.
Layer coverage:
| Layer | In a production device | Provided by Mongoose |
|---|---|---|
| Application | Your product code | No |
| Application protocols | HTTP, WebSocket, MQTT, OTA, management | Yes, built-in |
| TLS | TLS library and integration | Yes, built-in or external TLS |
| TCP/IP stack | IP, ICMP, TCP, UDP, sockets | Yes |
| Driver | Ethernet or Wi-Fi driver from SDK, BSP, or product | Yes |
Building the same device with lwIP means sourcing a TLS library, an HTTP server, a WebSocket layer, and an MQTT client separately - then owning that stack across security updates. Mongoose is one library.
| Pros | Cons |
|---|---|
| The easiest to integrate: drop mongoose.c and mongoose.h into your project, create a small mongoose_config.h, then call mg_mgr_init() and mg_mgr_poll() in main(). Done. | Closed-source products need a commercial license from Cesanta. udget for it from the start. |
| TCP/IP, HTTP, WebSocket, MQTT, DNS, SNTP, TLS, Modbus-TCP and device-dashboard in one bunder. No dependencies. | Cesanta is the single vendor for everything. If support or licensing terms change, there is no community fallback. |
| Runs on its built-in stack, OS BSD sockets, lwIP, FreeRTOS+TCP, Zephyr, or NetX - drop it into whatever networking layer already exists. | |
| Simple HTTP, MQTT, and WebSocket APIs that developers and AI agents can use correctly on the first try. |
Decision Guide
Start with the ownership boundary. The expensive part is rarely just TCP. It is who owns the Ethernet or Wi-Fi driver, TLS, certificates, HTTP, MQTT, OTA, diagnostics, security fixes, and field support.
lwIP does not include production TLS, HTTP, WebSocket, MQTT, or Ethernet/Wi-Fi drivers. Choose it when the MCU vendor SDK already provides lwIP integration, the project has existing lwIP code, or the team already has preferred TLS and application-layer components. Do not choose it as a shortcut to a complete connected-device platform; TLS, HTTP, authentication, OTA, and diagnostics remain the team's responsibility.
FreeRTOS+TCP requires FreeRTOS and does not run on bare metal. It does not include TLS or application-protocol APIs. Choose it when FreeRTOS is already the firmware platform and the team wants a FreeRTOS-native sockets stack with MISRA work, CBMC proofs, and protocol testing documented in the public repository. It is a weaker fit for bare-metal, Zephyr, or ThreadX projects.
Zephyr networking is not a drop-in TCP/IP library; it requires the Zephyr kernel, Kconfig, devicetree, and the Zephyr build system. Choose it when the product is already a Zephyr product and you want the OS, drivers, secure sockets, shell tools, and protocol libraries from one platform. It is usually too much commitment if the only gap is a small TCP/IP stack.
NetX Duo requires ThreadX and is not a standalone bare-metal TCP/IP component. Driver integration is BSP-specific. Choose it when ThreadX or Eclipse ThreadX is already part of the target silicon vendor SDK, or when an existing product depends on the NetX API. For new designs, verify current vendor SDK support and maintenance cadence for the exact MCU.
CycloneTCP is licensed under GPLv2 or a commercial license; closed-source products cannot use it without a commercial agreement. Choose it when the product needs broad protocol coverage (Modbus/TCP, SNMP, CoAP, SNTP/NTS, FTP, PPP), many driver options, bare-metal or RTOS flexibility, and a single commercial vendor for TLS, SSH, IPsec, and secure boot alongside TCP/IP. Budget for the larger source surface (~53.8k LoC core) and licensing cost.
Mongoose includes TCP/IP, HTTP, WebSocket, MQTT, DNS, SNTP, TLS, and driver abstractions in a single ~3.3k LoC built-in stack. It is licensed under GPLv2 or a commercial license. Choose it when the product needs a compact connected-device stack with a built-in application layer: embedded web UI, REST endpoints, WebSocket dashboards, MQTT, OTA, and TLS on bare metal, an RTOS, OS sockets, or another TCP/IP stack. It is less suitable when a pure BSD sockets architecture is a hard requirement.
Use Mongoose on top of an existing TCP/IP stack when the low-level network path is already fixed but the product still needs a complete application layer: embedded web UI, MQTT, Modbus/TCP, or OTA.
Security and CRA compliance
If the device ships a web interface - even a local one - the HTTP, WebSocket, and TLS stack is part of the attack surface and falls under the EU Cyber Resilience Act. CRA requires manufacturers to track vulnerabilities, provide security updates for the product's expected lifetime, and maintain an SBOM for all network-exposed components.
Teams building on lwIP or FreeRTOS+TCP and writing their own HTTP and TLS layer on top have created a home-grown framework. There is no upstream to push CVE fixes. Every vulnerability in that custom stack is the product team's to find, patch, document, and ship to the field. That obligation does not end at first shipment.
Using a maintained library - Mongoose, CycloneTCP, or Zephyr - moves the vulnerability tracking and patching work to the library vendor. For a web device dashboard specifically, Mongoose is the smallest attack surface: one library, one SBOM entry, HTTP and WebSocket and TLS in a single auditable codebase with security fixes published upstream. Assembling the same features from lwIP plus separate TLS plus a custom HTTP layer produces three or more SBOM entries, split ownership, and no single point of accountability for security fixes.
Conclusion
The platform choice usually makes the decision for you. FreeRTOS project? FreeRTOS+TCP. Zephyr project? Zephyr networking. If the platform is not fixed, count the layers the team will own past TCP: drivers, TLS, HTTP, MQTT, OTA, diagnostics, and security fixes over the product lifetime. That cost dwarfs the TCP/IP source size comparison.
FAQ
Which embedded TCP/IP stacks work without an RTOS (bare metal)?
lwIP, CycloneTCP, and Mongoose run fine on bare metal. FreeRTOS+TCP will not - it is deeply coupled to FreeRTOS task notifications and heap primitives. Zephyr will not - the networking subsystem is part of the OS kernel. NetX Duo will not: it is built on ThreadX threading. If bare-metal operation is a hard requirement, the list is lwIP, CycloneTCP, and Mongoose.
Does lwIP include TLS?
No, and this is the most common lwIP surprise. lwIP stops at the TCP layer. Secure connections require a separate TLS library (mbedTLS is the usual choice) plus custom glue: certificate storage, entropy source, memory pool tuning, and every error path. Budget a few hundred KB of flash and meaningful integration time on top of the lwIP baseline.
Does lwIP include an HTTP server?
No production one. There is example and demo HTTP code in the lwIP tree, but it has no authentication, no TLS path, no keep-alive management, and no one maintains it to production standard. Teams that need HTTP in a lwIP project either pull in a separate library or build their own on top of lwIP sockets.
What is the difference between lwIP and FreeRTOS+TCP?
Both stop at TCP/IP - neither includes TLS, HTTP, WebSocket, or MQTT. The main difference is coupling: lwIP runs on any RTOS or bare metal; FreeRTOS+TCP integrates tightly with FreeRTOS task notifications, heap, and timers and will not run outside FreeRTOS. FreeRTOS+TCP also ships Ethernet driver abstractions; lwIP does not - drivers come from your MCU vendor SDK.
Which embedded TCP/IP stack uses the least flash memory?
Mongoose - roughly 20–40 KB on Cortex-M at -Os for the full built-in stack including HTTP, WebSocket, and MQTT. lwIP and FreeRTOS+TCP compile smaller in isolation (40–80 KB and 30–55 KB respectively) but those numbers exclude TLS and application protocols, which add another 50–200 KB depending on what you wire in. Compare the full application-layer flash cost, not just the TCP/IP core.
Which embedded TCP/IP stack includes a built-in HTTP server, WebSocket, and MQTT API?
Zephyr, NetX Duo (via add-ons), CycloneTCP, and Mongoose all cover HTTP, WebSocket, and MQTT. lwIP and FreeRTOS+TCP do not - you are on your own above the socket layer. Among the four that do, Mongoose is the only standalone two-file library; the others bring their respective OS or middleware ecosystem with them.
Can Mongoose run on top of lwIP?
Yes. Set MG_ENABLE_LWIP=1 and Mongoose uses lwIP sockets as its network layer
instead of its own built-in stack. This is the right setup for ESP-IDF (ESP32)
and STM32 CubeIDE projects where lwIP is already the platform choice. You keep
the existing TCP/IP integration and add Mongoose's HTTP, WebSocket, MQTT, and
TLS on top.
What is the difference between Mongoose and lwIP?
lwIP is a TCP/IP stack: IP, ICMP, TCP, UDP, DHCP, DNS - about 44,400 lines of core C. You wire in TLS, HTTP, MQTT, and everything above the socket layer yourself. Mongoose covers that whole path - TCP/IP, HTTP, WebSocket, MQTT, DNS, SNTP, TLS, and driver abstractions - in roughly 3,300 lines for the built-in stack. The tradeoff is license: lwIP is BSD, Mongoose is GPLv2 or commercial.
Which embedded TCP/IP stacks support IPv6?
All six in this comparison support IPv6. NetX Duo is explicitly dual-stack from the ground up - that is what "Duo" means. Zephyr has mature IPv6 and 6LoWPAN support for mesh networking. For the others, IPv6 is an optional build-time feature; confirm it is enabled and tested on your specific target before depending on it.
What license does lwIP use?
Modified BSD, similar to 3-clause BSD. You can ship it in a closed-source commercial product without royalties and without publishing your changes. That is one reason it is the default in so many MCU vendor SDKs.
What license does Mongoose use?
GPLv2 or commercial. Open-source projects compatible with GPLv2 use it for free. Closed-source or proprietary products need a commercial license from Cesanta - that covers most shipping embedded products. The commercial license also includes support.
Does FreeRTOS+TCP support bare metal?
No. FreeRTOS+TCP uses FreeRTOS task notifications, queue primitives, and heap management throughout. Extracting it from FreeRTOS is not a practical option. For bare-metal TCP/IP, lwIP, CycloneTCP, or Mongoose are the straightforward alternatives.
Which TCP/IP stacks are RTOS-agnostic?
lwIP, CycloneTCP, and Mongoose. All three run on bare metal or with any RTOS. FreeRTOS+TCP requires FreeRTOS. Zephyr requires the Zephyr OS. NetX Duo requires ThreadX. If the RTOS choice is not yet locked in, pick from the first three.
What is the smallest embedded TCP/IP stack by source code?
Mongoose's built-in TCP/IP layer - approximately 3,300 lines of C. For context: other stacks are 10x or more larger. All counts are core .c and .h files excluding tests, drivers, examples, and port code. Mongoose is also the only stack that combines TLS 1.3 and protocols, all delivered as two files.