Ethernet WiFi Router on a Pi Pico 2W: What's Possible

Why the Raspberry Pi Pico 2W Is an Interesting Routing Platform

The Raspberry Pi Pico 2W ships with the RP2350 microcontroller, 520 KB of on-chip SRAM, 16 MB of QSPI flash, and a CYW43439 wireless chip delivering 802.11n (Wi-Fi 4) at 2.4 GHz. The board retails at approximately $6 from the Raspberry Pi Foundation — making it, by a substantial margin, the cheapest platform combining a dual-core ARM CPU and a wireless radio on a single PCB. That combination has drawn sustained maker-community attention toward one compelling experiment: can this $6 board function as a Wi-Fi-to-Ethernet NAT router?

The short answer from community documentation is for light workloads, yes — with clear caveats about throughput ceilings and operational complexity. For IoT network segmentation, air-gapped lab setups, or learning embedded networking protocols from first principles, the Pico 2W router project is a legitimate and functional build. For household broadband sharing across a dozen devices, commercial hardware wins by a wide margin and at comparable or lower cost.

---

What the RP2350 Brings to the Task

The RP2350 is a dual-core ARM Cortex-M33 running at up to 150 MHz per core, per the RP2350 datasheet. The Cortex-M33 adds hardware DSP instructions and TrustZone security extensions compared to the older Cortex-M0+ in the original RP2040 — meaningful for both performance and eventual secure-boot configurations.

For routing purposes, the dual-core architecture is the key structural advantage. Community build documentation consistently describes the same division of labor: one core manages the CYW43439 Wi-Fi stack and handles interrupt-driven radio events, while the second core runs the lwIP packet-forwarding loop and NAT table lookups. The 520 KB SRAM is enough to hold the lwIP buffer pool, a NAT translation table for a few dozen hosts, and DHCP lease state simultaneously — though headroom is tight.

One fundamental constraint the RP2350 shares with all microcontrollers in its class: no MMU. The absence of a memory management unit means a full Linux kernel — and therefore OpenWRT in its standard form — cannot run on this chip. Routing must be implemented bare-metal or on a lightweight RTOS such as FreeRTOS. This is not a deficiency of the Pico 2W specifically; it reflects the architectural tradeoffs that keep microcontrollers at $6 rather than $60.

---

Hardware You Need Beyond the Pico 2W Itself

The Pico 2W provides Wi-Fi via the CYW43439, but carries no wired Ethernet MAC or PHY. Community router builds documented on Hackaday and the Raspberry Pi Forums converge on two hardware approaches for the wired side:

SPI Ethernet via Wiznet W5500 (Recommended)

The Wiznet W5500 is the most referenced SPI Ethernet chip in community Pico router builds. Per Wiznet's published ioLibrary documentation, the W5500 implements a full hardware TCP/IP stack internally, offloading the RP2350 from per-packet processing overhead. It connects over four to five GPIO pins using SPI0 or SPI1 and supports 10/100BASE-T with RJ45 magnetics on most breakout boards. Breakout boards are available from third-party suppliers for $3–8.

Bit-Banged RMII via LAN8720 (Advanced, Lower Ceiling)

A smaller number of community experiments have connected an LAN8720 Ethernet PHY via bit-banged RMII. Per Raspberry Pi Forum discussions, this approach is substantially more CPU-intensive than the W5500 path, because every byte transfer consumes RP2350 cycles that compete with Wi-Fi interrupt handling. Real-world throughput on this path is reported lower than the W5500 route and is generally not recommended for practical builds.

Downstream Switch Expansion

Because the Pico 2W presents a single wired port through the W5500, a small unmanaged switch on the LAN side fan the connection out to multiple wired clients without any additional processing on the microcontroller. A TP-Link TL-SG105 5-port Gigabit switch ($12.11, ASIN B00A128S24) is a natural companion here — well within the build budget and widely available. For wired runs between the Pico 2W WAN port and upstream equipment, a Jadaol Cat 6 Ethernet cable ($19.49, ASIN B01F4XBTH0) keeps signal integrity solid over distances up to 75 feet.

---

Software Stack: lwIP NAT on FreeRTOS

The routing software in community builds is not a port of OpenWRT — that would require a Linux kernel. Instead, builds are constructed on top of lwIP (Lightweight IP), which ships as part of the official Raspberry Pi Pico SDK. The Pico SDK's picow_access_point example in the official pico-examples repository is the canonical starting point: it establishes a DHCP-backed 802.11n AP in under 200 lines of C using the cyw43_arch_lwip_nothread or threadsafe-background mode.

Turning that AP example into a router requires bridging the Wi-Fi netif to the W5500 Ethernet netif with NAT enabled. The component that enables this is the ip4_napt NAT extension — a community-maintained addition to lwIP (search GitHub for lwip-nat or pico-w-nat) that implements IPv4 network address and port translation.

The resulting stack, at a high level:

This is a purpose-built embedded firmware, not a reconfigured commercial router OS. Configuration means editing C header files and recompiling — there is no web UI or CLI out of the box, though community projects have added rudimentary HTTP status pages using the lwIP HTTP server module.

---

Performance Reality: What Community Builds Actually Report

The CYW43439's 802.11n (HT20) PHY-layer maximum is 72.2 Mbps — a figure derived from the IEEE 802.11n standard's single-spatial-stream, 20 MHz channel rate, confirmed in the Infineon CYW43439 product page. This is a radio-layer ceiling, not an application throughput figure.

