Introducing wolfIP — a tiny, safe TCP/IP stack for embedded and safety‑critical systems

If you’ve ever tried to drop a full‑blown networking stack into a deeply embedded target, you know the drill: memory budgets get tight, timing gets squirrely, and dynamic allocation can turn certification efforts into a slog. wolfIP is our answer: a compact TCP/IP stack built with embedded systems in mind, that favors determinism over surprise. No malloc. No hidden threads. Just pre‑allocated buffers, a fixed number of sockets, and a BSD‑like non‑blocking socket API that’s easy to integrate.

wolfIP delivers a small, predictable networking core that pairs naturally with wolfSSL for end‑to‑end secure connectivity — and its static memory model makes it attractive for safety‑critical projects aiming at standards like DO‑178C.

Why wolfIP

Determinism by design. wolfIP allocates all working memory at compile time. That means you size your RX/TX pools and socket table up front and the runtime footprint never drifts. For developers working under tight RAM constraints — or subject to verification artifacts — this is a big deal.
Tiny, embedded‑first footprint. The stack targets microcontrollers and resource‑constrained systems. It currently supports endpoint mode (host only, no routing) with a single network interface, which is exactly what most MCUs need.
Safety‑friendly. Eliminating dynamic allocation and using pre‑defined buffer counts helps with worst‑case analysis and stack/heap audits. Combined with wolfSSL’s history of safety and security certifications, wolfIP gives you a clean path toward high‑assurance designs.
By design, it plays great with wolfSSL. The socket and callback model map cleanly to wolfSSL’s I/O hooks, making it straightforward to add TLS 1.3 on top of wolfIP for secure transport.

What’s inside (today)

  • IPv4 host stack (endpoint mode)
  • ARP, ICMP (echo replies), DHCP client, DNS client
  • UDP (unicast)
  • TCP (RFC 793) with support for Timestamps and MSS options
  • BSD‑like, non‑blocking sockets with custom I/O callbacks
  • No dynamic memory allocation
    • Fixed number of concurrent sockets
    • Pre‑allocated RX/TX packet buffers in static memory

This mix keeps the stack small while covering the embedded sweet spot: device discovery, basic IP services, UDP telemetry/command channels, and reliable TCP streams for control or TLS.

How small code base and static memory help safety certification

Safety standards such as RTCA DO‑178C reward designs that are predictable and analyzable. When your network stack:

  • does not allocate at runtime,
  • uses fixed‑size, pre‑allocated pools,
  • exposes clear execution paths and bounded resources,

you basically simplify your worst‑case memory and timing analysis and reduce the effort to demonstrate determinism. In short: fewer surprises, more artifacts you can point to. wolfIP’s design aligns with these expectations and pairs naturally with wolfSSL / wolfCrypt, which already offers DO‑178C (up to DAL-A) artifacts for specific use-case scenarios.

A natural fit with wolfSSL

Need TLS on top of TCP? You can layer wolfSSL directly over wolfIP sockets using the familiar wolfSSL I/O callbacks. The result is a compact, all‑wolf stack that scales from tiny MCUs to robust RTOS and MPU environments — with a single vendor and API style end‑to‑end.

Getting started

  1. Clone the repository and build the provided examples/targets.
  2. Size your stack: edit the configuration header to set the maximum number of sockets and RX/TX buffer sizes according to your use case.
  3. Hook up your NIC/driver by implementing the simple callback interface for transmit/receive and link status.
  4. No drivers? Use our tap interface support, to test how the stack communicates with your POSIX system.
  5. (Optionally) Add TLS: bind your wolfIP socket to a WOLFSSL object and use wolfSSL’s send/recv callbacks to secure the connection with TLS 1.3.
  6. Check the provided https examples, tested with curl.

Because wolfIP is single‑interface and endpoint‑only, bring‑up is quick: DHCP + DNS for client use cases, or static IP for fixed installations. ICMP echo replies are built in, so you can ping your device as soon as the link is up.

Who should consider wolfIP

  • MCU and bare‑metal projects that need predictable RAM and code size
  • RTOS deployments where you want fine‑grained control over memory and scheduling
  • Safety‑critical systems (avionics, industrial, medical) that benefit from static memory and bounded resources
  • Teams who want a tight TLS integration with wolfSSL from a single vendor

Roadmap towards a stable release

wolfIP is active and evolving. Here are a few items recently developed, which are currently under review:

  • Multiple datalink interfaces: support for an array of interfaces, with legacy APIs defaulting to the first (non‑loopback) interface; adds a loopback device and simple traffic forwarding between interfaces.
  • IPsec ESP (transport mode): initial ESP encrypt/decrypt path to enable network‑layer protection for selected flows, plus packet debugging helpers (Ethernet/IP/TCP/ESP)

If you have a platform, NIC, or feature you’d like to see prioritized, drop us a line at facts@wolfssl.com.

Try it now

If you’re evaluating TCP/IP stacks for resource-constrained embedded or safety‑critical systems and want deterministic memory, strong TCP, and seamless TLS, give wolfIP a spin. We think you’ll like how small and predictable networking can be.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now