Mesh SAR time-out

RE: Mesh SAR time-out

Mttrinh — Wed, 25 Sep 2019 12:00:02 GMT

Hi,

Increasing the retransmit count will help make sure that the receiving node get the message. All mesh devices maintain a message cache, which is used for filtering out packets that the device has already handled. This is to avoid messages being forwarded by the same realys over and over.

Even though increasing the retransmit might help it doesn't ensure that there never will be packet loss. The best option would be to send a reliable(acknowledgeable) message.

Just to clarify, the client node in this case will act as a relay node? If so, then message should be relayed as it is, message PDU remains unchanged when message is relayed.

RE: Mesh SAR time-out

Thierry — Tue, 17 Sep 2019 04:16:50 GMT

Hi Roshan Rajaratnam,
Thank you for your enlightening reply.

So simply creating a message PDU long enough should make it a reliable message with acknowledgement, is that right?

As I said, the node connected to the android device over proxy is receiving every packets so I would suppose this part works correctly indeed. However, the next node receiving the relayed packets is often missing a few packets.

So, how is it acknowledged over proxy but then is not over the rest of the mesh network?

As Mttrinh suggested, I tried increasing the retransmit count on the client; increasing it a bit still produced the error, but increasing it to 6 seemed to have every message pass (with only one relaying node in between).
Wouldn't increasing the retransmit count on every client put an unnecessary burden on the network? What if, out of bad luck, one packet get lost for all retransmissions, I would still be missing the whole PDU for one lost packet.

This PDU being important, I think it would be safer to make sure the proxy connection is directly onto the server node.

RE: Mesh SAR time-out

Roshan Rajaratnam — Fri, 13 Sep 2019 11:52:33 GMT

Hi Thierry,

Yes the api was renamed to make it a little bit more sensible as the calling the api SendMeshMessage would be wrong as the library does not send anything but generate a mesh packet, hence the renaming to createMeshPdu. About acknowledged messages, If you check all configuration/generic messages are of of type MeshMessage. So basically you just have to create an acknowledged message and send it and the library will handle it for you. Unfortunately we are missing the retransmission in the Mesh library. Currenlty the library only retransmit segmented messages based on block acks.

IMHO your message should just work out of the box.

Hope this answers your question.

RE: Mesh SAR time-out

Thierry — Wed, 04 Sep 2019 09:36:11 GMT

If it had, let's say, received segment 5 but did not get segment 4... I thought it could fetch it from the message's source.

I would like to use an acknowledged message for sure. This is a priority as if the server cannot connect to wifi, the rest of the mesh network is pretty much useless.

From the Nordic Android-nRF-Mesh-Library, I was using sendMeshMessage() of MeshManagerApi.java

Its name changed in a recent version (2.0.3 ?) to :

public void createMeshPdu(final int dst, @NonNull final MeshMessage meshMessage)

but there doesn't seem to be any option to send it as an acknowledged message (nor does it have a retransmission count), or am I mistaken?

Here's my message, if ever.. :

public class ServerWifiSet extends GenericMessage {

    private static final String TAG = ServerWifiSet.class.getSimpleName();
    private static final int OP_CODE = ApplicationMessageOpCodes.SERVER_WIFI_SET;

    private final String mSSID;
    private final String mPass;

    /**
     * Constructs PublishServerWifi message.
     *
     * @param appKey                application key for this message
     * @param SSID                  SSID
     * @param pass                  pass
     * @throws IllegalArgumentException if any illegal arguments are passed
     */
    public PublishServerWifi(@NonNull final ApplicationKey appKey, final String SSID, final String pass) {
        super(appKey);
        if (SSID.length()>32 || pass.length()>64) throw new IllegalArgumentException();
        this.mSSID = SSID;
        this.mPass = pass;
        assembleMessageParameters();
    }

    @Override
    public int getOpCode() {
        return OP_CODE;
    }

    @Override
    void assembleMessageParameters() {
        mAid = SecureUtils.calculateK4(mAppKey.getKey());

        final ByteBuffer paramsBuffer;
        paramsBuffer = ByteBuffer.allocate(this.mSSID.length() + 1 + this.mPass.length()).order(ByteOrder.LITTLE_ENDIAN);
        paramsBuffer.put(this.mSSID.getBytes());
        paramsBuffer.put(new byte[1]); // 1 empty byte for separation
        paramsBuffer.put(this.mPass.getBytes());
        mParameters = paramsBuffer.array();
        //Log.d("Publish mParameters", new String(mParameters));
    }
}

Then, again the device connected over proxy seems to receive everything. So should I make this message an acknowledged one only once i got the message on the client side?

RE: Mesh SAR time-out

Mttrinh — Tue, 03 Sep 2019 12:14:13 GMT

What do you mean by "ask"? A message from the client can be retransmittet a number of times depending on your configuration, to ensure that the server receives this message. An ACK can be sent back from the server if a reliable message was sent. Have you tried increasing the retransmit count on the client?

RE: Mesh SAR time-out

Thierry — Tue, 03 Sep 2019 09:02:35 GMT

Hi! No worry.
That's perfectly right.
Im still stuck on this and I would love to know the cause... Shouldn't the server "ask" for the missing packets?

RE: Mesh SAR time-out

Mttrinh — Tue, 03 Sep 2019 08:51:15 GMT

Hi,

Sorry for the delayed response. Have you had any progress on this matter? Seems like there are some packet loss when sending packets to the server. If I understand this correctly, you hit SAR timeouts on the server when packets are retransmitted from the client?

RE: Mesh SAR time-out

Thierry — Fri, 30 Aug 2019 03:03:55 GMT

I found it helpful to increase this value in nrf_mesh_config_core.h :

#define CORE_TX_QUEUE_BUFFER_SIZE_RELAY 128

Now (up to 512), the client doesn't give me any "no memory" error anymore.
However, with max packet data length being 97bytes (9 segments), I still hit SAR time-outs on the server,
receiving sometimes all 9, but more often seeing only 8 segments or less.
It is not always the same number dropping either. (ie, sometime only the 3rd one drops, sometime it's another one)

Reducing size of message to fit in less segments works better...
but this is not optimal as I cannot realistically know my user's wifi credentials won't be that long.