The problem came from the fact that there two opposite macro (UIP_CONF_ROUTER) that could not activate the code responsible to send the PIO option in NDP.
In Neighbor Discovery Protocol, when IPv6 host adds a prefix (coming from PIO) but it is always failing whatever if is successfully add in prefix table. The reason comes from the fact that the function uip_ds6_prefix_add in host version always return NULL. This is opposite of the specification of the router version.
The next-hop address did not get updated in the routing table
in case an entry for the destination already existed.
This patch resolves the issue by removing the entry and
having it re-created from scratch.
The issue causes a routing error triggering reconstruction of
the DODAG through version increase.
In case of somewhat frequent downward traffic in not (yet) stabilized DODAG
a vicious circle is formed: unstable topology means churn, downward
routing under churn causes reconstruction of DODAG. In this situation
the network does not have chance to stabilize.
We encountered a constant churn caused by this bug
in a network of 50 nodes and a periodic traffic (a packet every 5
seconds) generated at the root.
More info and a PCAP demonstrating the issue can be found here:
https://github.com/contiki-os/contiki/issues/496
Made Ethernet drivers easier to consume by assembly programs.
* Replaced function pointers with JMP instructions.
* Provide return values additionally via Carry flag.
Reset Ethernet chips on initialization.
Both for the CS8900A and the W5100 the data sheets just say that
the RESET bit is automatically cleared after the RESET. This may
be interpreted in two ways:
1) There's no need to be afraid of reading the RESET bit as 1 and
unintentionally trigger a RESET by writing it back after ORing in
some other bit.
2) The RESET process isn't complete before the RESET bit hasn't
become 0 again.
It's impossible for me to empirically falsify the latter option
as the drivers are supposed to work on faster machines than the
ones I have access to. And if the RESET process includes things
like oscillators then the time to complete the RESET could differ
even between multiple exemplars of the same chip. Therefore I
opted to presume the latter option.
However that means a non-exsistent chip may cause an infinite
loop while waiting for the RESET bit to be cleared so I finally
added code to detect the presence of the Ethernet chips. There's
a risk of a chip being locked up in a way that makes the detection
fail - and therefore the RESET not being performed. This catch-22
needs to be solved by the user doing a hard RESET.
type process_data_t. This was an artifact when the choice was
made to use the void * type for the data parameter in processes.
Changed parameter 'void * data' of process_post_synch to
process_data_t for consistency.
Checked all the uses of process_start() in contiki and fixed casts
of the data parameter.
Some calls to `rpl_set_root` select a hardcoded DODAG ID
(0x1111, 0x1100, 0, 0, 0, 0, 0, 0x0011)
This is against what RFC 6550 says. We change these calls
to select a DODAG ID corresponding to a routable v6 address
corresponding to the root
