Currently, when using vtimer_set_msg the corresponding msg_t is filled
with the MSG_TIMER ("12345") type.
This approach makes it difficult to differentiate between incoming
messages via vtimer_set_msg.
In this PR I introduce another parameter for the vtimer_set_msg
function to specify a custom msg_t type.
In the main function of RPL (rpl_process thread)
a mutex is used after receiving a message via msg_recv.
However, this mutex is never used in another thread and thus is rendered
obsolete.
As a result of PR #1404, entries will not be added to the routing table
when running in storing mode, although it is supposed to do so.
You can verify by running rpl_udp and call *route* on the dodag-root.
This PR fixes the wrong offset calculation.
In PR #1404 addr_str was renamed to addr_str_mode,
but at some places it was still referenced as addr_str.
When enabling debug messages, the compiler complains.
This implementation is based on RFC 6550 with addition of RFC 6554 (Source Routing Header for RPL). Both can be found under the following links:
- http://tools.ietf.org/html/rfc6550
- http://tools.ietf.org/html/rfc6554
The PR provides basic functionality for handling and forwarding packages in non-storing mode. In addition the structure of the previous implemented RPL storing mode is now revised, so that readability and modularity is increased. The following features are implemented:
- building function for a SRH and integration in common packets
- source-route build algorithm based on the structure of the DODAG
- an RPL-based interpretation of the SRH and removal at destination
- new structure for RPl-module with extracted beaconing-functionality
- leaf nodes are now supported
There are some missed goals and should be included in future updates:
- building a common routing table structure for different types of routing protocols
- routing tables are statically assigned via source code, future update should have an optional variable at build-time, which sets the size of the routing table depending on the desired functionality of a node in the network (root, node, leaf)
This PR depends on #1766.
It contains a minimal implementation of the AODVv2 routing protocol.
*Not* implemented are:
- AckReqs
- alternate metrics
- multiple interfaces
- clients and Client Networks
- buffering
- all addresses, TLVs, and features that are marked as optional
An example application can be found at https://github.com/Lotterleben/RIOT-AODVv2/tree/master/aodvv2_demo.
The implementation relies heavily on a functioning Neighbor Discovery Protocol.
It might be necessary to fill the neighbor cache manually with the current state
of RIOTs NDP implementation.
The value of AODVV2_MAX_UNREACHABLE_NODES has been chosen arbitrarily and will be subject to
future improvement.
Please note that based on my experience, with the default transceiver
buffer size (3) of the native port, about 2/3 of the route discoveries
will fail. This has been addressed in issue #1747. It is advised to increase
the transceiver buffer size when using AODVv2 as a routing protocol.
udp_recvfrom wrote the sender port number in host byte order into the
provided sockaddr6_t. Because all send functions expect the port number
in network byte order this introduces a superfluous conversion step in
case one wants to reuse the address for replying.
closes#1406
Currently, the tcp and udp implementations are bound to each other in a
module called *destiny*. Thus, when using only one of them then the
other one gets also compiled into the binary and initialized,
which results in unnecessary RAM usage and workload for the CPU.
The approach in this PR defines a common module named *socket_base*,
which contains functions used by the posix layer. Compiled by it's own,
those functions return negative error codes, to symbolize upper layers
that they are not supported. When also including the modules *udp* or
*tcp* respectively, functions from *socket_base* get overwritten with the
correct functionality.
Defining *udp* or *tcp* in a Makefile also includes *socket_base*.
Defining *pnet* in a Makefile also includes *socket_base*.
If there's no IPv6 address configured so far to any interface, 6lowpan
should not try to handle incoming packets. This can easily lead to
looping packets.
