Community Over Code · Glasgow 2026

WireGuard for Apache NuttX

Bringing Secure Remote Access to Embedded Devices

Satoru AkitaSony Semiconductor Solutions

SLIDES

About Me

Satoru Akita — edge AI engineer at Sony Semiconductor Solutions, working with Apache NuttX from the application side.

my icon on social media

Japan

My background & activities

A model rocket on its launch pad — Rocket / Aerospace Engineering

A DNA nanostructure seen with cryo-TEM — DNA Nanorobotics

Test chips on a silicon wafer — Semiconductor Research

With a humanoid robot at a hackathon — Robots

Volunteering at an open-source conference — Open-Source Conference Volunteer

Satoru Akita @fox_aki310ooooo

2 / 36

First, a little about me.

I am an edge AI engineer at Sony Semiconductor Solutions. I use Apache NuttX from the application side. I was born in Nagoya, I studied in Sendai, and now I live in Kawasaki.

My background is wide. At university, I studied mechanical and aerospace engineering, including rockets. My undergraduate research was DNA nanorobotics, and my master's research was on semiconductors. I also build robots, and I volunteer at open-source conferences.

This project is the latest stop on that road. Let me show you the project.

OPTIONAL: The conferences are Open Source Summit Japan and KubeCon. I also build robots at hackathons.

OPTIONAL: My road to this project went through molecular robots, computer vision, edge AI cameras, and embedded systems on SPRESENSE.

OPTIONAL: On social media, I am the fox in this picture. I also wrote a book about open source.

Agenda

Overview & background

Project origins · NuttX & Sony · my experience

~5 MIN

The Problem & Solution

Remote access challenge · why WireGuard

~4 MIN

The Development Plan

Reuse wireguard-lwip · adapt to NuttX

~2 MIN

Version 1: Application-Based Implementation

First working tunnel · debugging challenges

~4 MIN

Version 2: The Kernel Driver

Why a driver · integration challenges · validation

~5 MIN

Live Demo

Secure remote access · Stack-chan control

~3 MIN

Summary & Reflections

Achievements · personal reflections · community

~4 MIN

3 / 36

Agenda

Overview & background

Project origins · NuttX & Sony · my experience

~5 MIN

The Problem & Solution

Remote access challenge · why WireGuard

~4 MIN

The Development Plan

Reuse wireguard-lwip · adapt to NuttX

~2 MIN

Version 1: Application-Based Implementation

First working tunnel · debugging challenges

~4 MIN

Version 2: The Kernel Driver

Why a driver · integration challenges · validation

~5 MIN

Live Demo

Secure remote access · Stack-chan control

~3 MIN

Summary & Reflections

Achievements · personal reflections · community

~4 MIN

PART 14 / 36

Project Overview

Lightweight VPN

Bring WireGuard to NuttX-based microcontrollers.

Virtual interface

Use wg0 as a network interface for the VPN tunnel.

Secure communication

Exchange encrypted packets with WireGuard peers over UDP.

Takeaway

NuttX devices can now talk IP securely, like any other WireGuard peer.

PART 1 · 1/55 / 36

How it started

MID FEBRead the GSoC idea list. Started to study.

EARLY MARProposed the plan.

MAR 20Alan told me about this conference. Submitted a CfP.

EARLY APRSent the GSoC proposal.

EARLY MAYCfP accepted. GSoC proposal not selected. Kept going anyway.

OCT 11–14Glasgow — this talk.

FEB

MAR

APR

MAY

JUN

JUL

AUG

SEP

OCT

MAY – JULStudied NuttX and WireGuard, explored approaches

AUGV1

SEP –V2

VERSION 1Application (FLAT) · hardware testing

→

VERSION 2Kernel driver

DEVELOPMENT

Takeaway

The GSoC proposal was not selected, but the work went on.

PART 1 · 2/56 / 36

A Quick Overview of Apache NuttX

Apache NuttXA small RTOS for microcontrollers

POSIX-like real-time OS
Small footprint
Broad hardware support15+ CPU architectures · 300+ boards
Apache open-source project

RTOS	Standard APIs
FreeRTOS	Its own task API
Zephyr	Own API, optional POSIX layer
NuttX	POSIX-like by design

Used in real devices

SonyAudio products, SPRESENSE

A Fitbit Charge 3 fitness tracker on a wrist — **Fitbit**Fitness trackers (Charge 3 / 4)

PX4Drone flight controllers

The SORA-Q lunar robot — **SORA-Q**Lunar robot on Japan's 2024 Moon mission

1,000+

Xiaomi OpenVelaReported products: watches, speakers, displays

Takeaway

Apache NuttX is a POSIX-like RTOS used in a wide range of real-world embedded devices.

