Moving to a pointer-based API simplifies a lot, since there is no need
for an internal pool of entries anymore. Therefore, a lot of
organizational overhead and some restrictions (e.g. an upper limit on
entries) are dropped.
The entries can be stored in the stack of the respective thread.
The motivation behind this module is to allow for address handling
functions where they, but not the full IPv6 functionality might be
needed. This new version of the IPv6 address data type utilizes the
byteorder.h header to enforce network byte-order on its members.
When setting the `ENABLE_DEBUG` flag to *1* in ip.c,
the **rpl_udp** example won't compile, because the variable `addr_str`
is also defined in **rpl_udp.h** as extern.
Prefixing `addr_str` with `static` in ip.c solves this problem.
Currently, the DIO options `dodag conf` and `prefix info` are off by two
bytes in their `length` field. The RFC states, that the length field
should not include the option `type` field and the `length` field (two bytes).
For Prefix Info Option: Option Length: 30 (RFC 6550, P.61)
For Dodag Conf Option: Option Length: 14 (RFC 6550, P.52)
Wireshark complains about DIOs as malformed packets, otherwise.
Can be reproduced by running the rpl_udp example and logging the DIOs
via wireshark.
This PR proposes an approach to reduce the thread count of RPL.
The current RPL/Trickle stack needs about 5 threads to handle tasks
like updating the trickle timer, routing entries and the transmission of
DAOs.
This PR modifies RPL to use only one thread with a looped `msg_recv()` call.
The message is then multiplexed to the right task.
This PR removes code depending on a routing table with an entries
size > 0. Currently, all those functions and symbols are compiled into the binary,
even when there is no effective space in the routing table (as it is the
case for normal nodes in non-storing mode)
``debug.h`` was included before ``ENABLE_DEBUG`` was set to 0 or 1. In consequence, setting ``ENABLE_DEBUG`` to 1 had no effect. This should be fixed now.
For some reason the call to aodv_packet_reader_handle_packet() got lumped in with the check if a received packet is ours. In consequence, all packets which were not sent by the node that received them (i.e. the important ones) were silently ignored, preventing any routes from being established.
This should be fixed now: foreign packets are now handled again, while own packets are ignored.
Also, I made the corresponding comment a bit less passive-aggressive.
Calling ipv6_iface_set_srh_indicator with storing mode breaks the
neighbour discovery code in **ip.c:480**.
Thus, it is not possible to use `send <n> test` from node to node.
The dicision to drop a packet if no next hop exists is made by the
`rpl_get_next_hop` function, which is initialized as the routing
provider for rpl applications. Hence, it seems needless to do this in the
`rpl_send` function.
`dodag` is the representation of the incoming DIO and thus is temporary.
Assigning this to the parent would lead to failure when reading/writing
to/from the parent's dodag attribute later.
`my_dodag`on the other hand is the local persistent representation of
the DIO's dodag and therefore the right choice.
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.
