Networking with the host system

While developing networking software, it is usually necessary to connect and exchange data with the host system like a Linux desktop computer. Depending on what board is used for development, the following options are possible:

  • QEMU using SLIP (Serial Line Internet Protocol).

    • Here IP packets are exchanged between Zephyr and the host system via serial port. This is the legacy way of transferring data. It is also quite slow so use it only when necessary. See Networking with QEMU for details.

  • QEMU using built-in Ethernet driver.

    • Here IP packets are exchanged between Zephyr and the host system via QEMU’s built-in Ethernet driver. Not all QEMU boards support built-in Ethernet so in some cases, you might need to use the SLIP method for host connectivity. See Networking with QEMU Ethernet for details.

  • QEMU using SLIRP (Qemu User Networking).

    • QEMU User Networking is implemented using “slirp”, which provides a full TCP/IP stack within QEMU and uses that stack to implement a virtual NAT’d network. As this support is built into QEMU, it can be used with any model and requires no admin privileges on the host machine, unlike TAP. However, it has several limitations including performance which makes it less valuable for practical purposes. See Networking with QEMU User for details.

  • Arm FVP (User Mode Networking).

    • User mode networking emulates a built-in IP router and DHCP server, and routes TCP and UDP traffic between the guest and host. It uses the user mode socket layer of the host to communicate with other hosts. This allows the use of a significant number of IP network services without requiring administrative privileges, or the installation of a separate driver on the host on which the model is running. See Networking with Arm FVP User Mode for details.

  • native_sim board.

    • The Zephyr instance can be executed as a user space process in the host system. This is the most convenient way to debug the Zephyr system as one can attach host debugger directly to the running Zephyr instance. This requires that there is an adaptation driver in Zephyr for interfacing with the host system. Two possible network drivers can be used for this purpose, a TAP virtual Ethernet driver and an offloaded sockets driver. See Networking with native_sim board for details.

  • USB device networking.

    • Here, the Zephyr instance is run on a real board and the connectivity to the host system is done via USB. See USB Device Networking for details.

  • Connecting multiple Zephyr instances together.

  • Simulating IEEE 802.15.4 network between two QEMUs.