Zephyr is a great RTOS for embedded development: broad board support, a familiar BSD socket interface, and a flexible networking subsystem. However, teams building long-lived connected products often need more than a default network stack: they need predictable memory behavior, modern TCP features, and tight alignment with their security architecture.
Our new wolfIP port, replacing Zephyr’s TCP/IP stack, provides a static memory, predictable implementation that perfectly fits the existing interfaces and device drivers.
With this port, Zephyr applications can continue using standard socket calls while wolfIP owns IPv4, TCP, UDP, ARP, ICMP, and optional DHCPv4 behavior on selected interfaces, but with increased number of features and level of quality assurance. Zephyr remains the RTOS and driver environment; wolfIP becomes the system’s TCP/IP stack.
Integration approach: one Interface, one stack
Replacing a TCP/IP stack is not just about intercepting send() and recv().
A real stack owns ARP state, packet parsing, TCP state transitions, retransmissions, routing decisions, and next-hop selection. Splitting that responsibility across two stacks creates confusion fast: which stack owns the MAC? Which one handles ARP? Which one decides the next hop?
The wolfIP Zephyr integration takes the cleaner route: one interface, one stack owner.
To make that possible, the port introduces a custom Zephyr L2 module, NET_L2_WOLFIP. Instead of hooking late in the socket path, traffic is diverted before Zephyr’s native IPv4/TCP/UDP path takes over. Incoming Ethernet frames are preserved with the Ethernet header intact and passed to wolfIP. Outgoing packets are built by wolfIP and sent through the Zephyr Ethernet driver. All existing zephyr network interfaces are supported out of the box.
Applications still use the familiar Zephyr socket API:
socket(); bind(); connect(); send(); recv(); poll(); close();
The application experience stays the same. The network stack underneath changes completely.
Static Memory, Predictable Networking
wolfIP was designed for embedded systems where memory behavior must be clear, bounded, and reviewable.
Unlike stacks that depend on runtime allocation of packet buffers or socket resources, wolfIP uses a static memory model. Sockets and buffers are sized ahead of time and pre-allocated. No malloc. No surprise heap behavior. No “it depends on the state of the pool” answer when analyzing runtime resource use.
That is a major advantage for small MCUs, but it is also important for safety-oriented and compliance-driven products. Static allocation makes it easier to reason about worst-case behavior, buffer ownership, resource exhaustion, and long-term maintainability.
For teams looking at certification, auditability, or long product lifecycles, this is exactly the kind of design decision that matters.
Better TCP for Real Embedded Networks
TCP performance is not just about link speed. On real networks, especially when latency is involved, TCP options matter.
Without TCP window scaling, the advertised receive window is limited by the 16-bit TCP window field, which caps it at about 64 KiB. That can limit the bandwidth of a single TCP connection on higher-latency or higher-throughput links. Window scaling is the standard way to go beyond that limit.
wolfIP includes the TCP features embedded developers increasingly expect from a modern, compact stack:
| TCP capability | wolfIP | Zephyr native TCP |
|---|---|---|
| MSS option | Yes | Yes |
| TCP timestamps | Yes | No |
| Window scaling | Yes | No |
| SACK | Yes | No |
| Congestion control | Yes | Yes |
| Fast retransmit | Yes | Yes |
| Static, compile-time socket/buffer sizing | Yes | No |
This is one of the strongest reasons to look at wolfIP for Zephyr. You get a small, allocation-free stack with modern TCP behavior, while keeping the same Zephyr socket-facing application model.
Why This Matters for CRA
The EU Cyber Resilience Act (CRA) is changing the expectations for connected products sold in Europe. It introduces mandatory cybersecurity requirements for products with digital elements, including secure design, vulnerability handling, updates, and lifecycle responsibilities.
The main CRA obligations apply from December 2027, with reporting obligations beginning earlier. For connected embedded devices, this means cybersecurity is no longer just a best practice. It is becoming a market-access requirement.
wolfSSL is committed to providing CRA-compliant support across the product line. That includes helping customers build connected devices around security-focused, maintainable, well-supported components, from TLS and cryptography to boot, secure update, and now TCP/IP with wolfIP.
For teams preparing products for the EU market, standardizing on wolfSSL components can simplify the path toward long-term security maintenance and compliance readiness.
Why This Is Useful in Zephyr
The goal is not to run a second TCP/IP stack beside Zephyr. The goal is to make wolfIP the owner of the network path for selected interfaces while preserving the Zephyr application model.
This gives teams a practical way to:
- keep Zephyr’s RTOS, driver, net_if, and socket infrastructure,
- standardize TCP/IP behavior across Zephyr and non-Zephyr targets,
- align networking with the wolfSSL ecosystem,
- avoid split ownership between RTOS networking and application security components,
- and build toward deterministic, compliance-ready connected products.
The same work also adds IPv4 routing table support to wolfIP, including static routes and longest-prefix-match lookup. That keeps interface and next-hop decisions inside the same stack that owns packet transmission.
Current Scope
The current integration targets Zephyr v4.4.0 and focuses on IPv4. It replaces the native IPv4, TCP, UDP, ARP, ICMP, and DHCPv4 path on selected interfaces. IPv6 is not part of this integration at this stage.
For evaluation, the port includes a native_sim sample using a TAP-backed echo application. This makes it easy to validate the data path and socket behavior before moving to hardware.
A set of GPLv3 patches for zephyr is available in wolfIP github repository, with an extended technical guide explaining the port in details
Conclusion
The wolfIP Zephyr integration gives embedded developers an exciting new option: keep Zephyr where it is strong, but move TCP/IP ownership into wolfIP.
For teams already using wolfSSL components, this creates a more consistent networking and security story across platforms. For teams focused on predictable memory, modern TCP behavior, CRA readiness, or safety-oriented systems, wolfIP provides a compact, static-memory TCP/IP stack designed with embedded reality in mind.
If you are evaluating TCP/IP options for Zephyr, small embedded devices, or connected products heading toward the EU CRA timeline, wolfIP is worth a serious look.
For more information about wolfIP, wolfSSL, or commercial support and integration options, contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now