Sources: nuttx.apache.org/market-share · “NuttX at Fitbit” (2020) · docs.px4.io · Sony Developer Blog. Images: Sony; Wikimedia Commons (Charge 3: Vemerce, CC BY-SA 4.0; Pixhawk: Pixhawk project, CC BY 4.0; SORA-Q: テレストレラッソ, CC BY-SA 4.0)

PART 1 · 3/57 / 36

NuttX is a real-time operating system for small devices. It follows POSIX, so it feels familiar to Unix programmers. It supports many CPU architectures and boards, and it is an Apache open-source project.

FreeRTOS and Zephyr are good RTOSes too. For this project, the POSIX-like API matters. With pthreads, sockets and files, a VPN can become a normal network device.

NuttX is also used in real commercial products. You can see some examples on the screen: audio products, fitness trackers, drone controllers, and even a lunar robot.

OPTIONAL: Sony uses NuttX in audio products and SPRESENSE. Fitbit used it in fitness trackers, such as the Charge 3 and Charge 4. PX4 drone flight controllers run on it. Xiaomi's OpenVela is reported to run on more than a thousand products. And a small lunar robot, SORA-Q, used it on Japan's 2024 Moon mission.

Sony has a long history with NuttX. Let me show it.

Sony's history with NuttX

2013–15

Early adoption

Ported NuttX to LC823425 / LC823450; first commercial audio products shipped in 2015.

2016–17

Commercial products

Walkman NW-WS620, SMR-10, ICD-TX800 and ICD-PX470 used NuttX.

2018

Xperia Ear Duo & SPRESENSE

Xperia Ear Duo shipped with CXD5602 / NuttX; SPRESENSE launched as a multicore development board.

2019–20

Upstream collaboration

Sony engineers upstreamed CXD56xx platform support and drivers, and shared the work in public NuttX talks.

2020s

Edge sensing

Expanded camera, GNSS, connectivity and edge-sensing capabilities.

Sony Walkman NW-WS620 — Walkman NW-WS620

Takeaway

Sony's NuttX journey began with audio products, expanded through SPRESENSE, and evolved into long-term open-source collaboration.

Sources: M. Ishikawa, Sony NuttX talks (2018–19) · Sony, “Running NuttX on Spresense” (2019) · A. Jerpelea (2020) · Apache NuttX CXD56xx docs

PART 1 · 4/58 / 36

Sony has used NuttX for more than ten years. The public record starts in 2013, when Sony engineers began porting NuttX to an audio processor. The first commercial audio products shipped in 2015.

In 2018, the Xperia Ear Duo shipped with a Sony chip and NuttX. SPRESENSE also launched, as a development board with GNSS, audio and camera support.

Later, Sony engineers moved much of their platform and driver work upstream, and shared it in public NuttX talks.

So Sony's NuttX story began with audio products. It grew through SPRESENSE, and it became long-term open-source collaboration.

That is Sony's history. Now, my own.

OPTIONAL: Public product examples include the Walkman NW-WS620, the SMR-10 sound amplifier, and two voice recorders, the ICD-TX800 and the ICD-PX470.

OPTIONAL: In the 2020s, the platform's abilities kept growing in camera, GNSS, connectivity and edge sensing. That is about technical capability. It is not a claim that every feature shipped in a named product.

NOTE, do not read: Sources (not spoken). M. Ishikawa and K. Okamoto, SMP and Networking support on NuttX / LC823450, 2018: https://events.nuttx.apache.org/wp-content/uploads/2019/11/MIshikawa_nx2019.pdf . Sony, Running NuttX on Spresense, NuttX Workshop 2019: https://events.nuttx.apache.org/wp-content/uploads/2019/11/TKoizumi_nx2019.pdf . A. Jerpelea, A Journey from Fork to Mainline, NuttX Online Workshop 2020: https://events.nuttx.apache.org/index.php/past-events/nuttx-online-workshop-2020/ . Apache NuttX, Sony CXD56xx documentation: https://nuttx.apache.org/docs/latest/platforms/arm/cxd56xx/index.html . Product images: Sony NW-WS620 https://www.sony.jp/products/picture/NW-WS620.jpg , Xperia Ear Duo https://www.sony.jp/xperia/product/smartproducts/xea20/img/main01.jpg , SPRESENSE https://developer.spresense.sony-semicon.com/

My Experience with NuttX

SPRESENSE — Satellite Project

Sony's low-power board, the on-board computer of the ARICA-2 CubeSat (Aoyama Gakuin University, launched April 2026).

I took part through an internal, grassroots engineering initiative.

AITRIOS — Edge AI Sensing Platform

Sony's platform for managing edge AI cameras and running inference on them.

I worked on setting up and operating camera systems that use ESP32 and Apache NuttX.

Takeaway

I wanted a secure way to access and troubleshoot remote embedded devices.

