[HECnet] MIM?

[Paul Koning]

> On Oct 23, 2018, at 1:39 PM, Robert Armstrong <bob at jfcl.com> wrote:
> 
>> $ 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.  

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