14 Dec
2021
14 Dec
'21
9:41 a.m.
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.
From there onwards, dup-dmc are getting in a loop. It
looks like the dup logging itself is neither consistent or constant (some lines are
sometimes present and later on missing). The coalescing probably indicates some error(s)
in dup simulation leading to the dmc dancing around with the dup in bad crc error
reporting, although the checksums of the packets look ok, until some form of reset takes
place and then it starts all over again.
Now it may be time to zoom in.
Reindert