Images: ARICA project (ARICA CubeSat) · Sony Semiconductor Solutions (AITRIOS). ARICA-2: nanosats.eu/sat/arica-2 · SmallSat 2026 paper (Mabuchi et al.)

PART 1 · 5/59 / 36

Now, my own experience with NuttX. I have two stories.

First, SPRESENSE. It is Sony's low-power microcontroller board, and it runs NuttX. The ARICA-2 CubeSat, from Aoyama Gakuin University, uses SPRESENSE as its on-board computer. It sends rapid alerts for gamma-ray bursts, and it was launched in April 2026. I took part in this project through an internal, grassroots engineering initiative.

Second, AITRIOS, Sony's edge AI sensing platform. It is used to manage edge AI cameras and run inference at the edge. I worked on setting up and operating edge AI camera systems. In the systems I worked with, the board was an ESP32 running Apache NuttX.

A satellite in orbit and a camera on site are both far from my desk. These experiences made me want a secure way to access and troubleshoot remote embedded devices. That is the problem I want to talk about next.

OPTIONAL: Not every AITRIOS camera is built this way.

Agenda

Overview & background

Project origins · NuttX & Sony · my experience

~5 MIN

The Problem & Solution

Remote access challenge · why WireGuard

~4 MIN

The Development Plan

Reuse wireguard-lwip · adapt to NuttX

~2 MIN

Version 1: Application-Based Implementation

First working tunnel · debugging challenges

~4 MIN

Version 2: The Kernel Driver

Why a driver · integration challenges · validation

~5 MIN

Live Demo

Secure remote access · Stack-chan control

~3 MIN

Summary & Reflections

Achievements · personal reflections · community

~4 MIN

PART 210 / 36

Problem: How Can We Securely Access Remote Devices?

Devices are far away

Embedded devices sit at remote sites and on other networks.

Remote diagnosis

Engineers need to check and fix them when something goes wrong.

A secure path

Wi-Fi security protects the radio link. Remote access needs its own secure path.

Takeaway

We needed a secure way to access and troubleshoot remote NuttX devices.

PART 2 · 1/411 / 36

Options: Ways to Reach a Remote Device

Way	Any IP service (telnet, web…)?	No server in the middle?	Protected up to
Open a port to the Internet	yes	yes	the application itself
HTTPS / MQTT via a cloud	no, only your API or messages	no, a server or broker	the server or broker
Reverse tunnel / relay (SSH, WebSocket)	one port per tunnel	no, a relay host	the relay host
VPN on the router	yes, the whole LAN	yes	the router, not the LAN behind it
Carrier closed network	yes	no, the carrier	the carrier gateway
VPN on the device (this talk)	yes, any IP service	yes, any WireGuard peer	the device itself

Takeaway

Every option has trade-offs. I chose a VPN on the device, so the device itself is the end of the tunnel.

Each option can be made secure. The last column shows where its protection ends. Mesh VPN agents (Tailscale, ZeroTier) are another “VPN on the device” option, but they usually need a bigger OS.

PART 2 · 2/412 / 36

Solution: A VPN on the Device

Why WireGuard?

Small & simple

Far less code than IPsec or OpenVPN, so it is easier to review and to port.

Lines of code, 2018 — not today's counts

Modern cryptography

ChaCha20-Poly1305 and Curve25519, in one fixed, well-defined suite.

UDP-based tunnel

Encrypted IP packets over UDP. It works with existing WireGuard peers such as Linux, and the microcontroller itself is the VPN endpoint.

Takeaway

Run a lightweight, standard VPN directly on the NuttX device.

Lines of code (rounded): J. Donenfeld, “WireGuard”, Linux Plumbers Conference 2018, wireguard.com/talks/lpc2018-wireguard-slides.pdf. Specific implementations, counted in 2018; the talk's own slides differ slightly for OpenVPN.

PART 2 · 3/413 / 36

So my solution is a VPN on the device itself. Why WireGuard?

First, it is small and simple. In a 2018 talk, its author compared the size of the code: about four thousand lines for WireGuard, about one hundred and twenty thousand for OpenVPN, and over four hundred thousand for IPsec. These are old numbers for specific implementations, but the gap is large. That matters on a microcontroller.

Second, it uses modern cryptography. Third, it is a tunnel over plain UDP. It works with existing WireGuard peers, such as Linux or Windows. And the microcontroller itself becomes the end of the tunnel.

So the idea is simple: run a lightweight, standard VPN directly on the NuttX device. Now, let me show where it fits in NuttX.

OPTIONAL: The cryptography is ChaCha20-Poly1305 and Curve25519. I will not go into the details.

NOTE, do not read: The line counts come from the WireGuard author's Linux Plumbers 2018 talk (slide 5, https://www.wireguard.com/talks/lpc2018-wireguard-slides.pdf). They are old, for specific implementations, and slide 4 of the same talk gives slightly different OpenVPN numbers.

