B-L475-IOT01A: Enable UDP broadcast test in the spirit-starhub configuration.

This commit is contained in:
Gregory Nutt 2017-08-08 08:32:41 -06:00
parent 572cf51fa4
commit 79400ea960
4 changed files with 49 additions and 0 deletions

View File

@ -496,6 +496,39 @@ Configuration sub-directories
Where <server-ip> is the IP address of either the E1 or E2 endpoints
or of the star hub.
4. Hub UDP Test. The hub of the star does not support the same level of
test as for the endpoint-to-endpoint tests described above. The primary
role of the hub is packet forwarding. The hub does support to test
applications, however: (1) A Telnet client that will permit the hub to
establish remote NSH sesstions with any endpoint, and (2) A special
version of the udpclient program to support testing of Spirit broadcast.
IPv6 does not support "broadcast" in the same since as IPv4. IPv6
supports only multicast. The special multicast address, ff02::1 is
the "all-nodes address" and is functionally equivalent to broadcast.
The spirit radios do support both multicast and broadcast with the
special addresses 0xee and 0xff, respectively. So the Spirit driver
will map the all-nodes IPv6 to the Spirit destination address 0xff and
the packet will be broadcast to all Spirit nodes.
Here are the procedures for using the test
C: nsh> ifup wpan0 <-- Brings up the network on the hub
E1: nsh> ifconfig wpan0 hw 37 <-- Sets E1 endpoint node address
E1: nsh> ifup wpan0 <-- Brings up the network on the E1 node
E1: udpserver & <-- Start the UDP server
E2: nsh> ifconfig wpan0 hw 38 <-- Sets E2 endpoint node address
E2: nsh> ifup wpan0 <-- Brings up the network on the E2 node
E2: udpserver & <-- Start the UDP server
C: udpclient & <-- Starts the UDP client side of the test
The client will broadcast the UDP packets and, as each UDP packet is
sent, it will be received by BOTH endpoints.
STATUS:
2017-08-05: Configurations added. Early testing suggests that there is
a problem when packets are received from multiple sources at high rates:
@ -559,3 +592,6 @@ Configuration sub-directories
that there are no failures that lead to data loss in this environment.
I would say it is functional but fragile in this usage, but probably
robust in a less busy environment.
2017-08-08: Added and verified broadcast packet transfers using the
hub-based broadcast UDP client.

View File

@ -15,6 +15,12 @@ CONFIG_BUILTIN=y
CONFIG_DRIVERS_WIRELESS=y
CONFIG_EXAMPLES_NSH_CXXINITIALIZE=y
CONFIG_EXAMPLES_NSH=y
CONFIG_EXAMPLES_UDP_BROADCAST=y
CONFIG_EXAMPLES_UDP_CLIENT_PORTNO=61617
CONFIG_EXAMPLES_UDP_DEVNAME="wpan0"
CONFIG_EXAMPLES_UDP_SERVER_PORTNO=61616
CONFIG_EXAMPLES_UDP_SERVERIPv6ADDR_1=0xff02
CONFIG_EXAMPLES_UDP=y
CONFIG_FS_PROCFS=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y

View File

@ -23,6 +23,7 @@ CONFIG_EXAMPLES_NETTEST_TARGET2=y
CONFIG_EXAMPLES_NETTEST=y
CONFIG_EXAMPLES_NSH_CXXINITIALIZE=y
CONFIG_EXAMPLES_NSH=y
CONFIG_EXAMPLES_UDP_BROADCAST=y
CONFIG_EXAMPLES_UDP_CLIENT_PORTNO=61617
CONFIG_EXAMPLES_UDP_DEVNAME="wpan0"
CONFIG_EXAMPLES_UDP_SERVER_PORTNO=61616

View File

@ -823,6 +823,12 @@ static void spirit_transmit_work(FAR void *arg)
goto errout_with_csma;
}
/* REVISIT: If we are sending to the multicast or broadcast address,
* should we not also disable ACKs, retries, and RX timeouts? What
* will happen if multiple radios ACK? At a minimum it could keep
* the driver unnecessarily busy.
*/
/* Put the SPIRIT1 into TX state. This starts the transmission */
ret = spirit_command(spirit, COMMAND_TX);