23 Oct
2018
23 Oct
'18
5:44 p.m.
On Oct 23, 2018, at 10:48 AM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2018-10-23 15:51, Paul Koning wrote:
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
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.