Architecture: where wg0 sits

Takeaway

To NuttX, wg0 is a normal network device. Under it, WireGuard turns its packets into encrypted UDP.

PART 2 · 4/414 / 36

Agenda

Overview & background

Project origins · NuttX & Sony · my experience

~5 MIN

The Problem & Solution

Remote access challenge · why WireGuard

~4 MIN

The Development Plan

Reuse wireguard-lwip · adapt to NuttX

~2 MIN

Version 1: Application-Based Implementation

First working tunnel · debugging challenges

~4 MIN

Version 2: The Kernel Driver

Why a driver · integration challenges · validation

~5 MIN

Live Demo

Secure remote access · Stack-chan control

~3 MIN

Summary & Reflections

Achievements · personal reflections · community

~4 MIN

PART 315 / 36

Porting Strategy: Start from wireguard-lwip

STARTING POINTgithub.com/smartalock/wireguard-lwipAn existing open-source WireGuard for lwIP

KEEP

Protocol & crypto

Reuse the WireGuard protocol and cryptography, with two small fixes.

ADAPT

Platform hooks

Implement NuttX-specific system functions.

REPLACE

lwIP network glue

Use NuttX networking APIs instead of lwIP.

Takeaway

We ported wireguard-lwip to NuttX by reusing the core, adapting platform hooks, and replacing the lwIP integration.

PART 3 · 1/216 / 36

I did not write WireGuard from scratch.

I started from wireguard-lwip, an open-source WireGuard implementation for the lwIP network stack. The link is on the slide. It already has the protocol and the cryptography, so I could focus on the porting.

I sorted the code into three parts. First, KEEP: the protocol and the crypto. I reused them. The crypto is unchanged, and the protocol core needed two small fixes. Second, ADAPT: the platform hooks, a few functions that depend on the operating system, such as the clock and random numbers. Third, REPLACE: the lwIP network glue. NuttX does not have lwIP, so this layer is the real porting work.

So, how does lwIP map to NuttX?

OPTIONAL: The four hooks are a monotonic clock, random bytes, the current time in TAI64N format, and a check for system load. I found the two protocol fixes in a review.

Mapping lwIP Networking to NuttX

Concept	lwIP	NuttX
Network device	struct netif	struct net_driver_s
Packet buffers	pbuf	iob (d_iob)
Registration	netif_add()	netdev_register()
Sending	output callback	d_txavail → devif_poll()
UDP “wire”	udp_pcb, udp_sendto()	UDP socket, psock_sendto()

These are matches of ideas, not a one-to-one swap of APIs.

Takeaway

Porting meant using NuttX's own building blocks, not bringing lwIP into NuttX.

PART 3 · 2/217 / 36

Agenda

Overview & background

Project origins · NuttX & Sony · my experience

~5 MIN

The Problem & Solution

Remote access challenge · why WireGuard

~4 MIN

The Development Plan

Reuse wireguard-lwip · adapt to NuttX

~2 MIN

Version 1: Application-Based Implementation

First working tunnel · debugging challenges

~4 MIN

Version 2: The Kernel Driver

Why a driver · integration challenges · validation

~5 MIN

Live Demo

Secure remote access · Stack-chan control

~3 MIN

Summary & Reflections

Achievements · personal reflections · community

~4 MIN

PART 418 / 36

Version 1: WireGuard as a NuttX application

GOAL

Run a standard WireGuard tunnel as a NuttX application.

Reuse the existing core and implement the NuttX integration.

Layer	Work needed	In this port
Protocol & crypto	Almost noneportable C	Crypto byte-identical. Two small fixes to the protocol core.~3,100 lines reused · ~40 changed
OS hooks	Four functionssmall	clock, `/dev/urandom`, TAI64N, load check~120 new lines
Network glue	The real work	netdev + UDP socket + RX task~1,200 new lines

Takeaway

Version 1 proved that WireGuard could run on NuttX.It also exposed OS and networking problems that the first tunnel did not reveal.

Lines include comments, from git history. Reused: the vendored wireguard-lwip files. New: the first working tunnel, 2026-08-13. Fixes: 2026-09-18.

PART 4 · 1/519 / 36

Version 1 is WireGuard as a NuttX application, in a FLAT build. The goal was a standard tunnel that I can configure at run time, without rebuilding the firmware.

This table shows the work in each layer. The protocol and crypto came from wireguard-lwip, with only two small fixes. The OS hooks are small. The real work was the network glue: the netdev, the UDP socket, and a receive task. That was about twelve hundred new lines.

It worked, but it also showed problems that a first successful ping could not show. Let me show where it was hard.

OPTIONAL: About three thousand lines came over from wireguard-lwip. The OS hooks are about one hundred and twenty lines.

OPTIONAL: One of the two small fixes was a bug in wireguard-lwip itself: its rate limit never worked.

