1.. _networking_with_host:
2
3Networking with the host system
4###############################
5
6.. toctree::
7   :maxdepth: 1
8   :hidden:
9
10   native_sim_setup.rst
11   qemu_eth_setup.rst
12   qemu_setup.rst
13   usbnet_setup.rst
14   qemu_user_setup.rst
15   networking_with_multiple_instances.rst
16   eth_bridge_native_sim_setup.rst
17   qemu_802154_setup.rst
18   armfvp_user_networking_setup.rst
19
20While developing networking software, it is usually necessary to connect and
21exchange data with the host system like a Linux desktop computer.
22Depending on what board is used for development, the following options are
23possible:
24
25* QEMU using SLIP (Serial Line Internet Protocol).
26
27  * Here IP packets are exchanged between Zephyr and the host system via serial
28    port. This is the legacy way of transferring data. It is also quite slow so
29    use it only when necessary. See :ref:`networking_with_qemu` for details.
30
31* QEMU using built-in Ethernet driver.
32
33  * Here IP packets are exchanged between Zephyr and the host system via QEMU's
34    built-in Ethernet driver. Not all QEMU boards support built-in Ethernet so
35    in some cases, you might need to use the SLIP method for host connectivity.
36    See :ref:`networking_with_eth_qemu` for details.
37
38* QEMU using SLIRP (Qemu User Networking).
39
40  * QEMU User Networking is implemented using "slirp", which provides a full TCP/IP
41    stack within QEMU and uses that stack to implement a virtual NAT'd network. As
42    this support is built into QEMU, it can be used with any model and requires no
43    admin privileges on the host machine, unlike TAP. However, it has several
44    limitations including performance which makes it less valuable for practical
45    purposes. See :ref:`networking_with_user_qemu` for details.
46
47* Arm FVP (User Mode Networking).
48
49  * User mode networking emulates a built-in IP router and DHCP server, and
50    routes TCP and UDP traffic between the guest and host. It uses the user mode
51    socket layer of the host to communicate with other hosts. This allows
52    the use of a significant number of IP network services without requiring
53    administrative privileges, or the installation of a separate driver on
54    the host on which the model is running. See :ref:`networking_with_armfvp`
55    for details.
56
57* native_sim board.
58
59  * The Zephyr instance can be executed as a user space process in the host
60    system. This is the most convenient way to debug the Zephyr system as one
61    can attach host debugger directly to the running Zephyr instance. This
62    requires that there is an adaptation driver in Zephyr for interfacing
63    with the host system. Two possible network drivers can be used for this
64    purpose, a TAP virtual Ethernet driver and an offloaded sockets driver.
65    See :ref:`networking_with_native_sim` for details.
66
67* USB device networking.
68
69  * Here, the Zephyr instance is run on a real board and the connectivity to
70    the host system is done via USB.
71    See :ref:`usb_device_networking_setup` for details.
72
73* Connecting multiple Zephyr instances together.
74
75  * If you have multiple Zephyr instances, either QEMU or native_sim ones,
76    and want to create a connection between them, see
77    :ref:`networking_with_multiple_instances` for details.
78
79* Simulating IEEE 802.15.4 network between two QEMUs.
80
81  * Here, two Zephyr instances are running and there is IEEE 802.15.4 link layer
82    run over an UART between them.
83    See :ref:`networking_with_ieee802154_qemu` for details.
84
85* Simulating Ethernet bridge network with native_sim.
86
87  * Here, one Zephyr instance is running with Ethernet bridge enabled
88    via :kconfig:option:`CONFIG_NET_ETHERNET_BRIDGE` Kconfig option. There
89    exists two host network interfaces ``zeth0`` and ``zeth1`` and the network
90    packets are bridged between those two interfaces.
91    See :ref:`networking_with_native_sim_eth_bridge` for details.
92