Actual NAT throughput — what a device connected to the Pico 2W's Wi-Fi AP can push through to the wired WAN side — is limited by RP2350 CPU cycles available for packet processing. Community measurements documented across Hackaday build logs and Raspberry Pi Forum threads consistently place practical NAT throughput in the 5–20 Mbps range under normal conditions. The bottleneck is per-packet CPU overhead in software NAT, not the radio or the SPI bus.

For comparison, a budget commercial router like the TP-Link TL-WR841N achieves 50–70 Mbps NAT throughput via a dedicated MIPS CPU with hardware NAT assist. The Pico 2W build is not competing at that level. It competes on cost, form factor, and educational value.

---

Where This Build Makes Practical Sense

IoT network isolation. A dedicated SSID for smart-home sensors and switches, bridged to a wired VLAN port, is well within the Pico 2W's capability. Packet rates from temperature sensors, smart plugs, and light controllers are trivially low — aggregate throughput rarely exceeds 1 Mbps even across dozens of IoT endpoints.

Air-gapped and offline environments. The Pico 2W router boots in under two seconds, requires no cloud connectivity, and can be pre-flashed and deployed in field locations where a commercial router is unavailable. This applies to industrial monitoring setups, remote data collection rigs, and educational kits.

Learning embedded networking. For developers who want to understand NAT, DHCP, and IP forwarding at the protocol level — rather than through an abstracted CLI — the Pico 2W stack is short enough to read, modify, and debug in a single session. This is a deeper dive than the Linux Fu: Upcycling an Old Router approach, which builds on a full Linux networking stack, but the underlying concepts map directly.

Captive-portal testbeds. Community projects have implemented lightweight captive portals — serving an HTTP terms page before issuing a DHCP lease — using lwIP's HTTP server alongside the NAT stack. This is a realistic pattern for conference or event Wi-Fi gating in low-traffic contexts.

---

How It Compares to Other Embedded Router Platforms

The Pico 2W and ESP32 occupy the same niche: sub-$10 boards capable of light NAT routing with similar throughput ceilings, limited by software stack overhead rather than radio capacity. GL.iNet and TP-Link parts run full Linux and deliver three to five times the throughput at two to three times the power draw.

The same RP2350 chip that handles routing in this build is capable of surprisingly diverse compute tasks — the Amstrad CPC emulator port to Raspberry Pi Pico 2 demonstrates cycle-accurate 8-bit emulation on the same silicon. Routing is comparably demanding in a different way: less compute-intensive per cycle, but latency-sensitive and interrupt-driven.

For readers curious about how AI edge hardware handles the router/compute boundary at the other end of the power curve, the Perplexity local-or-cloud hardware overview and the Cactus hybrid router project with Gemma4-2B are useful reference points.

---

Security Posture of an Embedded Router

The CYW43439 supports WPA2-Personal out of the box via the cyw43 driver and lwIP's WPA supplicant integration. WPA3-SAE support in community Pico 2W builds is experimental as of mid-2026 — the hostapd configuration layer required for SAE has not been fully ported to the RP2350's constrained environment.

Key security considerations for builders:

• No automatic firmware updates. Updating the Pico 2W router firmware requires physical USB access or a JTAG programmer. Community projects have documented UF2 drag-and-drop update workflows that reduce friction but do not eliminate the requirement for physical or local network access.
• TrustZone exists but is opt-in. The RP2350 includes ARM TrustZone support for secure boot, per the RP2350 datasheet. Enabling it requires toolchain configuration that most community router builds skip. An attacker with physical board access can reflash a default build without cryptographic resistance.
• Default credentials in sample code. Community router examples ship with hardcoded SSID names and PSKs in the C source. Any deployment must change these before the device connects to any network with untrusted hosts — this is the most common operational security failure in embedded router deployments.
• No stateful packet inspection. Deep packet filtering at any meaningful rate is not feasible on this CPU. The NAT table provides basic isolation; application-layer filtering is out of scope.

The DualSense PC dongle build on Pico (build guide here) illustrates how the same RP2350 handles tight security boundaries in a different peripheral role — the firmware isolation model is comparable.

---

Bill of Materials

Total for a functional prototype: approximately $45–55. This is not necessarily cheaper than a purpose-built $20 commercial router — the value proposition is educational depth and deployment flexibility, not bill-of-materials cost.

---

Key Resources for Getting Started

Documentation for this project is distributed across several community repositories and forums:

1. Raspberry Pi Pico W SDK examples — The picow_access_point example in the official pico-examples repo is the required starting point for the Wi-Fi AP side.
2. Wiznet W5500 ioLibrary — The official WIZnet driver library handles SPI communication and provides the lwIP netif integration.
3. ip4_napt NAT extension — Search GitHub for lwip-nat or pico-w-nat for community repositories implementing IPv4 NAT forwarding within lwIP.
4. lwIP project documentation — The lwIP project page covers the buffer management and netif architecture that underpins all of the above.
5. Raspberry Pi Forums — The "Pico W as a router" thread in the Raspberry Pi general forum aggregates community measurements and wiring diagrams.

Builders who want to understand NAT and DHCP at the Linux layer first — before working at the bare-metal lwIP level — will find the Linux Fu: Upcycling an Old Router guide a useful conceptual primer.

---

Citations and sources

• Raspberry Pi Pico 2W product page — Raspberry Pi Foundation
• RP2350 datasheet — Raspberry Pi Foundation
• pico-examples official SDK repository — Raspberry Pi Foundation / GitHub
• ioLibrary Driver — WIZnet / GitHub
• lwIP Lightweight IP project — Savannah GNU
• CYW43439 product page — Infineon Technologies
• Hackaday — embedded networking and Pico W build coverage

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.