Question for understanding: Why does the first fragment send function doesn't require adaptation?

For all fragments except for the last the idea is to strip off the TX sync snip prior to the fragmentation and reattach it afterwards. If the packet gets dropped outside of the fragmentation code for whatever reason, the TX snip will also be freed which unblocks the thread waiting for the transmission attempt to conclude.

For the very last fragment, the tx snip will be attached to the fragment to send and no longer re-attached to the packet. Once the last fragment to send is freed by the network device (that is, after TX of that is completed), which triggers the unblocking of the thread syncing with TX.

Since fragmentation is only done if the packet doesn't fit into a single frame, we know that the first fragment cannot also be the last. And only the last fragment needs the special treatment.

To be honest: I'm not entirely sure if this approach is indeed the most elegant or efficient way to do this. I didn't dive deeply into the code and only have a rough idea how the fragmentation works. From that, the approach taken here seemed to me to be the most straight forward way to implement this feature.

I think it would totally be possible to restructure the code to keep the tx sync snip in the packet and only strip it of for the very last fragment and attach it there. But I'm not certain enough that this might not play well with the code copying the data from the packet to the fragments, if there is now a tx sync snip at the end of it. (The TX sync snip reports a data length of zero in the hope that this prevents its contents to be ever send out - which might actually be good enough here.)

Since fragmentation is only done if the packet doesn't fit into a single frame, we know that the first fragment cannot also be the last. And only the last fragment needs the special treatment.

I know I go into very theoretical territory with this (and talking about things that are not even implemented), but do we actually know that? For classic fragmentation granted, we do not want to use fragmentation where it is not needed, but one could argue that a user also wants the benefits of fragment recovery for a single frame. I can imagine use cases where end-to-end (or end-to-gateway) ACKs for all 6LoWPAN data might be desirable.

OK, I see. I also adapted the 1st fragment routine and fixes two bugs of the previous version.

I'll mark this as WIP for now. I need to extend the test application a bit (so that the two bugs of the previous version would be caught) and I have the feeling that there is still something odd.

Thanks for addressing my theoretical worries 😅

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

This is still very much needed, I will try to give this more priority

I spiced up the test application to actually make sure that the test message payload is passed through. It does (intentionally) not parse the data send with the netdev, but simply checks if one of the iolist chunk ends with more than 4 bytes of the next expected payload chunk. This way, retransmissions are no longer counted and test will indeed only pass if all of the payload content is send.

Hence, a situation in which a retransmission was miscounted as the next chunk by the test and the test incorrectly passed should no longer occur. I am therefore confident that this indeed works as expected.

Please squash.

Thanks (: