Mesh back and forth seems to break connection

[kaushalyasat]

Hi,

We have one customer having two CoAP hosts and some CoAP clients in the form of wireless sensors. The sensors are paired to a single host. The pairing is actually in the app level, where the sensor discovers the network IP of the host in pairing host. All the devices have the same PANID and network key.

Recently we have seen a scenario where some sensors seemingly stopped communication with the paired host. By looking at the RSSI graphs, we thought is this caused by a sensor constantly swinging back and forth between two hosts (one host acting as a router). We dont have access to the CLI interface of the hosts as this is a remote site. We see the Sensor RSSI reported back. This is its RSSI with the router/leader immediately connected to at the time.  

Any ideas?

Cheers,

Kaushalya

[kaushalyasat]

Hi, We continue to see these SEDs failing over time. I have 4 SED now in the lab which seemingly 'fell off' the network. I dont have any wireshark captures of them before this happening, but I have them after. 

1. To filter out wireshark captures, I want to filter based on Extended MAC of the SEDs. But I cant seem to find any field in the captured packets which contains the Ext MAC. Is there a way to target the ExtMAC of SEDs from wireshark?

2. From one of these fallen off SEDs, I can see the RTT viewer (console is disabled in SEDs). By that I can see the SED apparently sends data out, but I cant see these packets from wireshark. I have filtered based on RLOC16 of the destination server, which should be receiving these packets. As I dont know a way to filter based on ExtMAC of the SED I cant directly target the SED. I dont know the RLOC16 of the SED. At the moment, we have many CoAP hosts in the lab, so I dont know the path this SED has taken as well. Can you give me a way how to find the packets send by this SED from wireshark? I only know the ExtMAC of the SED. 

Any help is much appreciated.

Cheers,

Kaushalya  

[Edvin]

You can apply any field that you see in a packet as a filter. Just right click it, select "Apply as Filter" -> "Selected":

This will paste this as a filter in the top of WireShark. You can also use logic expressions, like || and && : 

However, if you can't find that field in the packet, it is not part of the packet itself, and in that case, the filter will not be able to pick it up (it will be filtered out). 

I would assume the information is present in the trace. Can you upload it? Does it contain the data all the way from the start? There must be some packets where the RLOC address is assigned to the node.

BR,
Edvin

[kaushalyasat]

Hi Edvin,

Apr-16-1.pcapng

This is one of the logs. 

1. How can I filter RLOC address assignment packets? 

2. In SED to FTD transmissions, I cant seem to decrypt 802.15.4 packets but FTD to FTD packets are fully decryptable. 

How can I fix this? I have only one networkkey, which is 0x00112233445566778899aabbccdd0001

Cheers,

Kaushalya

[kaushalyasat]

Also I came across this thread from an old devzone ticket.

 nRF Sniffer integration for 802.15.4 in a python scipt (Pcap file problems) 

Here Nordic engineer mentions that extended address is required in a packet to decrypt and this can be 'fixed' by moving packets with extended address to the top. I tried doing this with the attached log, but I am not 100% sure how to do it. 

Can you shed some light?

Thanks,

Kaushalya

[kaushalyasat]

Also from the log I think I can see that the sensors (SEDs) which has disappeared from the network actually is connected to the network from the sensors point of view. I can see my log message just before  calling the coap_send_request (). Following is the code section.

...
LOG_INF ("ZS %d, RSSI %d, LQI %d, LQO %d, FW %04x", the_sensor_device->zoneState, RSSI, linkQalIn, linkQualOut, FWRevNum);
...
coap_send_request(COAP_METHOD_PUT, (const struct sockaddr *)&unique_local_addr, sensor_option, payload, sizeof(payload), NULL);
...

Here I have not handled the return value from coap_send_request (), which is my bad. But I dont get any error logs from this. But I cant see the packet being transmitted in my wireshark logs. So I have the feeling that this is something related to either CoAP stack or the OpenThread stack. 

There could be possibility that I dont see the actual packet in wireshark log because I dont have sufficient data to filter these. As I said, I dont know the RLOC of these sensors, I only know their MAC. But I cant easily filter based on the MAC as I cant see it in any frames.

How can we further debug this?

Cheers,

Kaushalya