.. _networking_with_qemu:

Networking with QEMU
####################

.. contents::
    :local:
    :depth: 2

This page describes how to set up a virtual network between a (Linux) host
and a Zephyr application running in a QEMU virtual machine (built for Zephyr
targets such as qemu_x86 and qemu_cortex_m3). Some virtual ARM boards (such as
qemu_cortex_a53) only support a single UART, in this case QEMU Ethernet is
preferred, see :ref:`networking_with_eth_qemu` for details.

In this example, the :zephyr:code-sample:`sockets-echo-server` sample application from
the Zephyr source distribution is run in QEMU. The QEMU instance is
connected to a Linux host using a serial port, and SLIP is used to
transfer data between the Zephyr application and Linux (over a chain of
virtual connections).

Prerequisites
*************

On the Linux Host, fetch the Zephyr ``net-tools`` project, which is located
in a separate Git repository:

.. code-block:: console

   git clone https://github.com/zephyrproject-rtos/net-tools
   cd net-tools
   make

.. note::

   If you get an error about AX_CHECK_COMPILE_FLAG, install package
   ``autoconf-archive`` package on Debian/Ubuntu.

Basic Setup
***********

For the steps below, you will need at least 4 terminal windows:

* Terminal #1 is your usual Zephyr development terminal, with the Zephyr environment
  initialized.
* Terminals #2, #3, and #4 are terminal windows with net-tools being the current
  directory (``cd net-tools``)

Step 1 - Create helper socket
=============================

Before starting QEMU with network emulation, a Unix socket for the emulation
should be created.

In terminal #2, type:

.. code-block:: console

   ./loop-socat.sh

Step 2 - Start TAP device routing daemon
========================================

In terminal #3, type:


.. code-block:: console

   sudo ./loop-slip-tap.sh

For applications requiring DNS, you may need to restart the host's DNS server
at this point, as described in :ref:`networking_internet`.

Step 3 - Start app in QEMU
==========================

Build and start the ``echo_server`` sample application.

In terminal #1, type:

.. zephyr-app-commands::
   :zephyr-app: samples/net/sockets/echo_server
   :host-os: unix
   :board: qemu_x86
   :goals: run
   :compact:

If you see an error from QEMU about unix:/tmp/slip.sock, it means you missed Step 1
above.

Step 4 - Run apps on host
=========================

Now in terminal #4, you can run various tools to communicate with the
application running in QEMU.

You can start with pings:

.. code-block:: console

   ping 192.0.2.1
   ping6 2001:db8::1

You can use the netcat ("nc") utility, connecting using UDP:

.. code-block:: console

   echo foobar | nc -6 -u 2001:db8::1 4242
   foobar

.. code-block:: console

   echo foobar | nc -u 192.0.2.1 4242
   foobar

If echo_server is compiled with TCP support (now enabled by default for
the echo_server sample, CONFIG_NET_TCP=y):

.. code-block:: console

   echo foobar | nc -6 -q2 2001:db8::1 4242
   foobar

.. note::

   Use Ctrl+C to exit.

You can also use the telnet command to achieve the above.

Step 5 - Stop supporting daemons
================================

When you are finished with network testing using QEMU, you should stop
any daemons or helpers started in the initial steps, to avoid possible
networking or routing problems such as address conflicts in local
network interfaces. For example, stop them if you switch from testing
networking with QEMU to using real hardware, or to return your host
laptop to normal Wi-Fi use.

To stop the daemons, press Ctrl+C in the corresponding terminal windows
(you need to stop both ``loop-slip-tap.sh`` and ``loop-socat.sh``).

Exit QEMU by pressing :kbd:`CTRL+A` :kbd:`x`.

.. _networking_internet:

Setting up Zephyr and NAT/masquerading on host to access Internet
*****************************************************************

To access the internet from a Zephyr application, some additional
setup on the host may be required. This setup is common for both
application running in QEMU and on real hardware, assuming that
a development board is connected to the development host. If a
board is connected to a dedicated router, it should not be needed.

To access the internet from a Zephyr application using IPv4,
a gateway should be set via DHCP or configured manually.
For applications using the "Settings" facility (with the config option
:kconfig:option:`CONFIG_NET_CONFIG_SETTINGS` enabled),
set the :kconfig:option:`CONFIG_NET_CONFIG_MY_IPV4_GW` option to the IP address
of the gateway. For apps not using the "Settings" facility, set up the
gateway by calling the :c:func:`net_if_ipv4_set_gw` at runtime.
For example: ``CONFIG_NET_CONFIG_MY_IPV4_GW="192.0.2.2"``

To access the internet from a custom application running in QEMU, NAT
(masquerading) should be set up for QEMU's source address. Assuming ``192.0.2.1`` is
used and the Zephyr network interface is ``zeth``, the following command should be run as root:

.. code-block:: console

   iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.0.2.1/24
   iptables -I FORWARD 1 -i zeth -j ACCEPT
   iptables -I FORWARD 1 -o zeth -m state --state RELATED,ESTABLISHED -j ACCEPT

Additionally, IPv4 forwarding should be enabled on the host, and you may need to
check that other firewall (iptables) rules don't interfere with masquerading.
To enable IPv4 forwarding the following command should be run as root:

.. code-block:: console

   sysctl -w net.ipv4.ip_forward=1

Some applications may also require a DNS server. A number of Zephyr-provided
samples assume by default that the DNS server is available on the host
(IP ``192.0.2.2``), which, in modern Linux distributions, usually runs at least
a DNS proxy. When running with QEMU, it may be required to restart the host's
DNS, so it can serve requests on the newly created TAP interface. For example,
on Debian-based systems:

.. code-block:: console

   service dnsmasq restart

An alternative to relying on the host's DNS server is to use one in the
network. For example, ``8.8.8.8`` is a publicly available DNS server. You can
configure it using :kconfig:option:`CONFIG_DNS_SERVER1` option.


Network connection between two QEMU VMs
***************************************

Unlike the VM-to-Host setup described above, VM-to-VM setup is
automatic. For sample
applications that support this mode (such as the echo_server and echo_client
samples), you will need two terminal windows, set up for Zephyr development.

Terminal #1:
============

.. zephyr-app-commands::
   :zephyr-app: samples/net/sockets/echo_server
   :host-os: unix
   :board: qemu_x86
   :goals: build
   :build-args: server
   :compact:

This will start QEMU, waiting for a connection from a client QEMU.

Terminal #2:
============

.. zephyr-app-commands::
   :zephyr-app: samples/net/sockets/echo_client
   :host-os: unix
   :board: qemu_x86
   :goals: build
   :build-args: client
   :compact:

This will start a second QEMU instance, where you should see logging of data sent and
received in both.

Running multiple QEMU VMs of the same sample
********************************************

If you find yourself wanting to run multiple instances of the same Zephyr
sample application, which do not need to talk to each other, use the
``QEMU_INSTANCE`` argument.

Start ``socat`` and ``tunslip6`` manually (instead of using the
``loop-xxx.sh`` scripts) for as many instances as you want. Use the
following as a guide, replacing MAIN or OTHER.

Terminal #1:
============

.. code-block:: console

   socat PTY,link=/tmp/slip.devMAIN UNIX-LISTEN:/tmp/slip.sockMAIN
   $ZEPHYR_BASE/../net-tools/tunslip6 -t tapMAIN -T -s /tmp/slip.devMAIN \
        2001:db8::1/64
   # Now run Zephyr
   make -Cbuild run QEMU_INSTANCE=MAIN

Terminal #2:
============

.. code-block:: console

   socat PTY,link=/tmp/slip.devOTHER UNIX-LISTEN:/tmp/slip.sockOTHER
   $ZEPHYR_BASE/../net-tools/tunslip6 -t tapOTHER -T -s /tmp/slip.devOTHER \
        2001:db8::1/64
   make -Cbuild run QEMU_INSTANCE=OTHER