Hello list,
I have been trying to get Contiki nodes to connect to a RIOT RPL
network and vice versa, but so far without success. By sniffing the
wireless traffic I have found that Contiki seem to be sending its RPL
messages to the multicast group FF02::1A which in [1] is called "All
RPL nodes". RIOT on the other hand is sending its RPL messages to
FF02::1 and FF02::2 which are the "All nodes" and "All routers" groups
which seem to be ignored by Contiki. RIOT seem to be unaware of the
FF02::1A group on the other hand.
My question is: What is the correct behaviour for RPL messages?
Is there a defined multicast address to use (according to some RFC
document or whatever)?
Hello list,
I have been trying to get Contiki nodes to connect to a RIOT RPL
network and vice versa, but so far without success. By sniffing the
wireless traffic I have found that Contiki seem to be sending its RPL
messages to the multicast group FF02::1A which in [1] is called "All
RPL nodes". RIOT on the other hand is sending its RPL messages to
FF02::1 and FF02::2 which are the "All nodes" and "All routers" groups
which seem to be ignored by Contiki. RIOT seem to be unaware of the
FF02::1A group on the other hand.
My question is: What is the correct behaviour for RPL messages?
Is there a defined multicast address to use (according to some RFC
document or whatever)?
Actually, to respond to my own question:
I found this in RFC6550:
Most RPL control messages have the scope of a link. The only
exception is for the DAO / DAO-ACK messages in Non-Storing mode,
which are exchanged using a unicast address over multiple hops and
thus uses global or unique-local addresses for both the source and
destination addresses. For all other RPL control messages, the
source address is a link-local address, and the destination address
is either the all-RPL-nodes multicast address or a link-local unicast
address of the destination. The all-RPL-nodes multicast address is a
new address with a value of ff02::1a.
RIOT's behaviour in this regard therefore seems wrong.