--- Begin Message ---
I'm requesting an addition of the new DLT type. I'd call it:
DLT_SILABS_DEBUG_CHANNEL.
The description of the protocol is here:
https://github.com/SiliconLabs/java_packet_trace_library/blob/master/doc/debug-channel.md
...
In case of errors (such as the ] not being present after the length bytes) the
recovery is typically accomplished by the deframing state engine reading
forward until a next [ is found, and then attempting to resume the deframing.
This case can be detected, because the payload of individual message contains
the sequence number.
So, presumably:
1) all packets in a LINKTYPE_SILABS_DEBUG_CHANNEL capture begin with a
'[';
No. Like the document describes: tooling that deals with deframing is
expected to remove the starting `[`, the ending `]` and the 2 byte
length right after the `[`.
In case of creating a PCAPNG file out of this stream, the payload of the
packet blocks will NOT contain the framing. So the "packet" starts with
the debug message.
2) all bytes after the '[' and the payload bytes specified by the
length should be ignored as being from a framing error, unless there's just one
byte equal to ']'?
Deframing engine is looking for a `]` after the end of the <length>
bytes. If it doesn't find it, it's considered "in error". It will stay
"in error" and not emit any deframed messages, until it:
a.) Finds a next `[`.
b.) Succesfully reads the <length> bytes.
c.) Succesfully reads the ']' after the bytes.
If this happens, the deframing is back out of error, and continues
properly emitting the individual messages.
This design is intended to favor simplicity over recoverability. You can
be unlucky, and encounter a sequence `[`, 0xFF, 0xFF inside the payload
when you're in-error, and this would immediately cause you to skip FFFF
bytes. Which may be way too much. And if you have fatefully many `[`
characters in the payload, you may never recover.
That's ok though. The use of this protocol is such, that the user
typically simply breaks off all the communication and gives up, when the
deframer ends up in-error. Deframing errors are rare, because all this
data in majority of cases travels over TCP/IP. What gets lost are
typically whole messages because of various buffer exhaustion, not
individual bytes that would mess up with the deframing.
I.e., code reading the capture file does *not* have to do any deframing?
Correct. Capture file is already deframed into individual debug messages.
What do the bits in the "Flags" field of the 3.0 debug message mean? Does "few
bytes of future-proofing flags" mean that there are currently no flag bits defined, so that
the field should always be zero, but there might be flag bits defined in the future?
They mean. "Reserved for future use". The value currently can be
arbitrary and until someone defines values for them, they have no
meaning. I'll make this more specific in the doc.
The types supported are listed in this file.
The file in question:
https://github.com/SiliconLabs/java_packet_trace_library/blob/master/silabs-pti/src/main/java/com/silabs/pti/debugchannel/DebugMessageType.java
lists a bunch of message types; is there a document that describes the format
of messages with each of those types?
Good eyes.... :)
I am currently in the process of gathering all this documentation, but I
moved forward with starting with the DLT_ process before I finish all
that, since it's a decent digital archaeology project and meanwhile I
can wait out the pull-requests for the new DLT_ numbers to be approved.
The outcome of documentation gathering effort will be:
a.) The message types that are actually of immediate concern (the
TX/RX packet formats of various radios, mostly envelopes that
essentially wrap the payload of a well-known protocol, such as Bluetooth
or Zigbee) are well documented, and I'll gather all that and document it
in a same location.
b.) Several message types that are helpful, and would be "nice to
show" in the utilities that visualize or analyze these messages are
simple, and will be documented as well.
c.) Many message types will be declared "Obsolete." as the format and
purpose was lost over time, but the message types will remain reserved
forever.
d.) Some message types will be declared "Reserved, vendor specific.",
as the format of those messages is somewhat proprietary. (There may be
just one or two of those, if any).
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
