Description of various IP stack test applications
=================================================
echo_server
-----------
The echo server test implements a network server that listens
UDP sockets. If that socket receives data, the server reverses
the data and sends it back.
The echo client can be running in the host system in which
case you need to use SLIP to connect to qemu. This usage scenario
is described in net-tools project README file [1]. This is the default
if you type "make qemu" in echo_server test application directory.
The network IP stack hooks right under IP stack (network level)
and sends the IP packet to host using SLIP. The layer 2 is the
SLIP layer in this case, no radio layer is simulated or used.
The echo server qemu instance can also be running against echo
client that is running in another qemu. For this you need two
terminal windows. In terminal 1 go to echo_server directory
and type "make server". This will start the echo server and setup
qemu pipes in suitable way and it will also start monitor application
that will store the transferred network traffic into pcap file
for later analysis. Then in terminal 2 go to echo_client directory and
type "make client". This will start the echo client that will
start to send data to the server and verify that it has received
the data back correctly. In the two qemu case we are simulating
the whole radio network meaning that the saved pcap file will
contain 802.15.4 network packets.
echo_client
-----------
The echo client test implements a network client that will
send UDP data to the echo server. The client verifies that
it has received data to the sent message and that the data
is correct.
The echo server can be running in the host system in which case
you need to use SLIP to connect to qemu. This usage scenario
is described in net-tools project README file [1]. This is the default
if you type "make qemu" in echo_client test application directory.
The network IP stack hooks right under IP stack (network level)
and sends the IP packet to host using SLIP. The layer 2 is the
SLIP layer in this case, no radio layer is simulated or used.
The echo client qemu instance can also be running against echo
server that is running in another qemu. This test scenario is
described in echo_server chapter above.
dns_client
----------
The dns_client sample application implements a basic DNS resolver
according to RFC 1035. Supported DNS answers are: IPv4/IPv6 addresses
and CNAME.
If a CNAME is received, the DNS resolver can create another DNS query.
The number of additional queries is controlled by the
DNS_RESOLVER_ADDITIONAL_QUERIES Kconfig variable.
For more information about DNS configuration variables, see:
lib/iot/dns/Kconfig. The DNS resolver API can be found at
include/iot/dns_client.h.
Building instructions and sample output can be found at the
samples/net/dns_client/README_xxx files.
zoap_server
-----------
The Zoap server application implements a trivial CoAP server
which exposes a single resource "a/light", that only provides the
GET method.
It can be run similar to the echo_server sample: using two terminals,
(1) for zoap_server, run 'make server' in its directory, (2) for
zoap_client, run 'make client' in the zoap_client test directory.
zoap_client
-----------
The Zoap client application does a single request against a 'a/light'
resource, which has the first response lost (so retransmissions are
basically verified).
Please refer to the section above about how to run these applications
together.
wpanusb
-------
The wpanusb application exports IEEE 802.15.4 radio over USB to be used in
other Operating Systems like Linux. In this scenario Linux SoftMAC driver
must be used implementing IEEE 802.15.4 stack inside Linux.
wpan_serial
-----------
The wpan_serial application implements IEEE 802.15.4 "serial-radio" protocol.
This is the protocol used in Contiki-based native border routers.
[1] https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=summary
90dc300f1e