14 Dec
2021
14 Dec
'21
3:06 p.m.
On Dec 14, 2021, at 3:41 AM, R. Voorhorst
<R.Voorhorst at swabhawat.com> wrote:
L.S.
Testing as it was done on the dup-dmc combination with the dmc side used as kind of
proven reference.
The initial section is a log (see pdf link:
https://drive.google.com/file/d/1-m3h5fpvv3JHHUYWi3zgX_qtfm3g1aRs/view?usp=… as
Hecnet seems to disallow pdf attachments) of a dmc-dmc connection that works out of the
box and leads to a Decnet adjacency up message.
Note that the dmc logging is not exactly time-sequential, therefor it is separated
according to time stamp which reveals that xmt and rcv logging is not strictly ordered
with respect to flow of time.
This snippet shows the exact packets that are exchanged with their correct crc
checksums.
The dup-dmc logging in the second section below, can be arranged in lockstep with xmt/rcv
and reveals an interesting anomaly where it seems somewhere in the beginning in dup two
packets are coalesced, that at least is present in the dup logging, although the dmc does
see it as two packets.
That ties into my earlier comment that character mode sync emulation should send the data
stream as submitted to the device. The DMC emulation recovers because it deals with the
connection in that way: it is in charge of finding frame boundaries, not the txmr
service.
I'd suggest the answer is to have the DUP emulation do the same, just pass the bytes.
That wouldn't work for HDLC mode, but the comments in the code say that HDLC mode
isn't currently supported.
paul