HECnet

hecnet@lists.dfupdate.se

15586 discussions

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

13 years, 5 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

13 years, 5 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

13 years, 5 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?

13 years, 5 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

13 years, 5 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

13 years, 5 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 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 On Jun 22, 2012, at 6:11 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 22:25 To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet User Mode Router - Encapsulation Formats On Jun 22, 2012, at 4:07 PM, Rob Jarratt wrote: DDCMP over some kind of serial line? Would need appropriate hardware and driver code to work against that. DDCMP over sync, yes. But DDCMP also works on an async line, and that just requires protocol code that can talk to a raw mode TTY device. That would work for what I need -- I have async DDCMP on my PRO-380 running RSTS, and in fact it's a standard feature of some of the PDP11 DECnet products. (I'm not sure if it was ever official in DECnet/E, but the machinery is there in the latest versions of the kernel.) paul 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?). Regards Rob 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

13 years, 5 months

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

by mcguire＠neurotica.com

On 06/22/2012 05:33 PM, Paul_Koning at Dell.com wrote: It's a midnight project, done while at DEC but not official. I did it first on RSTS 9.6, and in fact built a set of 3 or so floppies that can be used, along with a stock microRSTS kit, to install that on a Pro. I subsequently ported it to RSTS/E 10.1 but didn't repackage it as I did the first time. Wow wow wow!! This really makes my day! Yes, new drivers for sure. New interrupt handling, too. I figured! BTW, if you can write the correct bootstrap, the stock RSTS 9.6 INIT.SYS will boot on a Pro, because the PRO supports bits made it into the official sources as far as the init code goes. If you do, it will identify the machine type as a "GPK-350" or "GPK-380". :-) Wow, I never knew this! 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..? 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! -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 5 months

DECnet User Mode Router - Encapsulation Formats

by mcguire＠neurotica.com

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

13 years, 5 months

DECnet User Mode Router - Encapsulation Formats

by Paul_Koning＠Dell.com

On Jun 22, 2012, at 6:11 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 22:25 To: hecnet at Update.UU.SE Subject: Re: [HECnet] DECnet User Mode Router - Encapsulation Formats On Jun 22, 2012, at 4:07 PM, Rob Jarratt wrote: DDCMP over some kind of serial line? Would need appropriate hardware and driver code to work against that. DDCMP over sync, yes. But DDCMP also works on an async line, and that just requires protocol code that can talk to a raw mode TTY device. That would work for what I need -- I have async DDCMP on my PRO-380 running RSTS, and in fact it's a standard feature of some of the PDP11 DECnet products. (I'm not sure if it was ever official in DECnet/E, but the machinery is there in the latest versions of the kernel.) paul 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?). Regards Rob 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. paul

13 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet