23 Oct
2018
23 Oct
'18
4:48 p.m.
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.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Oct 23, 2018, at 3:54 AM, Johnny Eriksson
<bygg at cafax.se> wrote:
supratim sanyal wrote:
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. Johnny,
The other Johnny will now give a short answer:
I am suddenly seeing this from IMPVAX. Not sure
what to make of this
$ 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
The packet in question is an init packet, used to start up a link.
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.