23 Oct
2018
23 Oct
'18
10:54 a.m.
supratim sanyal wrote:
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.
--Johnny
23 Oct
23 Oct
3:51 p.m.
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.
paul
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. 
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.
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. 
6:22 p.m.
What in the world is pydecnet? Google surprisingly comes up empty! Python implementation
of DECnet? How does one get their hands on it?
On Oct 23, 2018, at 11:44 AM, Paul Koning
<paulkoning at comcast.net> wrote:
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.
6:50 p.m.
On Oct 23, 2018, at 12:22 PM, Supratim Sanyal
<supratim at riseup.net> wrote:
What in the world is pydecnet? Google surprisingly comes up empty! Python implementation
of DECnet? How does one get their hands on it?
Interesting that it comes up empty.
Yes, an implementation of DECnet in Python. I've mentioned it on this list in the
past. It's not finished but a fair amount is done, in particular the lower layers
(datalink and routing).
Look in svn://akdesign.dyndns.org/pydecnet/trunk/pydecnet (using Subversion).
paul
6:56 p.m.
On 10/23/2018 12:50, Paul Koning wrote:
Thank you, Paul. I am playing with a Hercules-emulated IBM Z/Arch S/390
Mainframe running Ubuntu 18; perhaps it will be possible for Linux/s390x
to speak DECnet using pydecnet! Will get around to giving it a shot
sometime hopefully soon.
Supratim
--
Sent via Thunderbird for Windows 10 on Lenovo Legion Y720
On Oct 23, 2018, at 12:22 PM, Supratim Sanyal
<supratim at riseup.net> wrote:
What in the world is pydecnet? Google surprisingly comes up empty! Python implementation
of DECnet? How does one get their hands on it?
Interesting that it comes up empty.
Yes, an implementation of DECnet in Python. I've mentioned it on this list in the
past. It's not finished but a fair amount is done, in particular the lower layers
(datalink and routing).
Look in svn://akdesign.dyndns.org/pydecnet/trunk/pydecnet (using Subversion).
paul
7:45 p.m.
Hi, Paul. We've had plenty of discussions about this in the past... :-)
On 2018-10-23 17:44, Paul Koning wrote:
Same here. And my problems are really about what Multinet might be doing
internally, as it is not as trivial and straight forward as one might
hope. Or at least it is not on the RSX side.
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.
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. 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.
Sortof. Yes, there is indeed a problem here related to UDP.
However, at least my code do handle TCP in the sane way you might think
it should. So RSX DECnet definitely gets a line down notification when
the TCP connection is lost. And once it is reestablished the line goes
up and DECnet can renegotiate.
Which is why I am wondering why, on the VMS side, you see an INIT
message out of sequence. It should only come when the line comes up,
which naturally should only happen when the TCP connection is established.
So, what is Multinet actually doing here???
As for the UDP case, it's way more tricky, at least on the RSX side, as
I cannot trivially detect when a link comes up. And RSX DECnet will only
send one INIT packet when the line comes up. So I need to keep that INIT
packet internally on my Multinet-side, and retransmit it on a regular
basis until the other side responds with an INIT packet of its own, at
which time I can proceed with the relaying of packets between DECnet and
the remote side, and let the link become established. But that also
means I need to detect if a new INIT packet happens, since that needs to
restart the syncing. So at an INIT I need to tell DECnet that the line
went down, and then up again, so that RSX DECnet will send a new INIT
packet.
And at startup I need to filter out if I happen to get multiple INIT
packets, since I only want to deliver one to DECnet.
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.
That would be interesting to know more of the story behind. I can't see
how Multinet would not signal a line down when the TCP connection is
lost. And it would be pretty obvious that the line comes back up when
the TCP connection is established.
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
7:39 p.m.
$ 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.
Bob
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.
8:08 p.m.
What clearly is going on is that the TCP connection
(in that mode) might
be reopened if the network is flaky, ..
I just searched thru my logs, and I can confirm that it happens on UDP
links as well -
From node 2.1 (LEGATO), 20-OCT-2018 00:17:17.67
Circuit TCP-0-3, Unexpected packet type, Adjacent node = 3.47
(RVDSXL)
Packet beginning = 012F0C0540020200002C01000404FF7F
.....
$! TCP-0-3 rvdsxl.rv13.net rok.vidmar at gmail.com
$ sysgen connect tcpa3:/noadapter/driver=tcpdriver
$ multinet set/decnet/remote=193.2.191.212 /device=tcpa3:/connect
I can see where a TCP link could be disconnected by some network hiccup, but
UDP links are stateless. What could cause one of them to become
disconnected and restart?
Bob
8:14 p.m.
I searched my logs more exhaustively, and there are a lot of these "bad
packet, down/up" events for MIM, and a few for RVDSXL and MASON. There are
none in that same period for FRUGAL or STUPI, even though those links were
up too.
Don't know what it all means...
Bob
8:59 p.m.
On 2018-10-23 20:14, Robert Armstrong wrote:
I searched my logs more exhaustively, and there are
a lot of these "bad
packet, down/up" events for MIM, and a few for RVDSXL and MASON. There are
none in that same period for FRUGAL or STUPI, even though those links were
up too.
Don't know what it all means...
Be aware that I am fiddling with things on Mim at the moment, so there
are random reboots going on. Sorry for the inconvenience, but I have
found a test scenario that is rather interesting for getting my TCP to
perform somewhat more optimal under high latency network conditions with
noticeable packet drop.
That said, I do find it a big "buggy" that VMS Multinet then do not
appear to signal that the line went down when the TCP connection is lost.
It's understandable that this don't happen for UDP, where there are no
concept of established links, but for TCP they could/should have done
this. I have certainly done this on the RSX side, but I can't do much
beyond that.
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
8:55 p.m.
On 2018-10-23 20:08, Robert Armstrong wrote:
System reboot for example?
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
What clearly
is going on is that the TCP connection (in that mode) might
be reopened if the network is flaky, ..
I just searched thru my logs, and I can confirm that it happens on UDP
links as well -
From node 2.1 (LEGATO), 20-OCT-2018 00:17:17.67
Circuit TCP-0-3, Unexpected packet type, Adjacent node = 3.47
(RVDSXL)
Packet beginning = 012F0C0540020200002C01000404FF7F
.....
$! TCP-0-3 rvdsxl.rv13.net rok.vidmar at gmail.com
$ sysgen connect tcpa3:/noadapter/driver=tcpdriver
$ multinet set/decnet/remote=193.2.191.212 /device=tcpa3:/connect
I can see where a TCP link could be disconnected by some network hiccup, but
UDP links are stateless. What could cause one of them to become
disconnected and restart?
2013
days inactive
2013
days old
13 comments
5 participants
participants (5)
-
bob＠jfcl.com -
bqt＠softjar.se -
bygg＠cafax.se -
paulkoning＠comcast.net -
supratim＠riseup.net