If you have ever tried to drop a full networking stack into a deeply embedded target, you know the drill: memory budgets get tight, timing gets unpredictable, and dynamic allocation can turn certification efforts into a slog. wolfIP is our answer: a compact TCP/IP stack that favors determinism over surprise, and standard interfaces over complex namespaces. In order to demonstrate the adherence to the BSD API, the stack is already running as a userspacewoler of sockets, and a BSD like blocking and non blocking socket API that is straightforward to integrate.
Why wolfIP
- Determinism by design
wolfIP allocates all working memory at compile time. You size your RX and TX pools and socket table up front and the runtime footprint never drifts. That matters for tight RAM targets and for producing verification artifacts you can actually defend. - Tiny, embedded first footprint
wolfIP is built for endpoint devices. It focuses on the features embedded products actually need, without dragging in routing stacks or features that add code and testing surface area. - Safety friendly architecture
Eliminating dynamic allocation and using pre-defined buffer counts helps with worst case analysis and stack and heap audits. The result is a networking core that is easier to bound and easier to argue about. - Designed to pair with wolfSSL
wolfIP maps cleanly to wolfSSL I O hooks, so layering TLS 1.3 on top of wolfIP sockets stays small and predictable.
Operating systems
Supported today
- Bare-metal embedded targets
- Linux userspace TCP/IP replacement
- FreeBSD userspace TCP/IP replacement
- macOS userspace TCP/IP replacement
Planned and in progress
- FreeRTOS
- Zephyr
- Azure RTOS ThreadX
- NuttX
- RTEMS
- Any commercial RTOS targets where a fixed memory, single stack integration is valuable (examples: VxWorks, QNX)
Silicon and network interfaces
Supported today
- STM32 Ethernet (MAC plus PHY) via a dedicated driver path
Planned and in progress
- Additional MCU Ethernet MAC families (for example NXP i.MX RT, Microchip SAME70 class, Renesas RA class, and similar)
- Broader PHY and interface coverage (RMII and MII style MAC to PHY hookups)
- More reference drivers and BSP integrations driven by customer demand
What is inside (current feature set)
wolfIP currently includes:
- IPv4 host stack
- ARP
- ICMP (echo replies plus TTL exceeded)
- DHCP client
- DNS client
- UDP
- TCP with:
- MSS option
- Timestamps option
- Window Scaling option
- Congestion control: slow start, congestion avoidance, fast retransmit
- HTTPS server, showing the seamless integration with wolfSSL for TLS up to TLS1.3
- BSD like, non blocking sockets
- No dynamic memory allocation
- Fixed number of concurrent sockets
- Pre allocated RX and TX packet buffers in static memory
- Optional multi interface support for routing and basic traffic forwarding (when enabled)
This mix covers the embedded sweet spot: discovery and basic IP services, UDP telemetry and command channels, reliable TCP streams for control, and a clean path to HTTPS endpoints on resource constrained devices.
wolfIP vs lwIP
lwIP is the best known lightweight TCP/IP stack, and it is widely deployed. wolfIP is intentionally narrower and more deterministic, and the engineering tradeoffs are different.
Key differentiators that tend to matter in embedded product work and certification programs:
- 4x Smaller TCP/IP core code bas
lwIP implements the core component of the stack in about 17000 lines of code. wolfIP implementation for the same protocol is currently about 4200 lines. This is mostly thanks to the simpler data structures used for the internal representation of frames, packets and protocols. - Hard deterministic memory model by default
wolfIP is built around compile time sizing, fixed pools, and a fixed socket table. This is the default, not an optional build style. - Userspace stack replacement on POSIX
wolfIP can replace the system TCP/IP for a process in userspace using library interposition. This is useful for integration testing, reproducibility, and debugging without rewriting your application networking code, and proves our commitment to the POSIX/BSD standard, across different protocol families, to interact with the stack. - Security first path that stays small
wolfIP includes an HTTP server and an HTTPS server flow that uses wolfSSL for TLS, keeping the full secure connectivity story within one vendor stack and one set of integration patterns. - A smaller code and audit surface by design
lwIP is a mature, broad stack with a large codebase and feature set. wolfIP focuses on an embedded endpoint profile and keeps the supported protocol set tight. In practice, that can reduce the amount of code you need to review, test, and qualify for high assurance programs.
CRA support for wolfIP
The EU Cyber Resilience Act is changing expectations for connected products. Whether you ship into the EU directly or your product ends up there through an OEM channel, security maintenance, vulnerability handling, and traceable update processes will increasingly be table stakes.
wolfIP is being developed with CRA minded product needs in view, including:
- deterministic configuration that is easier to document and reproduce
- clear boundaries on enabled features and exposed services
- an implementation approach that supports secure by default deployments
- a practical path to secure update and long term maintenance when paired with wolfSSL and your firmware update mechanism
wolfIP and DO 178C certifiable designs
RTCA DO 178C rewards systems that are predictable, analyzable, and testable. wolfIP aligns naturally with those goals:
- no runtime allocation
- fixed size pools
- bounded resource usage (sockets, buffers, timers)
- single interface endpoint profile (and optional, explicit multi interface behavior when enabled)
For aerospace and other safety critical domains, this minimalist, static architecture reduces surprises in worst case timing and memory analysis and helps you build credible verification artifacts. In short: fewer moving parts, more evidence.
Getting started
- Clone the repository and build the provided examples and targets.
- Size your stack by configuring the maximum number of sockets and RX and TX buffer sizes.
- Hook up your NIC driver by implementing the simple callback interface for transmit, receive, and link status.
- If you do not have hardware ready, use the tap interface support to test against a POSIX host.
- Optionally add TLS by binding wolfIP sockets into wolfSSL I/O callbacks and enabling HTTPS server flows.
Want to try it or influence the roadmap?
If you have a platform, NIC, or RTOS port you would like to see prioritized, contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now