NOTE, do not read: Line counts are physical lines from git history. Reused: the vendored wireguard-lwip files (about 3,100 lines). Fixes: about 40 lines changed (2026-09-18). OS hooks: nuttx-platform.c, 118 lines at the first working tunnel (2026-08-13). Glue: nuttx-wireguardif.c and .h, about 1,200 lines at that time. Today's file is about twice as long because of run-time configuration.

Where it was hard: six bugs

#	Bug	Showed up in	Lesson
1	The receive thread stopped when the `wg` command exited	apps version	`pthread_detach()` frees memory later. It does not keep a thread alive.
2	ping works, TCP dies in detail	apps version	A file descriptor belongs to one task group.
3	“No real impact” was 10× in detail	apps version	Measure a quick fix before you call it free.
4	Stack 94% full; saving the config froze the board	real boards only, never sim	Measure on real hardware. Sim's big stacks hide it.
5	Handshake OK, data fails: NuttX's own ChaCha20‑Poly1305 part 5	kernel driver	A passing handshake does not prove the data path.
6	A 6 KB array on a 3 KB kernel stack part 5	BUILD_KERNEL (QEMU)	The same stack lesson, one level deeper.

Takeaway

Most of them hid behind a test that passed, so I first looked in the wrong place.

PART 4 · 2/520 / 36

The first tunnel worked quickly. Most of my time went into six bugs: four in the application version, and two more in the kernel version.

Most of them hid behind a test that passed, like a handshake or a ping. So at first, I looked in the wrong place.

I will explain two of them, because their lessons are useful for anyone. Bugs five and six come later, in the kernel part.

OPTIONAL: Bug one: the receive thread stopped when the wg command that started it exited. Detach only decides when memory is freed. It does not decide how long the thread lives. That is why the kernel driver owns its thread.

OPTIONAL: Bug four: only real hardware showed it. On the board, the receive task's stack was ninety-four percent full. The simulator has big stacks, so it never showed. Measure on real hardware.

NOTE, do not read: The logs and fixes for all six bugs are in the GitHub repository.

Bug ②: Ping Works. TCP Dies.

SYMPTOM

ping works: 0% loss.

A TCP handshake even completes, then the connection dies.

psock_sendto: ret=-1 errno=9
EBADF — “Bad file descriptor”

ROOT CAUSE & FIX

Sends from the wg_rx task worked. Sends from the system work queue, which flushes TCP data, failed.

Cause: a file descriptor belongs to one task group. It is not valid in another one.

Fix: use psock_*() on a struct socket. No fd, so any task can use it.

Takeaway

If only some tasks fail, look at what each task owns. Here, it was the file descriptor.

PART 4 · 3/521 / 36

Bug ③: “No Real Impact” Was 10× Slower

QUICK FIX

Check every 50 ms

Dropping fds also broke poll(), so I polled the socket. I thought the only cost was waking an idle CPU.

Measured: about 10× slower.

REAL FIX

Event-driven wake-up

A callback on psock_poll() and a semaphore: a real blocking wait. Each packet wakes the thread when it arrives.

Takeaway

A quick fix you never measure can look free. Measure it.

PART 4 · 4/522 / 36

Version 1 demo: the first video

A frame from the version 1 video: the Windows WireGuard client beside a telnet session into NuttX on an ESP32-S3

1 telnet 10.10.0.2
2 uname -a, ifconfig
3 webserver &
4 browser: http://10.10.0.2/

ESP32-S3 DevKit, apps version (FLAT). USB unplugged.

Other end: the official Windows WireGuard client.

Video: youtu.be/1kyX2av5WG4

Takeaway

Version 1 was enough for a demo. Next, I made it a real NuttX driver.

PART 4 · 5/523 / 36

Agenda

Overview & background

Project origins · NuttX & Sony · my experience

~5 MIN

The Problem & Solution

Remote access challenge · why WireGuard

~4 MIN

The Development Plan

Reuse wireguard-lwip · adapt to NuttX

~2 MIN

Version 1: Application-Based Implementation

First working tunnel · debugging challenges

~4 MIN

Version 2: The Kernel Driver

Why a driver · integration challenges · validation

~5 MIN

Live Demo

Secure remote access · Stack-chan control

~3 MIN

Summary & Reflections

Achievements · personal reflections · community

~4 MIN

PART 524 / 36

Version 2: WireGuard as a NuttX kernel driver

BEFORE — VERSION 1

An application

Lives in apps/ and reaches into kernel internals (psock_*).

Works only in a FLAT build, and does not fit as an in-tree driver.

AFTER — VERSION 2

A kernel driver

wg0 lives in drivers/net/wireguard/. A small wg command sets it up through ioctl.

Made for FLAT, PROTECTED and KERNEL builds.

BUILD MODES

