HECnet December 2011

hecnet@lists.dfupdate.se

27 participants
322 discussions

by bob＠jfcl.com

Peter Lothberg wrote: Redundancy is good... Not always - see below... NETPTH>legato [Routing path from SOL (59.10) to LEGATO (2.1)]

14 years

LEGATO now connected to MIM

by roll＠Stupi.SE

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:

14 years

LEGATO now connected to MIM

by bqt＠softjar.se

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

14 years

LEGATO now connected to MIM

by roll＠Stupi.SE

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)]

14 years

Merry Christmas

by wonko＠4amlunch.net

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

14 years

Merry Christmas

by hvlems＠zonnet.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

14 years

Fwd: [Johnny Billquist <bqt@softjar.se>: Re: [HECnet] Multinet Tunnel Links defined]

by bqt＠softjar.se

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

14 years

area 44

by hvlems＠zonnet.nl

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

14 years

NML not happy ... -:)

by roll＠Stupi.SE

NETPTH>MIM [Routing path from SOL (59.10) to MIM (1.13)]

14 years

I'm Back!!

by jeep＠scshome.net

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

14 years

← Newer
1
...
16
17
18
19
20
21
22
...
33
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet December 2011