Hi Dojo,

I noticed an interesting behavior in DataMiner's byte unstuffing that caught my attention. Consider the following action:

<Action id="4">
    <Name>Response Unstuffing</Name>
    <On>response</On>
    <Type options="0x10ef-0x10fd-0x10fc;0x10-0x02-0x03" startoffset="1" endoffset="1">replace                  data</Type>
</Action>

Example raw device response:

02 30 0E 00 D1 10 EF FD 03

After unstuffing, the protocol produces:

02 30 0E 00 D1 02 03

Even though the original response contained 10 EF FD, the sequential greedy replacement turns it into just 02.

Step-by-step explanation:

1. The protocol scans the stream and finds 10 EF. It replaces it with 10.

   • Stream becomes: ... <strong>D1 10 FD 03</strong>

2. Next, it finds 10 FD in the remaining stream and replaces it with 02.

   • Stream becomes: ... <strong>D1 02 03</strong>

3. No more matches are found, so unstuffing ends.

   • Final unstuffed stream: ... <strong>D1 02 03</strong>

The protocol processes the buffer sequentially and greedily, which is why 10 EF FD becomes 02.

I am curious why the protocol was designed to apply replacements sequentially over the entire response instead of treating the original response sequence as a single unit. Also, is there a scenario where reordering the replacements to prevent this behavior is not possible, and could that potentially cause issues with some responses?