HECnet

hecnet@lists.dfupdate.se

1 participants
15560 discussions

RSTS on a Pro, was Re: [HECnet] DECnet User Mode Router - Encapsulation Formats

by Paul_Koning＠Dell.com

On Jun 22, 2012, at 8:56 PM, Dave McGuire wrote: On 06/22/2012 05:33 PM, Paul_Koning at Dell.com wrote: ... What's missing is CNA support (Ethernet). The chip used on that card sucks quite severely, and I've never had enough energy to write the driver. Urr? Doesn't the CNA use an Am7990 "Lance" chip? As I recall that isn't too bad to program. I must be misremembering what chip it uses..? Intel 82586, which has the worst programming interface in the history of Ethernet. It uses a single linked list, which is accessed both by the driver and by the chip, without interlocking. Race conditions everywhere... But I have disk, and display, and serial ports including the obscure 4-port card, DDCMP support in both sync and async mode... Wow, that is fantastic! (I keep saying "wow"! ;)) Umm...are you willing to share that stuff? =) I run RSTS 10.1 on many of my PDP-11s; I'd LOVE to run it on my Pro-350! Sure, if I can figure out a way to do it reasonably cleanly. paul

12 years, 11 months

DECnet User Mode Router - Encapsulation Formats

by Paul_Koning＠Dell.com

On Jun 23, 2012, at 2:51 AM, Rob Jarratt wrote: -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com Sent: 23 June 2012 01:49 To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet User Mode Router - Encapsulation Formats ... Version 2? Do you mean Level 2? No I mean version 2, as in this spec here: http://www.openvms.compaq.com/wizard/decnet/route20.txt I forgot about those confusing version numbers. That's DECnet Phase IV. (The "routing 1.x" spec is DECnet phase III, because that's when the routing layer first appeared -- DECnet phase II didn't have one.) paul

12 years, 11 months

Three Tons of Minicomputers

by pontus＠update.uu.se

On 06/22/2012 02:10 AM, Gregg Levine wrote: Hello! Pontus I've met Adam (LINC-8) at the VCF earlier this year, that's where David and I met (officially that is) but not the 2060. What was both of them being used at the school for? The LINC-8 was used by the department of psychology to control experiments related to human perception. The 2060 was the main computer for the Computer Science department, used by researchers, teachers and students and later by the Update computer club for several years.. /P

12 years, 11 months

DECnet User Mode Router - Encapsulation Formats

by robert.jarratt＠ntlworld.com

It is going to be a while before I am ready to debug seriously against an existing tunnel, but if you could make one available in any case that would be great so I can start to see what things look like. Beware though that I am very likely to cause stuff to break! Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Peter Lothberg Sent: 23 June 2012 15:49 To: hecnet at Update.UU.SE Cc: hecnet at Update.UU.SE Subject: RE: [HECnet] DECnet User Mode Router - Encapsulation Formats The Multinet ecap Stuart explained a while ago here on HECnet, I'll resend it. GRE is a IP protocol, like TCP and UDP. If you encap anything in GRE you have: IP header GRE Header (Protocol you are transporting part of GRE header represented with the 16 bit ether-type) Payload. csum In the case of DECnet the cisco encap is take the stuff you put in a etchernet packet, but skip headers and start at the protocol ID. Remember check what hapens with packets that decnet multicats on a lan. http://en.wikipedia.org/wiki/Generic_Routing_Encapsulation Let me knew if you run in to problems or need a tunnel to debug against. --Peter -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Dave McGuire Sent: 22 June 2012 19:34 To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet User Mode Router - Encapsulation Formats On 06/22/2012 02:31 PM, Rob Jarratt wrote: I am making a little progress on a user mode DECnet router that will run on Raspberry Pi and on Windows. There is still a long way to go, but I want to get the basic design right in terms on the network interfacing. Can someone tell me how Cisco and Multinet encapsulate DECnet packets sent over the internet? Ciscos can encapsulate DECnet within either GRE or L2TP. -Dave -- Dave McGuire, AK4HZ New Kensington, PA I hope GRE and L2TP aren't too complex. It *looks* like GRE can be transported over UDP. L2TP looks a bit more complex, but I have skimmed the Wikipedia page for all of 15 seconds so I may have missed something. Regards Rob

