mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-09-03 13:31:57 +00:00
15a151a0a0
The example entropy_source implementation should write entropy to the output buffer rather than to the context pointer which in this example happens to be NULL. Take the opportunity to reorganize the entropy_source to use all of the entropy provided by a call to sys_rand32_get() rather than just 1/4 of it. The entropy_source() callback from mbedtls is given a maximum amount of entropy to return, rather than a minimum amount. Hence it makes more sense to deliver exactly one chunk (32 bits) of entropy from the call to sys_rand32_get() per call and let the mbedtls entropy handler worry about how much entropy we actually need to collect (ie the threshold). Change-Id: I57ed438de5cb1223619fde0fb8039d6eca284646 Signed-off-by: Marcus Shawcroft <marcus.shawcroft@arm.com> |
||
|---|---|---|
| .. | ||
| coaps_client | ||
| coaps_server | ||
| common | ||
| dhcpv4_client | ||
| dns_client | ||
| echo_client | ||
| echo_server | ||
| http_client | ||
| http_server | ||
| ieee802154 | ||
| irc_bot | ||
| leds_demo | ||
| mbedtls_dtlsclient | ||
| mbedtls_dtlsserver | ||
| mbedtls_sslclient | ||
| mqtt_publisher | ||
| telnet | ||
| wpan_serial | ||
| wpanusb | ||
| zoap_client | ||
| zoap_server | ||
| zperf | ||
| net.rst | ||
| README | ||
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 run" 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 run" 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. 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