--- Begin Message ---
On Sun, 1 Jun 2025 14:09:41 -0700
Howard Harte <hha...@magicandroidapps.com> wrote:
> 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.
You are welcome. Please note I mentioned LINKTYPE_RTAC_SERIAL to make
it clear that serial port data capture is a problem space of its own,
not to suggest it necessarily should be a subset of the protocol
problem space you are looking to solve.
It would help to decide how OASIS Send/Receive relates with the layer
that transports it. The original implementation was designed to run
over serial connections, but there is nothing in the protocol
specification that would prevent another implementation from running
over a network protocol (similarly to Kermit over TCP, it seems).
One way to make this design decision would be to say that the transport
connection specifics is out of scope, and to include only the protocol
characters in the link-level encoding. This would be similar to a log
file of httpd/ftpd/tftpd, supposedly with better granularity of wire
events, but without the ability to log additional debugging messages.
Arguably, if such a .pcap file comes from oasis-utils as a by-product
of driving a serial port, there would be a lot of overlap between the
.pcap file and the log file.
Another way would be to say that the main focus is the exchange on the
transport connection, and what higher-level protocol it carries is a
secondary detail. In this case LINKTYPE_RTAC_SERIAL may be not trivial
to implement correctly, but converting the serial connection to a TCP
connection would put debugging OASIS Send/Receive into the same
solution space as SMTP, HTTP etc., which most of the time does not even
require a purpose-designed link-layer header.
Obviously, the latter approach would depend on hypothetical TCP support
in oasis-utils. The native OASIS end of the connection could use a
serial port as before, and the PC end of the serial port would need to
use a converter (e.g. ser2net) to make it TCP.
Also, before I forget: in any case the .pcap/log file regardless of the
format would need to log 8-bit characters to make it possible to see if
any end of the connection violates the 7-bit space of the protocol.
Hopefully this provides some more useful material for this development.
--
Denis Ovsienko
--- End Message ---
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
