search

cetic / 6lbr

A deployment-ready 6LoWPAN Border Router solution based on Contiki
github.com/cetic/6lbr/wiki
Other
337 stars 194 forks source link

6lbr blocks packets forwarding during unsuccessful NS #104

Closed darkopetrovic closed 7 years ago

darkopetrovic commented 9 years ago

Hello,

I've a bad issue with 6lbr when this latter is performing NS to a WSN nodes. Here i my setup:

(Windows / txThings)       (RaspberryPI / CC2531)              (CC2538 / Contiki-OS)
     CoAP Client <-----Eth-------> 6LBR <----------802.15.4-------> CoAP Server

6LBR is running as NDP-Router. Everythings works fine until 6LBR doesn't receive properly the NA in response to a NS. In fact, I've a sleeping node and it is therefore normal for this node to not receive this NS and respond back a NA message. But the node wakes-up periodically to send a notification to the CoAP client. The message is received properly by the CoAP client, which in turn send a response. But this response is then never forwarded to the CoAP server by 6LBR.

I guess this appends because the node isn't present anymore in the neighbor cache of 6LBR and thus doesn't send a message to a unreachable device. Am I right?

Has anyone an idea of a workaround for this?

Is it planned for 6LBR to implement the "ND Optimization for 6LoWPANs, RFC6775" standard in the near future?

laurentderu commented 9 years ago

Hi,

You could check in the network page the status of the neighbor table of 6LBR and check if the neighbor is still present or not.

I believe your neighbor entry is removed because NUD mechanism kicks in and as your sleepy node does not reply, it is removed because of its unreachability. As a workaround you could increase the reachability time to be greater than your sleep period.

About 6LoWPAN-ND, it is already implemented and available in a separate branch :) Check here : https://github.com/cetic/6lbr/tree/dev-6lowpan-nd However it is still beta software, I hope to push a new version soon.

darkopetrovic commented 9 years ago

I thought that. The reachability is already greater than the sleep period. The NS/NA exchange works most of the time, but from a certain moment (can be after more than 20h), I couldn't find why my device doesn't respond to NS message anymore. But for that point it's my business.

Thanks for the info I didn't see you already implemented 6lowpan-nd :) Great!

In the meantime I've problem to cross-compile and create the .deb package of 6LBR for raspberry pi. The debuild -us -uc in your documentation is supposed to be executed directly on the target machine?