This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

COAP server only responding on link local address

I'm trying to use a the COAP server example from SDK 14.2 running on nRF52DK. I've got a RPI3 acting as a router between my Ethernet network and the 6lowpan/BLE link.

I'm running a python coap client on an Ubuntu PC.

My Ethernet network has a fd56:84e8:dd8:1::/64 prefix while the BLE segment has a 2001:db8::/64 prefix.

I can successfully ping the nrf52 from the PC using the nrf52's global address, showing ICMP6 routing via the RPI is working OK.

However, if I execute the COAP client, I see the request executed on the nRF52DK (the LED changes state) but I never see a response received at the PC.

If I look at the bt0 interface on the RPI with wireshark, I see the following:

image description

This seems to show that the COAP request is being sent with the source and destination addresses I expect, i.e. source = PC, destination = nRF52, all using their global addresses, confirming the RPI routed the request from the eth0 interface to the bt0 interface.

However the response is being sent on the link local address back to the PI and so isn't being routed back to the PC.

If I compare this with the ping request, I see the ping reply being sent using the global address of the nRF52DK.

image description

Why is the COAP server responding on the link local address, and what do I need to do to get it to use the global address?

Capture file attached COAP_and_Ping_raspi_BT0.pcapng

Here's another capture file, this time with the COAP request from: a) the raspberry pi router b) the PC on the Ethernet IPv6 network.

coap requests from different subnets.pcapng

You can see that when the request originates from the PI on the 2001:db8 interface, the response is correctly sent back from the interface specified by the source. However when the same request originates outside the 2001:db8 interface the response is sent back not on the interface that received the request, but on the link-local address.

I can't figure out why - especially as the ping request from the first capture works as I expect!

Related