[HECnet] native Dup sync line revisited --> preliminary tests --> update logging Dup-Dmc communications

[Paul Koning]

> 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=sharing 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