CoAP communication between NCP and Border Router

[k.bur...@biotcloud.com]

Hello,

Having a custom NCP application, and standard Border Router, is it possible to establish 2-way CoAP communication between user-space program on Linux side and the code on NCP? We're trying to do so, but for some reason packets sent from NCP code to BR are OK, but the other way doesn't work - packets seem to be lost somewhere around wpantund. Is this kind of communication possible by design? Maybe some Linux/iptables settings are necessary?

Generally we want a bit of custom code on NCP to be able to communicate with Linux programs. Probably some custom spinel extensions are the way to do that as well, but CoAP seems to be one of the easiest stuff (especially that both sides are already using CoAP for other purposes). Yet, so far we have problems establishing the communication. Any insights? 

[Jonathan Hui]

By default, the IPv6 RLOC address is not exposed to the host. As a result, it should be possible to send a message from host to NCP using the IPv6 RLOC as a destination address. At the same time, it should be possible to send a message from NCP to host using any IPv6 address assigned to a host network interface, including the mesh-local EID. Does that work for you?

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/78dda60a-feab-4f70-bee9-51dada435704%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[k.bur...@biotcloud.com]

Right. So, we have `Thread:Config:FilterRLOCAddresses false` in wpantund.conf, as it was solving some other problem.. Can't remember now what it was, I think it was that our BR is assigning Service ALOC and the traffic directed toward that ALOC was not reaching Linux side. But we'll verify that again.

Thanks for the pointers, most likely that was the problem, we will confirm it asap. 

[k.bur...@biotcloud.com]

So, disabling the filtering helped a bit, indeed. We still haven't managed to get good communication, though - now ACK is received by NCP, but dropped and CoAP confirmation callback is not called.

In this configuration:

- FilterRLOCAddresses is left at default

- NCP is modified to ask for Service ALOC from leader, and gets 0xfc10 properly

- wpantund is modified, to not filter ALOC addresses, only RLOCs (so ::fc10 address is set on linux interface)

- the IP addresses set on linux side seem to be OK (e.g. RLOC is not there)

These are the scenarios which we observe:

- when linux side is sending request to NCP (destination address being RLOC), it goes through nicely, and ACK is sent back as well - everything works fine both ways

- when NCP is sending request to linux side, using mesh local IP, request reaches linux side, gets answered, ACK gets generated, but is dropped before reaching spinel (not sure yet which layer does drop it, though)

- if, however, NCP is sending request like the above, but to ALOC address, the request reaches linux side, ACK gets generated, gets through spinel to NCP, but NCP drops the packet. This is the log which we do see in such case: https://github.com/openthread/openthread/blob/4693638f77f3e249b518580845bcd7503a2d702f/src/core/net/ip6.cpp#L744

At this point we're slightly clueless and just trying to debug the internals to understand it better how it works, but any pointers/insights/things to check would be really helpful.

PS. As a side story, the FilterRLOCAddresses should probably pass ALOC addresses, filtering out only regular RLOCs. That would be first step towards having full Service support on wpantund (the remaining steps would be to be able to ask NCP over spinel to do service registration). So far, we have custom NCP code with added Service registration + modified wpantund to not filter ALOC addresses, only the RLOC ones.

[Jonathan Hui]

When sending a request from NCP to host, are you setting the IPv6 Source Address to the RLOC? If not, it could be that the IPv6 default source address selection is selecting an address assigned to the host interface (e.g. mesh-local EID).

I agree the FilterRLOCAddresses should be specific to RLOC. For completeness, we probably want an analogous FilterALOCAddresses option as well.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/b5aa2cde-76cd-46c7-8d7a-f5b5928f4de8%40googlegroups.com.

[k.bur...@biotcloud.com]

Yes, we do set NCP source address as RLOC, that was also verified through Wireshark. So, if I understand correctly, it generally should work? So, either we hit some unknown bug or our setup is somehow faulty?

Is there any similar example existing? E.g. in BR demo setup with Raspberry PI or something like that? So we can see that working elsewhere and then compare to our environment?

I will try to issue PR to Wpantund with the new FilterALOCAddresses option, that one seems to be quite easy.

[k.bur...@biotcloud.com]

So, once we configured the RLOC filtering right, the problem now seems to be in port configuration.

On NCP we do start CoAP instance, then send request to BR from it. However, if we use 5683 port, sending request to such port and one of our own IP addresses causes that NCP's local CoAP server handles the request (and sends 'not found' error). The packet is also visible to linux side, and ACK is sent there, too, so we do see multiple ACK packets on Wireshark.

In order to avoid this problem, we started listening on different port (5685) and sending requests to 5683 (this is where BR is listening). CON packet is having src port = 5685, dst port = 5683 properly, as visible in Wireshark.

Then, our libcoap implementation used in BR (taken straight from the OpenThread BR) decides that ACK should be sent with src port = 5683 and dst port = 5683. So, NCP is not recognizing such packet. If we override the ACK dst port to be 5685, NCP recognizes ACK properly. So far we haven't analyzed yet why libcoap decides to override dst port to 5683, not even sure if that is supposed to happen or not.

Could you shed more light onto topics below, please?

- when NCP sends request to BR, can NCP use the same port number (e.g. 5683), and avoid self-responding behaviour? Or we need to use the different port numbers?

- do you think it is a bug, that libcoap ignores src port and sets it to 5683 (or, probably just dst port), or it is actually intended behaviour?

[Jonathan Hui]

The current NCP implementation is behaving as expected. I'm not sure if there's a cleaner way of disambiguating whether the traffic is destined for NCP or host.

I do think the fact that libcoap ignores the source port of the request is a bug.

In RFC7252 Section 1.2

  Endpoint

      An entity participating in the CoAP protocol.  Colloquially, an
      endpoint lives on a "Node", although "Host" would be more
      consistent with Internet standards usage, and is further
      identified by transport-layer multiplexing information that can
      include a UDP port number and a security association

      (Section 4.1).

So UDP port number is used to identify an endpoint.

   Client

      The originating endpoint of a request; the destination endpoint of

      a response.

So responses are destined to the originating endpoint.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/5af963d2-9f89-4853-b6a3-8ad1c1dc86a5%40googlegroups.com.