On 2011-12-26 15.24, Johnny Billquist wrote:
On 2011-12-26 15.07, Bob Armstrong wrote:
Hmmm . LEGATO can t talk to ROOSTA ( remote node not currently
reachable ) even though there s a direct Multinet link to ROOSTA (and
yes, the link is UP and working).
I think the problem is that ROOSTA is in area 6, and the area router for
6 is STAR69. Trouble is, STAR69 doesn t have a path to ROOSTA and
doesn t know how to send it packets.
Unless ROOSTA is an area router, that link makes no sense. You cannot
have (usable) links between different areas unless both ends are area
routers...
It would appear something is more broken currently. I can't talk to SG1 from MIM either, and thus nothing beyond it. And SG1 is currently acting as the next hop for a whole bunch of areas, as seen from area 1.
Also, while I'm at it: NIKKEL - There is some issue with that machine too. Can others talk with it?
Johnny
Unless ROOSTA is an area router, that link makes no sense.
I won't argue with you about that... I can't fix it from here, though.
But does DECnet allow two different area routers, with different subsets of
reachable nodes, for the same area??
Bob
On 2011-12-26 15.07, Bob Armstrong wrote:
Hmmm . LEGATO can t talk to ROOSTA ( remote node not currently
reachable ) even though there s a direct Multinet link to ROOSTA (and
yes, the link is UP and working).
I think the problem is that ROOSTA is in area 6, and the area router for
6 is STAR69. Trouble is, STAR69 doesn t have a path to ROOSTA and
doesn t know how to send it packets.
Unless ROOSTA is an area router, that link makes no sense. You cannot have (usable) links between different areas unless both ends are area routers...
Johnny
Do you know which task/object NETPTH tries to talk to? Obviously MIM
don't have one running, but depending on what, it might be something
that I just have not set up. Is NML the object? What is NML?
It sends the same requests that you would send to a another node using NCP
to ask for example about the known circuits.
FWIW, it works for me -
$ ncp tell mim show act cir
Active Circuit Volatile Summary as of 26-DEC-2011 06:18:14
Circuit State Loopback Adjacent
Name Routing Node
UNA-0 on 11.2 (MAISA)
UNA-0 2.1 (LEGATO)
UNA-0 42.1 (CANADA)
UNA-0 1.300 (CTAKAH)
UNA-0 19.41 (SG1)
UNA-0 4.249 (SLAVE)
UNA-0 44.21 (NIKKEL)
UNA-0 1.301 (CTEPBA)
UNA-0 1.350 (ERSATZ)
It's pretty slow, though. Maybe the timeout in NETPTH is too short.
Bob
Do you know which task/object NETPTH tries to talk to? Obviously MIM
don't have one running, but depending on what, it might be something
that I just have not set up. Is NML the object? What is NML?
It sends the same requests that you would send to a another node using
NCP to ask for example about the known circuits.
On Tops10/20 it's a program part of galy "NMLTxx" that the monitor
passes all network management requuests to. The code bliss has traces of
PDP11 stuff, as there was a rs20f phase 3 front-end.
--Peter
!++
! FACILITY: DECnet-10/20 V3.0 Network Management Layer (NML)
!
! ABSTRACT:
!
! This module performs the NML NICE remote request receive
! function.
!
! ENVIRONMENT: TOPS-10/20 & MCB/RSX11 User mode under NML
!
! AUTHOR: Dale C. Gunn , CREATION DATE: 20-Jan-81
!
! MODIFIED BY:
On 2011-12-26 10.07, Peter Lothberg wrote:
I've kept all the Multinet circuits that I had before, and I don't mind
continuing to carry them, although several of them now represent redundant
paths.
Redundancy is good... (as long as managing it cases less network
stability...)
Indeed.
Speaking of which, does DECnet have anything equivalent to the tracert
program ??
..long lines.. So it querries the NML objects to figure out the
topology, and some nodes, like Mim, don't respond. DECnet don't have
TTL expire control messages.
Do you know which task/object NETPTH tries to talk to? Obviously MIM don't have one running, but depending on what, it might be something that I just have not set up. Is NML the object? What is NML?
Otherwise, it should be possible to write something similar on your own, using NICE. For each hop, check what the next hop is for the destination. Should actually be more accurate than traceroute in IP, which don't really neccesarily give the truth, but just what happened for a bunch of packets sent before, all of which might not even have traveled the same path themself.
Johnny
I've kept all the Multinet circuits that I had before, and I don't mind
continuing to carry them, although several of them now represent redundant
paths.
Redundancy is good... (as long as managing it cases less network
stability...)
Speaking of which, does DECnet have anything equivalent to the tracert
program ??
..long lines.. So it querries the NML objects to figure out the
topology, and some nodes, like Mim, don't respond. DECnet don't have
TTL expire control messages.
NETPTH is on the KLAD-pack, but I don't have the sourcves online (or
knew if I have still have them.)
NETPTH>legato
[Routing path from SOL (59.10) to LEGATO (2.1)]
I second that! A Merry Christmas to all who celebrate it and a Happy <insert holiday here> to those who don't!
-brian
On Dec 25, 2011, at 6:18, "H Vlems" <hvlems at zonnet.nl> wrote:
A Merry Christmas to all of you!
Hans Vlems
PS
The Top 2000 just started on Radio 2 (dutch radio) which is also available
thru the internet
see: www.radio2.nl
A Merry Christmas to all of you!
Hans Vlems
PS
The Top 2000 just started on Radio 2 (dutch radio) which is also available
thru the internet
see: www.radio2.nl
Thanks, Kenneth.
Good stuff in there.
Since I'm thinking of this in terms of a PDP-11, byte ordering is not an issue. :-)
I have a dump of some packets between to VMS machines as well. With your information, I think this should now not be much trouble getting working. I'll just have to find some time (as always the biggest problem). :-)
Johnny
On 2011-12-24 07.37, Kenneth Adelman wrote:
Hunter Goatley would have the access to the code to give you a
definitive answer, but I'm the one who reverse-engineered and coded
the first version. It has been over 15 years since I had access to the
source code, so all of this is from memory.
Basically, I wrote a VMS device driver that looked like a
point-to-point line card to the operating system and transported the
packets over UDP (or TCP), where they were delivered into DECnet on
the other end. I didn't know (or care) anything about the DECnet
protocols at the time, presumably some of which are implemented in the
line card and some in the host software, so I'm not sure where you
might "hook in" to the stack in another implementation.
For the UDP implementation each side did a bind() to a local IP
address and port and a connect() to "fix" the remote IP address and
port (the ports were all the same, but I don't recall the number
anymore). Datagrams were one-for-one with the data received from
DECnet, except a very thin header was added. My recollection is that
the header had a two-byte sequence count (more on this later) which
was incremented by the sender for each packet and may have had a
two-byte length. Be suspicous that these are in VAX byte order
(little endian) instead of network byte order (big endian). It should be
easy to reverse-engineer if you have a packet trace from two VMS
machines communicating.
For the TCP implementation one end was always passive and the
other the active connector. This was chosen by a comparison of the IP
addresses to see which was "smaller". The DECnet packets were framed
inside the TCP stream by prefixing them with a length and I suspect
also they may or may not have had a sequence count for "uniformity".
The receiver read the length and then used the length to know how much
data to read and deliver upstream.
Early versions of DECnet (I think this was fixed in the early 4.x
timeframe, but I may be wrong) made an assumption of point-to-point
line cards that packets would never arrive out-of-order, and if they did,
it would drop synchronization on the line and reset. The purpose of the
sequence count (transmitted by all implementations) was to allow
the receiving driver (I believe it checked if it was one of the buggy
versions of DECnet) to drop out-of-order packets (which DECnet was
happy to recover from) rather than deliver them upstream. Obviously
this wasn't an issue with TCP as a transport.
TCP wasn't used frequently as a transport, but worked on
long-haul links because TCP's retransmission algorithems at the
time were substaintially better than DECnets.
I don't think there was anything else in the header (eg, a
protocol version number), but there probably should have been.
Now more interesting would be to do a DECnot implementation.
This was the wholesale replacement of the DECnet stack with a
mapping layer that mapped requests directly into TCP connections.
This gave you DECnet functionality over TCP without any DECnet routing,
eg,
$ set host kaos.tgv.com
The protocol for this was a LOT more complex and would require source
code to jog my memory...
Ken
NIKKEL is up and running again. One of its 8 4 MB memory boards failed. The
system disk (an RZ26) was not the problem apparently...
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
hvlems at zonnet.nl
Verzonden: vrijdag, december 2011 0:48
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] area 44
NIKKEL just crashed again whiile installing decnet. So perhaps a memory
problem (too). Off to bed.
------Origineel bericht------
Van: Steve Davidson
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] area 44
Verzonden: 23 december 2011 00:01
Correction:
Make that 13:56:27.29 Eastern (18:56:27.29 UTC).
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of hvlems at zonnet.nl
Sent: Thursday, December 22, 2011 4:23 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] area 44
NIKKEL just lost its system disk. OZON is now the area router.
Did someone see at what time NIKKEL went south, and area 44 with it?
Hans
Welcome BACK!
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Brian Hechinger
Sent: Friday, December 23, 2011 9:52 AM
To: hecnet at Update.UU.SE
Subject: [HECnet] I'm Back!!
RIFTER$ mcr ncp show known circuits
Known Circuit Volatile Summary as of 23-DEC-2011 09:50:26
Circuit State Loopback Adjacent
Name Routing Node
QNA-0 on
TCP-0-19 on 19.41 (SG1)
RIFTER$ mcr ncp show known areas
Known Area Volatile Summary as of 23-DEC-2011 09:50:31
Area State Circuit Next node to area
1 reachable TCP-0-19 19.41 (SG1)
2 reachable TCP-0-19 19.41 (SG1)
3 reachable TCP-0-19 19.41 (SG1)
4 reachable TCP-0-19 19.41 (SG1)
6 reachable TCP-0-19 19.41 (SG1)
8 reachable TCP-0-19 19.41 (SG1)
11 reachable TCP-0-19 19.41 (SG1)
19 reachable TCP-0-19 19.41 (SG1)
20 reachable TCP-0-19 19.41 (SG1)
33 reachable TCP-0-19 19.41 (SG1)
42 reachable TCP-0-19 19.41 (SG1)
44 reachable TCP-0-19 19.41 (SG1)
52 reachable 52.2 (RIFTER)
54 reachable TCP-0-19 19.41 (SG1)
59 reachable TCP-0-19 19.41 (SG1)
RIFTER$
The last time I was joined to HECnet was 11 years ago!!
That got me thinking about that time. Things were much different back
then. Johnny's bridge program didn't bridge ethernet at that time. It
bridged serial!
-brian
RIFTER$ mcr ncp show known circuits
Known Circuit Volatile Summary as of 23-DEC-2011 09:50:26
Circuit State Loopback Adjacent
Name Routing Node
QNA-0 on
TCP-0-19 on 19.41 (SG1)
RIFTER$ mcr ncp show known areas
Known Area Volatile Summary as of 23-DEC-2011 09:50:31
Area State Circuit Next node to area
1 reachable TCP-0-19 19.41 (SG1)
2 reachable TCP-0-19 19.41 (SG1)
3 reachable TCP-0-19 19.41 (SG1)
4 reachable TCP-0-19 19.41 (SG1)
6 reachable TCP-0-19 19.41 (SG1)
8 reachable TCP-0-19 19.41 (SG1)
11 reachable TCP-0-19 19.41 (SG1)
19 reachable TCP-0-19 19.41 (SG1)
20 reachable TCP-0-19 19.41 (SG1)
33 reachable TCP-0-19 19.41 (SG1)
42 reachable TCP-0-19 19.41 (SG1)
44 reachable TCP-0-19 19.41 (SG1)
52 reachable 52.2 (RIFTER)
54 reachable TCP-0-19 19.41 (SG1)
59 reachable TCP-0-19 19.41 (SG1)
RIFTER$
The last time I was joined to HECnet was 11 years ago!!
That got me thinking about that time. Things were much different back then. Johnny's bridge program didn't bridge ethernet at that time. It bridged serial!
-brian
I'd like to install axp/vms v8.4 on one of my systems. Are the os and layered products cd's available for download (as an nero, dd output or iso file) on HECnet?
Hans
On 22/12/11 17:58, Marc Chametzky wrote:
Interesting. Could anyone grab a bunch of frames with tcpdump and send
to me?
Here's the output from a tcpdump while doing a "MCR NCP TELL MIM SHOW
EXEC".
I did some reverse engineering of Multinet IP protocol for DECnet-Linux. The code is in CVS here
http://linux-decnet.cvs.sourceforge.net/viewvc/linux-decnet/dnprogs/multine…
It's not perfect (or even good) but it might be a starting point for you.
Chrissie
NIKKEL just crashed again whiile installing decnet. So perhaps a memory problem (too). Off to bed.
------Origineel bericht------
Van: Steve Davidson
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] area 44
Verzonden: 23 december 2011 00:01
Correction:
Make that 13:56:27.29 Eastern (18:56:27.29 UTC).
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of hvlems at zonnet.nl
Sent: Thursday, December 22, 2011 4:23 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] area 44
NIKKEL just lost its system disk. OZON is now the area router.
Did someone see at what time NIKKEL went south, and area 44 with it?
Hans
Netherlands is UTC+1 so that would make it around 8 PM. I went upstairs half an hour later, booted a few alphas and noticed that NIKKEL was unreachable.
Well, the old girl will be up in another hour. It's -90A not a 60 btw.
------Origineel bericht------
Van: Steve Davidson
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] area 44
Verzonden: 23 december 2011 00:01
Correction:
Make that 13:56:27.29 Eastern (18:56:27.29 UTC).
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of hvlems at zonnet.nl
Sent: Thursday, December 22, 2011 4:23 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] area 44
NIKKEL just lost its system disk. OZON is now the area router.
Did someone see at what time NIKKEL went south, and area 44 with it?
Hans
Steve, I just did not know. There was no other VMS system running so no logs to read.
I'm reinstalling VMS on Ni right now. I'm out of 50 pin scsi drives, luckily I found a 50 to 68 pin converter and I have lenty 68 pin drives.
Hans
------Origineel bericht------
Van: Steve Davidson
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] area 44
Verzonden: 22 december 2011 23:57
Hans,
The operator log on SG1:: said 19:15.13 (UTC). Does that sound about
right???
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of hvlems at zonnet.nl
Sent: Thursday, December 22, 2011 4:23 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] area 44
NIKKEL just lost its system disk. OZON is now the area router.
Did someone see at what time NIKKEL went south, and area 44 with it?
Hans
Correction:
Make that 13:56:27.29 Eastern (18:56:27.29 UTC).
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of hvlems at zonnet.nl
Sent: Thursday, December 22, 2011 4:23 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] area 44
NIKKEL just lost its system disk. OZON is now the area router.
Did someone see at what time NIKKEL went south, and area 44 with it?
Hans
Hans,
The operator log on SG1:: said 19:15.13 (UTC). Does that sound about
right???
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of hvlems at zonnet.nl
Sent: Thursday, December 22, 2011 4:23 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] area 44
NIKKEL just lost its system disk. OZON is now the area router.
Did someone see at what time NIKKEL went south, and area 44 with it?
Hans
It's NOT nice to shake VAX 2000's, even though it probably needed it!
:-)
Well, I really only wanted to shake the RD54, but it's way too much trouble
to take it out and put it back in again so I hope CHEKOV will forgive me :-)
Regards,
Peter Coghlan.
BTP::PETER
On Thu, 22 Dec 2011 18:36:52 +0100, you wrote:
Speaking of Multinet and DECnet-over-IP. I just got this crazy idea to
implement DECnet-over-IP tunneling in RSX, and it would be fun to be
compatible.
Have anyone analyzed, or read any documentation on how the tunneling is
done? TCP or UDP? Any additional headers or data in the stream in
addition to the encapsulated DECnet packets?
IIRC, you can find a daemon to interface with Multinet tunnels into the
Linux DECnet tools package. That should be a good starting point where to
discover what would be needed to write a new RSX interface, at least in
terms of packet structures and such. :)
HTH,
G.