23 Oct
2018
23 Oct
'18
7:49 p.m.
On Oct 23, 2018, at 1:39 PM, Robert Armstrong <bob
at jfcl.com> wrote:
Yes, that rings a bell. What clearly is going on is that the TCP connection (in that
mode) might be reopened if the network is flaky, but that action isn't tied to a
DECnet circuit restart event. So the routing init message appears on a circuit that
DECnet believes to be in "running" state, which is illegal according to the
DECnet protocol specs.
The only reason this matters is that if you're writing a DECnet implementation that
does conform to the specs, you end up having to do workaround hacks for Multinet. You can
see this in pydecnet, where there is workaround code in the point to point circuit
sublayer state machine, enabled for multinet and disabled for the other (conforming) data
links.
paul
$ dir mim::
%%%%%%%%%%% OPCOM 23-OCT-2018 04:15:10.77 %%%%%%%%%%%
Message from user DECNET on IMPVAX
DECnet event 4.18, adjacency down
From node 1.559 (IMPVAX), 23-OCT-2018 04:15:10.77
Circuit TCP-0-0, Unexpected packet type, Adjacent node = 1.13 (MIM)
Packet beginning = 010D040140020200002C010000000000
FWIW (not much, I suspect) the same thing happens here all the time -
%%%%%%%%%%% OPCOM 23-OCT-2018 10:32:56.52 %%%%%%%%%%%
Message from user DECNET on LEGATO
DECnet event 4.18, adjacency down
From node 2.1 (LEGATO), 23-OCT-2018 10:32:56.51
Circuit TCP-0-1, Unexpected packet type, Adjacent node = 1.13 (MIM)
Packet beginning = 010D040140020200002C01000404FF7F
This happens sporadically on all Multinet links, even VMS to VMS, so it's not got
anything directly to do with MIM. I believe it also happens regardless of the link type
(e.g. TCP or UDP) although I might have to do a little more searching thru the log to
confirm that.
It's a bit annoying but otherwise mostly harmless.