Add the new linktype for SILABS_DEBUG_CHANNEL.

[tecimovic]

Add a new link type.

[tecimovic]

I see this number (293) conflicts with an earlier pull request.

If you need me to change it, just let me know, I"ll rebase and increase it. I have no idea which will come earlier or later, since this same conflicting PRs also exist on the libpcap library.

[infrastation]

Force-pushed with whitespace cleanups, the proposed code point changed to 296 and rebased on the current master branch. The linked document at a glance looks reasonably intelligible to me.

[tecimovic]

@infrastation : I rebased this and updated the number from 296 to 297, because looking at the libpcap repo, I see something called "Auerswald" took the 296 number on master, so I updated our debug channel number to 297.

Anything else you need me for this to finally get merged?

[guyharris]

So, other than the framing '[' and ']', are the fields mentioned in the specification binary?

If so, then, if one of those bytes has the value 0x5b or 0x5d, are they escaped, or is a ']' not an end-of-frame indicator?

What are the debug message type values and what is the format of the corresponding debug messages?

A flag field that "contains arbitrary values" isn't useful "for future use" unless there's a reliable way for a receiver/reader to determine whether it's been set to a meaningful value or not. Is there such a way to determine that, or should the field be treated as a "must be zero" field - including by Silicon Labs' own software - so that a non-zero value indicates that some meaningful indicators have been put in that field?

What is the sequence number used for? Does it increment with every message, so that it can be used to indicate lost messages?

[tecimovic]

Responding to @guyharris questions:

So, other than the framing '[' and ']', are the fields mentioned in the specification binary?
If so, then, if one of those bytes has the value 0x5b or 0x5d, are they escaped, or is a ']' not an end-of-frame indicator?

The framing are the [ and ] characters and the two-byte length. That ensures that a ] inside a content does not trigger a false end-of-message, since the reader is expected to simply skip the number of characters indicated in the two-byte length, and look for a ] only after that. That ensures a decent recovery if a stream gets broken.

What are the debug message type values and what is the format of the corresponding debug messages?

Debug message types are listed in the JSON which is linked from the toplevel document:
https://github.com/SiliconLabs/java_packet_trace_library/blob/master/silabs-pti/debug-message-type.json
The format of each individual debug message is not specifically described anywhere. Some have been lost to history anyway. The idea is, that this format is a decentralized top-level format, and then each team in the ecosystem that uses this format, can add their messages and their own formats however they wish. Many of those have no desire to be ever decoded my anything else than an automated embedded system, nor decoded in wireshark, for example. But some of those, are actually carrying a binary blob that corresponds to a wireless over-the-air packet, which is IP based, so for those, we need to make wireshark properly decode them.

I can't even provide a full documentation for all of those, but I can provide the documentation for the types that carry the IP packets, since those are my primary concern here.

A flag field that "contains arbitrary values" isn't useful "for future use" unless there's a reliable way for a receiver/reader to determine whether it's been set to a meaningful value or not. Is there such a way to determine that, or should the field be treated as a "must be zero" field - including by Silicon Labs' own software - so that a non-zero value indicates that some meaningful indicators have been put in that field?

The systems that read this are typically embedded systems, for which the knowledge of actual length of message headers matters. In that environment it is useful to know that next minor version update might start using those fields, while the overall message size doesn't change. So if you have a version 3.0, for example, the value in those bytes is ignored. But if your toplevel format version is 3.1, then the values in some of those fields become important. However, because the overall size of the messages didn't change, all the readers that know how to read 3.0 will not break because those fields gain meaningful data points, they will simply continue ignoring them instead.

What is the sequence number used for? Does it increment with every message, so that it can be used to indicate lost messages?

Exactly. Sequence number is used to detect if there were gaps in the messages. This is extremely important, as this indicates that somewhere in the long chain of travel of these messages from the originating system, down to your PC which analyzes this data, some firmware ran out of buffer space or memory or something like that, so the whole chain needs to be analyzed and a faulting hardware/software needs to be updated for higher bandwidth.
It's what tells you that a "missing transmission" in your analysis is possibly due to your instrumentation, not because the transmission didn't happen on the actual radio system being analyzed.

[tecimovic]

@infrastation , @guyharris :

I've updated the docs as requested, I've updated the DLT number again to a later one and rebased both PRs in the two repos. Any chance we can get this merged in now?

Our organization has been using the USERx DLTs for many many months now, and we would really at this point be able to have a fixed DLT for our infrastructure work. The longer we wait, the more things will have to change here and there, so we would really appreciate this being merged, so we can then all standardize on our assigned DLT.

Thank you so much!

[tecimovic]

@infrastation , @guyharris :

Any updates? If you need anything from me to get this merged in, please let me know!

Cheers,
TImotej

[infrastation]

@guyharris, if you don't mind, I will allocate the next available code point to this request because the encoding has a specification and version fields, so it can be refined later on as and if required.

[tecimovic]

Thank you!

[infrastation]

This is now code point 298. From the discussion here and on the mailing list it seems all outstanding points have been addressed in the specification. If this is not the case, please make the specification as difficult to misunderstand as you can. Thank you for waiting and good luck with your project.

[tecimovic]

Thanks for merging in, much appreciated!