Hello Denis,
Thank you very much for your insightful response and for taking the
time to thoroughly review the documentation and the proposed encoding
for the OASIS Send/Receive protocol. Your detailed analysis and the
points you raised regarding potential ambiguities and alternative
approaches are greatly appreciated.
In particular, thank you for pointing out the existence of
LINKTYPE_RTAC_SERIAL. I will certainly take a closer look at its
structure and consider its potential applicability to capturing OASIS
Send/Receive traffic. Your explanation of the complexities associated
with serial line captures, including control lines and timing
considerations, is very helpful in understanding the nuances involved.
I will also reflect further on the use case and the intended purpose
of adding this specific link-layer type, taking into account the
various aspects you have highlighted, such as the ASCII-centric nature
of the protocol messages and the potential for capturing timing
information more granularly.
Thank you once again for your valuable feedback.
Best regards,
Howard
On Sun, Jun 1, 2025 at 12:09 PM Denis Ovsienko via tcpdump-workers
wrote:
>
>
>
>
> -- Forwarded message --
> From: Denis Ovsienko
> To: tcpdump-workers@lists.tcpdump.org
> Cc:
> Bcc:
> Date: Sun, 1 Jun 2025 20:07:55 +0100
> Subject: [tcpdump-workers] Re: Request to add: LINKTYPE_OASIS
> On Sat, 31 May 2025 19:10:40 -0700
> Howard Harte wrote:
>
> > Protocol documentation:
> > https://cpm80.com/oasis-send-recv-protocol.html
>
> Hello Howard.
>
> Thank you for putting the documentation together, I have spent some
> time comprehending the protocol and had a closer look at the proposed
> encoding, which is as follows:
>
>
> Pseudo-header
> Field Length (bytes) Description
>
> version 1 Set to 1.
>
> direction byte 1 Direction, relative to capturing
> utility: 0x00: received from the serial port.
> 0x01: transmitted to the serial port.
>
> message n The OASIS protocol message (e.g., starting
> DLE STX or ENQ).
>
>
> The "version" seems to correspond to various version fields in
> LINKTYPE_IPNET, LINKTYPE_NFLOG, LINKTYPE_NORDIC_BLE,
> LINKTYPE_USB_DARWIN, LINKTYPE_ZBOSS_NCP, LINKTYPE_NETANALYZER and
> LINKTYPE_NETANALYZER_TRANSPARENT.
>
> The "direction" corresponds to various direction fields in
> LINKTYPE_SLIP, LINKTYPE_PPP_PPPD, LINKTYPE_PPP_WITH_DIR,
> LINKTYPE_C_HDLC_WITH_DIR, LINKTYPE_FRELAY_WITH_DIR,
> LINKTYPE_LAPB_WITH_DIR and elsewhere.
>
> The "message" is a sequence of zero or more ASCII characters, that
> is, octets that have the most significant bit set to 0. (All control
> character codes are ASCII and "Message characters are always
> transmitted as 7-bit ASCII characters." -- the PDF specification
> Appendix A clause 7.)
>
> It should be easy to notice that this version of this encoding captures
> generic directional ASCII strings, which is not limited to the OASIS
> Send/Receive protocol -- it could readily encode other exchanges that
> traditionally take place on a serial line: an XMODEM/etc. file transfer
> session, an interactive shell session, an AT command exchange and so on.
>
> Furthermore, if the proposed link-layer encoding, unlike the specified
> protocol, does not restrict the octets to 7-bit values, it could with
> some degree of approximation be used to capture the [binary] payload of
> a TCP session or the reads and writes done on a character device or a
> Unix socket. Conversely, in the OASIS Send/Receive protocol
> specification I do not immediately see anything that would prevent the
> protocol from working over a TCP connection, a character device or a
> Unix socket. Also if the OASIS host is running in a simulator, the
> communication line potentially could be a [virtual] serial port at the
> OASIS guest end and a TCP connection at the host end.
>
> All this is not to say this solution should be immediately generalised
> to the limit, but there is a few things to consider if you are looking
> for a better match between the problem space and the solution space.
>
> One aspect here is whether the serial line is in scope. If it is, then
> the problem space would be a bit larger because a serial port can be
> synchronous/asynchronous, half/full duplex, and usually includes various
> control lines that may be relevant to the exchange, but are not present
> in the payload (CTS, RTS, DCD, DSR, DTR and so on). Please have a look
> at LINKTYPE_RTAC_SERIAL, which captures this complexity to an extent.
>
> Another aspect is timing. It w