FLAT	Applications and kernel share one address space.
PROTECTED	MPU separates application and kernel memory.
KERNEL	MMU provides separate address spaces.

Takeaway

The goal: a proper kernel driver for every NuttX build mode, in a form that is easier to review upstream.

PART 5 · 1/425 / 36

The Kernel Design: The Big Picture

Takeaway

The driver owns everything that must keep running. The command only sends settings, and then it can exit.

PART 5 · 2/426 / 36

Two Issues Found During Kernel Integration

CRYPTOGRAPHY — ChaCha20-Poly1305

NuttX crypto/chachapoly.c

The nonce counter sits in different bytes from the RFC 8439 / WireGuard layout.
Counter 0 still matches: the handshake works, but data packets after the first fail.
A two-line fix with test vectors, kept as its own change.

KERNEL STACK — Stack Overflow

This driver, KERNEL build only

Setting the peers put a 6 KB array on a 3 KB kernel stack: overflow, then panic.
The sim (FLAT, big stacks) never showed it.
A bug in the driver itself. The array now lives on the heap.

Takeaway

Porting WireGuard also surfaced findings worth sharing with the NuttX community.

PART 5 · 3/427 / 36

On the way into the kernel, I found two separate problems.

The first is in NuttX's ChaCha20-Poly1305 code. It places the nonce counter in different bytes from the layout in RFC 8439, which WireGuard uses. When the counter is zero, the bytes are the same. So the handshake works, but the data packets after the first one fail. The fix is two lines. I prepared it as a separate change, with test vectors.

The second is a bug in my own driver, not in NuttX. Setting the peers put a six-kilobyte array on a three-kilobyte kernel stack. That caused a panic, only in a KERNEL build. I moved the array to the heap.

I prepared these as small, separate pieces. Nothing is submitted yet.

OPTIONAL: As far as I can see, current NuttX master still has the same nonce layout.

OPTIONAL: One more finding from the board side: SPRESENSE did not boot with the high-resolution RTC option, CONFIG_RTC_HIRES, on NuttX 13.0.1 and master. I found the cause and fixed it locally. The report is drafted, but not filed.

NOTE, do not read: Status on 2026-10-13: no pull request exists in apache/nuttx or apache/nuttx-apps; the only related issue is the closed GSoC thread #18548. The nonce check against master was made on 2026-10-13 (crypto/chachapoly.c).

Testing: What Ran Where

Build mode	Environment	Result
FLAT	ESP32-S3 · SPRESENSEreal boards	✓ Verified
KERNEL	QEMU rv-virttunnel to Linux; 4 CPUs under load	✓ Verified
PROTECTED	QEMU rv-virtone fault found and fixed: 20/20 runs	✓ Verified
KERNEL / PROTECTED	Real hardware	— Not tested yet

✓ means it passed in the conditions noted here. It is not a guarantee for other hardware.

Takeaway

Verified on real boards in FLAT builds and on QEMU in KERNEL / PROTECTED builds.Real-hardware testing for those modes remains open.

PART 5 · 4/428 / 36

Let me be exact about what I tested, and where.

In a FLAT build, I tested on real boards: the ESP32-S3 and SPRESENSE. In a KERNEL build, I tested on QEMU. In a PROTECTED build, I also tested on QEMU. I have not yet tested KERNEL or PROTECTED on real hardware.

So a check mark means: it passed under these conditions. It is not a promise for every board.

OPTIONAL: On October 12, I ran the exact series I prepared for upstream on the ESP32-S3: a handshake with Linux WireGuard, and ping both ways, up to the full packet size.

OPTIONAL: On SPRESENSE, I measured memory. After forty down-and-up cycles, it was exactly the same.

OPTIONAL: On QEMU with four CPUs, I ran heavy traffic while changing settings. There was no fault. But that was one scripted run, not a full search for race conditions.

OPTIONAL: In PROTECTED, repeated runs sometimes faulted. The cause was a stack overflow in the wg command. A bigger default fixed it: twenty out of twenty runs.

NOTE, do not read: Details. SPRESENSE receive thread used 1,472 bytes of a 6 KB default. PROTECTED stack overflow: a system call runs on the caller's stack in this mode. CoreS3 cannot boot bootloader-based images, so PROTECTED on that board is not possible (not a WireGuard problem). Records are in docs/upstream/evidence.

Agenda

Overview & background

Project origins · NuttX & Sony · my experience

~5 MIN

The Problem & Solution

Remote access challenge · why WireGuard

~4 MIN

The Development Plan

Reuse wireguard-lwip · adapt to NuttX

~2 MIN

Version 1: Application-Based Implementation

First working tunnel · debugging challenges

~4 MIN

Version 2: The Kernel Driver

Why a driver · integration challenges · validation

~5 MIN

Live Demo

Secure remote access · Stack-chan control

