Reassemble timeout value

[jtaySWE]

Hi, I have a question about the reassemble timeout value.

user.info otbr-agent[10668]: 13:21:20.739 [I] MeshForwarder-: Dropping (reassembly queue) IPv6 UDP msg, len:147, chksum:7712, ecn:no, sec:yes, error:ReassemblyTimeout, prio:normal, rss:-89.0, radio:15.4

For the log above which reassemble timeout value does it relate to?

OPENTHREAD_CONFIG_6LOWPAN_REASSEMBLY_TIMEOUT or OPENTHREAD_CONFIG_IP6_REASSEMBLY_TIMEOUT. And what would the recommended adjusted value be

[abtink]

The log at MeshForwarder is about lowpan re-assembly, so OPENTHREAD_CONFIG_6LOWPAN_REASSEMBLY_TIMEOUT. By default it is set to 2000 msec (2 seconds).

Here is the code where this log is emitted:

ool MeshForwarder::UpdateReassemblyList(void)
{
    TimeMilli now = TimerMilli::GetNow();

    for (Message &message : mReassemblyList)
    {
        if (now - message.GetTimestamp() >= TimeMilli::SecToMsec(kReassemblyTimeout))
        {
            LogMessage(kMessageReassemblyDrop, message, kErrorReassemblyTimeout);
            mCounters.UpdateOnDrop(message);
            mReassemblyList.DequeueAndFree(message);
        }
    }

    return mReassemblyList.GetHead() != nullptr;
}

[jtaySWE]

Ahh I see however, I am getting those logs in almost every minute on average so what value would you recommend I change to?

[abtink]

It might be worth digging in a bit deeper to see why this is happening in your setup first.

[jtaySWE]

threadOnlyMeshForwarderErrorLogs.txt.gz
threadAllMeshForwarderLogs.txt.gz

So these are the logs which I have ran to monitor for a couple of hours on the other day, on an openwrt router running the border router, and I've filtered to look at the openthread logs only. One of them I filtered to show the error logs from thread only, while the other shows all thread logs. For this location there are neon lights and we unfortunately can't relocate the router to lessen the interference nor can we have the neon lights removed, which i do suspect causes uncharacteristic amount of reassembly timeouts unlike other locations where this location shows the error more frequently than those that may have more thread clients than this location.

[jwhui]

Your log shows rss:-89.0, indicating a weak signal. Combined with local RF noise and interference, this causes high frame loss.
Changing OPENTHREAD_CONFIG_6LOWPAN_REASSEMBLY_TIMEOUT won't help to recover lost fragments.

I recommend investigating ways to improve the link budget:

1. Add a Thread Router: Place a powered router/repeater node between the device and OTBR.
2. Change Thread Channel: Switch to a cleaner channel (e.g., 15, 20, 25, or 26).
3. Adjust Antenna: Reposition the antenna on the OTBR.
4. Revisit Hardware Design: Check board layout, antenna matching/tuning, RF shielding, or adding a FEM/LNA.
5. Reduce Payload Size: Keeping IPv6 UDP packets under ~100 bytes avoids fragmentation entirely.