12 years, 11 months

DECnet User Mode Router - Encapsulation Formats

by Paul_Koning＠Dell.com

On Jun 22, 2012, at 8:53 PM, Dave McGuire wrote: On 06/22/2012 08:48 PM, Paul_Koning at Dell.com wrote: Hmmm, so if we can use async serial then we have a chance to add that to the router once I have had a chance to do the main part. It would be good to do something like that. I don't know enough about DDCMP yet to know what the implications are (can it work with a Version 2 router for example?). Version 2? Do you mean Level 2? DDCMP works in DECnet phase 1 through 4, I should remember about 5 (a.k.a., DECnet/OSI) but I don't. It's another datalink type, different from Ethernet, partly because it doesn't have addresses (it's point to point) and partly because the headers are different ("short" rather than "long" headers). But much of it is the same: routing exchanges work the same, for example. It's all spelled out in detail in the routing layer spec. The DDCMP protocol itself is in the DDCMP spec. My first exposure to its details was when I read the spec to implement the RSTS driver, and the spec is good enough that I could simply do what it says and end up with code that works. (Most of the DECnet specs are that good, actually.) It's not exactly a hard protocol; maybe a few thousand lines of assembly language code, so probably a few hundred if done in C. The point to point specific aspects of the routing layer would actually be the larger part, though not all that much larger, either. If it's that similar to DECnet over Ethernet, I would respectfully submit that the correct way to implement this would be to move as much of the DECnet code as possible into a datalink type-independent layer and have datalink layers below that, with a consistent API that serves as an abstraction layer. Having the ability to route to DDCMP-over-async-connected hosts would be really, really nice! -Dave -- Dave McGuire, AK4HZ New Kensington, PA Yes, your suggestion is exactly the right one. And the specification (the routing layer document) is organized that way, as a data link independent section and multiple data link dependent ones. The best known data link dependent section nowadays would be the Ethernet one, but there's another one for point to point links (ddcmp,hdlc) and a third for switched links (X.25). For that matter, IP has the same sort of approach, though described somewhat differently: Ethernet has MAC layer addressing and ARP to make that work, while point to point links (PPP and the like) have neither. paul

12 years, 11 months

DECnet User Mode Router - Encapsulation Formats

by roll＠Stupi.SE

.. summary.. The Multinet model looks like a point-to-point interface to DECnet where the cisco/GRE uses the ethernet model. (basic difference is how routing vectors are sent.) -P

12 years, 11 months

DECnet User Mode Router - Encapsulation Formats

by roll＠Stupi.SE

Date: Fri, 23 Dec 2011 22:37:30 PST From: Adelman at Adelman.COM (Kenneth Adelman) Reply-To: Adelman at Adelman.COM (Kenneth Adelman) Message-Id: <111223223730.9936 at ServFail.Adelman.COM> Subject: Re: Fwd: [Johnny Billquist <bqt at softjar.se>: Re: [HECnet] Multinet Tunnel Links defined] In-Reply-To: Your message <26C77BED-2D3C-40EB-BF6E-BB5A1ABAA789 at doubleshotsecurity.com> dated 23-Dec-2011 To: bqt at softjar.se, roll at Stupi.SE, hecnet at Update.UU.SE cc: merike at doubleshotsecurity.com, stuart at tae.com 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

12 years, 11 months

DECnet User Mode Router - Encapsulation Formats

by roll＠Stupi.SE

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com Sent: 22 June 2012 20:37 To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet User Mode Router - Encapsulation Formats On Jun 22, 2012, at 3:28 PM, Rob Jarratt wrote: -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com Sent: 22 June 2012 19:44 To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet User Mode Router - Encapsulation Formats Are you planning to have it speak unencapsulated, too? That would be nice for talking to real DECnet nodes. paul On Jun 22, 2012, at 2:31 PM, Rob Jarratt wrote: I am making a little progress on a user mode DECnet router that will run on Raspberry Pi and on Windows. There is still a long way to go, but I want to get the basic design right in terms on the network interfacing. Can someone tell me how Cisco and Multinet encapsulate DECnet packets sent over the internet? Thanks Rob Yes, that should be the simplest one. For that I am assuming that the router would be connected directly to the Ethernet segment, not missing anything am I? Regards Rob Right, that's what I had in mind. An Ethernet segment with a PDP11 on it along with your creation. Extra credit would be support of point to point links... which I could actually use, since my current PDP11 speaks DDCMP but not yet Ethernet (no driver for its NIC yet). That's off the wall enough that I wouldn't expect you to do it, but I would probably take it on as an additional feature. paul DDCMP over some kind of serial line? Would need appropriate hardware and driver code to work against that. Regards Rob DDCMP on a sync or async line?

12 years, 11 months

DECnet User Mode Router - Encapsulation Formats

by roll＠Stupi.SE

The Multinet ecap Stuart explained a while ago here on HECnet, I'll resend it. GRE is a IP protocol, like TCP and UDP. If you encap anything in GRE you have: IP header GRE Header (Protocol you are transporting part of GRE header represented with the 16 bit ether-type) Payload. csum In the case of DECnet the cisco encap is take the stuff you put in a etchernet packet, but skip headers and start at the protocol ID. Remember check what hapens with packets that decnet multicats on a lan. http://en.wikipedia.org/wiki/Generic_Routing_Encapsulation Let me knew if you run in to problems or need a tunnel to debug against. --Peter -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Dave McGuire Sent: 22 June 2012 19:34 To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet User Mode Router - Encapsulation Formats On 06/22/2012 02:31 PM, Rob Jarratt wrote: I am making a little progress on a user mode DECnet router that will run on Raspberry Pi and on Windows. There is still a long way to go, but I want to get the basic design right in terms on the network interfacing. Can someone tell me how Cisco and Multinet encapsulate DECnet packets sent over the internet? Ciscos can encapsulate DECnet within either GRE or L2TP. -Dave -- Dave McGuire, AK4HZ New Kensington, PA I hope GRE and L2TP aren't too complex. It *looks* like GRE can be transported over UDP. L2TP looks a bit more complex, but I have skimmed the Wikipedia page for all of 15 seconds so I may have missed something. Regards Rob

12 years, 11 months

DECnet User Mode Router - Encapsulation Formats

by robert.jarratt＠ntlworld.com

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Dave McGuire Sent: 23 June 2012 01:54 To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet User Mode Router - Encapsulation Formats On 06/22/2012 08:48 PM, Paul_Koning at Dell.com wrote: Hmmm, so if we can use async serial then we have a chance to add that to the router once I have had a chance to do the main part. It would be good to do something like that. I don't know enough about DDCMP yet to know what the implications are (can it work with a Version 2 router for example?). Version 2? Do you mean Level 2? DDCMP works in DECnet phase 1 through 4, I should remember about 5 (a.k.a., DECnet/OSI) but I don't. It's another datalink type, different from Ethernet, partly because it doesn't have addresses (it's point to point) and partly because the headers are different ("short" rather than "long" headers). But much of it is the same: routing exchanges work the same, for example. It's all spelled out in detail in the routing layer spec. The DDCMP protocol itself is in the DDCMP spec. My first exposure to its details was when I read the spec to implement the RSTS driver, and the spec is good enough that I could simply do what it says and end up with code that works. (Most of the DECnet specs are that good, actually.) It's not exactly a hard protocol; maybe a few thousand lines of assembly language code, so probably a few hundred if done in C. The point to point specific aspects of the routing layer would actually be the larger part, though not all that much larger, either. If it's that similar to DECnet over Ethernet, I would respectfully submit that the correct way to implement this would be to move as much of the DECnet code as possible into a datalink type-independent layer and have datalink layers below that, with a consistent API that serves as an abstraction layer. I agree and this is exactly what I am doing. Having the ability to route to DDCMP-over-async-connected hosts would be really, really nice! -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet