[HECnet] MIM?

[Paul Koning]

> On Oct 23, 2018, at 10:48 AM, Johnny Billquist <bqt at softjar.se> wrote:
> 
> On 2018-10-23 15:51, Paul Koning wrote:
>>> On Oct 23, 2018, at 3:54 AM, Johnny Eriksson <bygg at cafax.se> wrote:
>>> ...
>>> If tcpdump knew about this, it would look somewhat like:
>>> 
>>>  Init, 1.13 info 01 size 576 ver 2/0/0 timer 300
>>> 
>>> Why MIM decided to restart the link is another question.
>> I would guess that is a Multinet link, right?  A conforming DECnet implementation would not send an init message without restarting the data link layer first, which would produce a "circuit down" event.  So the unexpected packet type is indeed a reasonable complaint for it to generate.
> 
> Yes, it's a Multinet link. In addition, it's one carried over TCP, so I'm a bit curious why you would get an init packet here. When the TCP connection was lost, the circuit should have gone down.
> And you would not be able to get a new init packet before a new TCP connection was established.
> 
> But then again, I do not properly know how the Multinet implementation works internally, and I have been struggling from time to time to get it all working the right way. So I might also not be doing things in a fully matching manner to what Mutlinet does. If anyone have any knowledge of the internals of the Multinet implementation, I'd love to talk with them.

I had some traces sent to me a while ago which I used to implement the Multinet over TCP code in pydecnet.  But that doesn't show what the internals of the host looks like.

The fundamental error in the Multinet design is that, in the UDP case, it doesn't implement the data link requirements for point to point routing circuits.  In particular, there is no notion of "data link restart", of course.  So my guess would be that your Multinet endpoint doesn't bother with that for TCP either.  The correct implementation would be for a TCP connection reset to trigger a datalink shutdown notification to routing.  If that were done things would work correctly.

I have some comments in multinet.py implying that there is indeed no connection between TCP restart and Multinet restart even in TCP mode.  It's been long enough that I don't remember the details.

	paul