New AP_Networking_SITL_TUN backend that opens a Linux TAP device and
bridges the lwIP stack to it. Slots into the same "ethernet" position
in PPP_ETHERNET_GATEWAY mode that the ChibiOS backend takes on real
hardware, so a SITL build acting as a PPPGW can be reached by developer
tools on the host (browsers, curl, ...) at the periph's PPP-side IP.
A new Tools/scripts/Networking/sitl_network.sh handles the one-time
host setup: it creates the TAP device under the current user (so the
SITL binary needs no extra privileges), assigns the host's IP, and
installs iptables MASQUERADE + FORWARD rules so the SITL subnet can
reach the wider host network / internet via NAT. The matching `down`
action undoes exactly what `up` put in place, using a small state file
in /tmp to remember the outbound interface and the previous
net.ipv4.ip_forward setting. Tools/scripts/Networking/README.md
documents the usage and customisation knobs.
Tools/scripts/Networking/sitl_network.sh up # create TAP + NAT
sim_vehicle.py -v Plane -f quadplane-PPP
curl http://10.77.193.20/ # PPPGW web UI
Tools/scripts/Networking/sitl_network.sh down
The backend's init falls back to a "PPPGW-only, no host bridge" mode
if the TAP device is not pre-created (TUNSETIFF returns EPERM): it
seeds activeSettings from the user-configured IP params and prints a
one-line warning. That way the same hwdef works in autotest (which
runs without root and without sitl_network.sh) and in developer
sessions (which run it).
Gated by AP_NETWORKING_BACKEND_SITL_TUN (default 0); turned on in a
per-board hwdef when wanted. AP_NETWORKING_NEED_LWIP is widened to
include this backend so the lwIP sources get pulled into the build.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tools/scripts/Networking
Host-side helpers for ArduPilot's SITL networking. The scripts here
manage the host plumbing that lets SITL binaries with the optional
AP_NETWORKING_BACKEND_SITL_TUN backend bridge their lwIP stack to a
real TAP device and reach (or be reached from) the wider host network.
sitl_network.sh
Brings up a host-side TAP interface, assigns the host an address on it, and installs iptables rules so the SITL subnet has NAT'd outbound reachability through the host's default outbound interface.
Usage
Tools/scripts/Networking/sitl_network.sh up # create TAP + NAT
sim_vehicle.py -v Plane -f quadplane-PPP # SITL processes start
curl http://10.77.193.20/ # browse the PPPGW web UI
Tools/scripts/Networking/sitl_network.sh down # tear it back down
Both subcommands require sudo only for the privileged steps (TAP
creation, iptables -t nat, sysctl net.ipv4.ip_forward). The TAP
device itself is created with user $USER so the SITL binary opens
/dev/net/tun without any extra privileges.
The script writes a small /tmp/sitl_network.state file on up so
that down undoes exactly what was put in place (the outbound
interface used for MASQUERADE, and the previous
net.ipv4.ip_forward value).
What up does
- Creates
sitltap(TAP, persistent, owned by$USER) if it doesn't already exist, sets itup, and assigns the host10.77.193.1/24. - Detects the default outbound interface from
ip route. - Enables
net.ipv4.ip_forward(if it wasn't on already). - Adds an
iptables -t nat -A POSTROUTING ... -j MASQUERADErule for10.77.193.0/24leaving via the outbound interface, plus matchingFORWARDACCEPTs so the kernel actually forwards.
What down does
Reverses everything up set up, in the opposite order. Safe to call
even if nothing is up (it just prints "TAP does not exist").
Customising
A few environment variables let you change the defaults:
| Variable | Default | Meaning |
|---|---|---|
DEV |
sitltap |
TAP interface name |
HOST_IP |
10.77.193.1/24 |
Address assigned to the host on the TAP |
SUBNET |
10.77.193.0/24 |
Subnet the MASQUERADE rule covers |
PEER_IP |
10.77.193.20 |
Just used in the friendly "where to curl" message |
Companion SITL build
This script is paired with the
libraries/AP_HAL_SITL/hwdef/sitl_periph_PPP build target, which has
AP_NETWORKING_BACKEND_SITL_TUN enabled and a periph-side
NET_GWADDR=10.77.193.1 default so the periph's lwIP routes
out-of-subnet traffic via the host TAP. With the script's NAT rules in
place, both the periph and the ArduPlane behind it on the PPP link can
reach the wider host network and the public internet; with NAT off,
only the developer-side reachability (curl the PPPGW web UI on
10.77.193.20) still works.
If sitl_network.sh up has not been run, the SITL_TUN backend falls
back to a "PPPGW-only, no host bridge" mode: PPP and IPCP still work,
the periph is just not reachable from the host.