~3 MIN

Summary & Reflections

Achievements · personal reflections · community

~4 MIN

PART 629 / 36

Live Demo: Stack-chan over WireGuard

NETWORK SETUP

LIVE DEMO STEPS

Step	What to demonstrate	Command / Action
1	VPN Connection	`wg show`
2	Remote Login	`telnet 10.10.0.2`
3	Network Interface	`ifconfig` → `wg0`
4	Control Stack-chan	Change face / Play voice

Stack-chan, a palm-sized robot with a small face on its screen

Stack-chan Open-source palm-sized robot github.com/meganetaaan/stack-chan

Photo: Stack-chan project (docs/images, Apache License 2.0).

PART 6 · 1/230 / 36

I keep this slide on the screen, and the terminal is next to it.

My laptop and the Stack-chan are both on my smartphone's Wi-Fi hotspot. The phone only provides the local network. Between the laptop and the Stack-chan, there is one WireGuard tunnel. The laptop is ten dot ten dot zero dot one, and the Stack-chan is ten dot ten dot zero dot two. The phone is not a WireGuard peer. It only carries encrypted packets.

Step one: the VPN connection. I run wg show on the laptop. The handshake is done, so the tunnel is up.

Step two: remote login. I use telnet to connect to the Stack-chan through the tunnel. Now we are inside the NuttX shell.

Step three: the network interface. I run ifconfig. You can see wlan0 on the phone's network, and wg0 with the VPN address.

Step four: control. First, I change the face. Now I make it speak.

So the Stack-chan is a NuttX device, and I am controlling it remotely through WireGuard. One note: this robot runs the application version, in a FLAT build. The kernel driver ran on the same chip in a separate test.

That is the demo. Now, let me summarize.

OPTIONAL: If there is time, I can show the packets. Outside the tunnel, the phone's network sees only encrypted UDP. Inside the tunnel, you can see the telnet text. Then wg show again: the byte counts went up.

OPTIONAL: The voice clips were made on the laptop in advance, so there is no cloud API.

NOTE, do not read: Operation, in order. 1) scripts/stackchan/demo.sh show (wg show): expect the peer, a latest handshake, an endpoint on the phone's network, and transfer counters. 2) demo.sh login (telnet 10.10.0.2): expect the NuttShell prompt. 3) ifconfig inside the session: expect wlan0 and wg0 with 10.10.0.2. 4) stackchan face happy (also neutral, sad, angry, sleepy, surprised), then stackchan say http://10.10.0.1:8000/hello.wav: the clip comes through the same tunnel, the face changes and the mouth moves. Optional: demo.sh outside (tcpdump on eth0, UDP 51820) and demo.sh inside (tcpdump on wg0, TCP 23), then show again. Wait for the board's reaction after each step.

NOTE, do not read: Which version runs: the robot firmware is the application build (Version 1, FLAT), built by the esp32s3-stackchan stage of the Dockerfile. The kernel driver (Version 2) was run on the same ESP32-S3 in a separate build on 2026-10-12, without the Stack-chan app. Do not say the demo is Version 2.

Live Demo: backup video

A frame from the backup video: three terminal panes side by side, one to control Stack-chan, one with encrypted packets, one with plaintext packets

THREE TERMINALS

Left: control
Middle: tcpdump, encrypted
Right: tcpdump, plaintext

A recording of the same demo: Stack-chan over WireGuard.

Video: youtu.be/kMRaY8cDx2E

PART 6 · 2/231 / 36

Agenda

Overview & background

Project origins · NuttX & Sony · my experience

~5 MIN

The Problem & Solution

Remote access challenge · why WireGuard

~4 MIN

The Development Plan

Reuse wireguard-lwip · adapt to NuttX

~2 MIN

Version 1: Application-Based Implementation

First working tunnel · debugging challenges

~4 MIN

Version 2: The Kernel Driver

Why a driver · integration challenges · validation

~5 MIN

Live Demo

Secure remote access · Stack-chan control

~3 MIN

Summary & Reflections

Achievements · personal reflections · community

~4 MIN

PART 732 / 36

Summary

Secure Communication

Brought WireGuard to Apache NuttX, enabling secure IP communication with standard WireGuard peers.

Application to Kernel Driver

Evolved the implementation from a NuttX application into a kernel network driver, tested on real boards and QEMU.

Toward Upstream Contribution

Preparing the driver and related fixes for review by the Apache NuttX community.

Prepared as small, separate changes. Nothing is submitted yet.

PART 7 · 1/433 / 36

What I learned

Lesson 1

From application user to OS contributor

For years I used NuttX from the application side.

This time I worked inside the OS: drivers and the kernel.

Lesson 2

AI helped me code, but understanding was my job

I used Claude a lot. Research and code went much faster.

OS internals were new to me. I did not take AI code as it was. I asked, read, and tested until I could explain it myself.

That was the hard part.

Lesson 3

A welcoming open-source community

Good docs and contributing guides. Active discussion and review.

Open to AI-assisted development, with people staying responsible.

CI, hackathons and events help new people join.

Hope

I hope to keep contributing to Apache NuttX and the open-source community, and I look forward to seeing NuttX continue to grow.

PART 7 · 2/434 / 36

Finally, I'd like to share three things I learned.

First, I came to NuttX as an application developer. This time, I worked inside the OS: drivers and the kernel.

Second, and I want to say this clearly: I used AI, Claude, a lot in this project. It made research and coding much faster. But embedded OS internals were new to me. I could not just take the code the AI wrote. I asked questions, I read the NuttX source, and I tested the behavior, until I could explain it myself. AI helped me code, but understanding was my job.

Third, the community. NuttX has good documentation and contributing guides, and active discussion and review. It is open to AI-assisted development, and people stay responsible for their work. CI and hackathons also help new people join. Open source is not only public code. It grows when new people can join, learn, and contribute.

I hope to keep contributing to Apache NuttX and the open-source community, and I look forward to seeing NuttX continue to grow.

OPTIONAL: In NuttX, a commit says Assisted-by when AI helped, and AI never adds a Signed-off-by.

NOTE, do not read: Say the AI part plainly: not as a confession and not as a boast. It was faster, and understanding was still hard and still mine.

Acknowledgements

Alin JerpeleaFor encouraging me to submit this talk to Community Over Code.

The Apache NuttX CommunityFor the discussions, documentation, and support throughout this project.

Sony's NuttX Developers, Past and PresentFor their contributions to NuttX and the foundation they built.

The Apache Software Foundation & Community Over Code OrganizersFor bringing the open-source community together, organizers and volunteers alike.

PART 7 · 3/435 / 36

Community Over Code · Glasgow 2026

Thank You

The slides and the code are here.

wwlapaki310.github.io/gsoc2026-nuttx-wireguard/…/coc-glasgow-reveal/SLIDES & RESOURCES

github.com/wwlapaki310/gsoc2026-nuttx-wireguardCODE & RECORDS

Satoru Akita · Sony Semiconductor Solutions

SCAN TO VIEW THE SLIDES

Testing: What Ping Misses

Same key on every boot?

SPRESENSE 3 resets, 3 different keys.

A quick check, not a proof of good randomness.

Keys left in memory after down?

sim session keys all zero after down.

The static key stays, on purpose, so up works again.

A leak that shows after hours?

sim 151 rekeys, 100 down/up: nothing lost.

Memory back to the start-up count. Not a week-long run.

Takeaway

Each risk needs its own test. A passing tunnel is not one of them.

APPENDIXA1 / A2

This slide is about what a working tunnel cannot tell you: three problems that ping would never notice.

First, keys. NuttX can seed its random device from build-time settings. Then a board makes the same private key every time it starts, and everything still works. So I reset a SPRESENSE three times, and I got three different keys. That is a quick check, not a proof of good randomness.

Second, I read the device's memory in the simulator. After down, the session keys were all zero. The static key stays on purpose, so that up works again.

Third, a long test, also in the simulator: one hundred and fifty-one forced rekeys and one hundred down-and-up cycles. No buffer was lost, and memory went back to exactly the start-up number. I am not saying it ran for a week, or that the simulator behaves like the board.

Design Choice: Trust the Clock?

Each handshake needs a newer timestamp than the peer has seen, even after a reboot.

Chosen

Real-time clock + the highest value used this boot. Same rule as Linux and wireguard-go, plus a warning when the clock was never set.

Not chosen

Save every timestamp: wears out flash.
Reserve a range in flash: needs a write guarantee I could not verify.
Wait: as long as it last ran.

Same board, nothing sent to it: clock unset → no handshake in 75 s. Clock set → 4.1 s.

Takeaway

Without a clock, a device may not reconnect by itself, and a ping test will not show it.

APPENDIXA2 / A2

This is the one place where I had to decide, not test. And then I measured my decision.

WireGuard's replay protection has a rule: every handshake needs a newer timestamp than the peer has seen, even after a reboot. The device is usually the side that starts the handshake. It is also the side least likely to have a clock with a battery.

Saving every timestamp wears out the flash. Reserving a range in flash is the right long-term answer, but it needs a write guarantee that I could not verify. And just waiting means a device that ran for a month cannot reconnect for a month.

So I chose the real-time clock plus the highest value used in this boot. Linux and wireguard-go do the same. And the driver warns once if the clock was never set.

Then I measured it on the board. I sent the board nothing at all, because a ping from the peer would start the handshake for it. With the clock as it boots, there was no handshake in a seventy-five-second watch. With the clock set, it took four point one seconds. That is why the driver prints a warning.