DECnet over IP

If you have TGV Multinet (oops, TGV was bought by cisco and then sold to Process Software), you can have it encapsulate DECNET onto TCPIP right on the VMS node.

If you downgrade from DECNET-4 to the more complex DECNET 5, you can also encapsulate DECNET into TCPIP packets. None of the above two require router support.

Thank you for your reply.

Unfortunately the devices I wish to communicate with are not computers, or at least not ones that I can install any software on.

I will be generating and interpreting DECnet packets myself on my PC... the problem is that my programming language does not have any DECnet drivers, or the ability to send or recieve raw or custom made packets though my ethernet card. I can however send and recieve TCP or UDP. I was hoping I could send a UDP packet to a router and have it strip off the UDP header and spit out the DECnet packet I created onto the DECnet network. On the flip side I was hoping to route all incomming DECnet traffic to my PC.

It was suggested to me to use something called GRE on cisco routers. The router would have a DECnet aware feature set. If this is the best option, would you know what model of router I would need and what software?

I am of course open to a software solution if one exists.

Best regards.

~ ~ Thank you for your reply. ~ ~ Unfortunately the devices I wish to communicate with are not computers, ~ or at least not ones that I can install any software on. ~ ~ I will be generating and interpreting DECnet packets myself on my PC... ~ the problem is that my programming language does not have any DECnet ~ drivers, or the ability to send or recieve raw or custom made packets ~ though my ethernet card. I can however send and recieve TCP or UDP. ~ I was hoping I could send a UDP packet to a router and have it strip ~ off the UDP header and spit out the DECnet packet I created onto the ~ DECnet network. On the flip side I was hoping to route all incomming ~ DECnet traffic to my PC. ~ ~ It was suggested to me to use something called GRE on cisco routers. ~ The router would have a DECnet aware feature set. If this is the best ~ option, would you know what model of router I would need and what ~ software? ~ ~ I am of course open to a software solution if one exists. ~ ~ Best regards.

Well, I suppose you could buy a router (or, if you wanted to do something useful, a pair of routers) that could encapsulate DECnet IV in GRE in IP. So this would let you transport DECnet IV packets betwee point A and point B via a tunnel over an IP network.

This wouldn't do you any good though, because what you're really saying that you're looking for is a protocol translator, to translate between your TCP or UDP transport packets and the DECnet IV packets that your mystery device wants to see. A DECnet tunnel just takes DECnet packets in on one end and spits them out unchanged on the other end, which won't do you any good.

I am not aware of any such protocol translator. I think you will want to get a native DECnet IV stack for your PC. If memory serves, a company called Thusby Systems made such a thing. It would take some sleuthwork to track that code down however ... a quick Google scan did not provide a pointer to its resting place.

Can you run Linux on your PC? It appears that their exists a DECnet IV open source implementation: see

.

Have fun,

Aaron

I was the one who suggested GRE (over in comp.protocols.tcp-ip) in response to a question that asked whether he could generate UDP and get a Cisco router to strip off the UDP header and put the resulting DECnet frame on the wire.

The motivation for the question was that he had the ability to craft UDP frames on his PC but not the ability to craft DECnet frames.

If he had the ability to craft GRE frames then a Cisco router with a Tunnel interface could most certainly strip off the GRE encapsulation and forward the embedded DECnet packet or, in the reverse direction, accept a DECnet frame, apply GRE encapsulation and forward it to the user's PC.

Whether he has the ability to craft (or receive) GRE frames I haven't seen answered yet.

I agree that this is probably not an optimum solution to the underlying problem. It was merely a response to the question as asked.

I hope that its wasn't bad form to post a similar question in this group as I did in comp.protocols.tcp-ip. I thought this was the best place to find appropriate models of routers that might do as you suggested.

I don't believe I can create GRE packets. Anything I send using my programming language will either have a UDP or TCP header stuck onto it. I am really quite surprised that the programming language does not alow me to dump whatever I want to the network. (It is equally complicated recieving anything other than UDP).

The "Translation" idea sounds fantasitc... if such a thing could be made to work. I had envisioned sending something along the lines of , and have some device strip off the first part. In the other direction I assumed I would have to route every DECnet packet to my computer - though it would be infinately better to "translate" or send only the packets addressed to my PC.

The devices in question are connected together with a hub and nothing else I believe. When I "listen-in" using Wireshark I see many DECnet packets from the various devices.

Best regards.

We provide such a device, called the SyncServer. A client program does writes, UDP carries the data to the SyncServer, it sends the data out the serial port as an HDLC frame. Similar for received HDLC frames.

The above is for "raw framed synchronous" as the configured serial interface protocol. We support protocol stacks on the serial interface so that the client app doesn't have to do them, but unfortunately DECnet would be a custom effort.

Regards, Steve

[ adding comp.os.vms, my old stomping grounds ]

On 4 Jan 2007 15:23:16 -0600, snipped-for-privacy@encompasserve.org wrote:

~ In article , Aaron Leonard writes: ~ > On 4 Jan 2007 10:12:34 -0800, "FMonkey" wrote: ~ > ~ > ~ ~ > ~ Thank you for your reply. ~ > ~ ~ > ~ Unfortunately the devices I wish to communicate with are not computers, ~ > ~ or at least not ones that I can install any software on. ~ > ~ ~ > ~ I will be generating and interpreting DECnet packets myself on my PC... ~ > ~ the problem is that my programming language does not have any DECnet ~ > ~ drivers, or the ability to send or recieve raw or custom made packets ~ > ~ though my ethernet card. I can however send and recieve TCP or UDP. ~ > ~ I was hoping I could send a UDP packet to a router and have it strip ~ > ~ off the UDP header and spit out the DECnet packet I created onto the ~ > ~ DECnet network. On the flip side I was hoping to route all incomming ~ > ~ DECnet traffic to my PC. ~ > ~ ~ > ~ It was suggested to me to use something called GRE on cisco routers. ~ > ~ The router would have a DECnet aware feature set. If this is the best ~ > ~ option, would you know what model of router I would need and what ~ > ~ software? ~ > ~ ~ > ~ I am of course open to a software solution if one exists. ~ > ~ ~ > ~ Best regards. ~ > ~ > ~ > Well, I suppose you could buy a router (or, if you wanted to do something ~ > useful, a pair of routers) that could encapsulate DECnet IV in GRE in IP. ~ > So this would let you transport DECnet IV packets betwee point A and point ~ > B via a tunnel over an IP network. ~ > ~ > This wouldn't do you any good though, because what you're really saying ~ > that you're looking for is a protocol translator, to translate between ~ > your TCP or UDP transport packets and the DECnet IV packets that your ~ > mystery device wants to see. A DECnet tunnel just takes DECnet packets ~ > in on one end and spits them out unchanged on the other end, which won't ~ > do you any good. ~ ~ I was the one who suggested GRE (over in comp.protocols.tcp-ip) in ~ response to a question that asked whether he could generate UDP and ~ get a Cisco router to strip off the UDP header and put the resulting ~ DECnet frame on the wire. ~ ~ The motivation for the question was that he had the ability to craft ~ UDP frames on his PC but not the ability to craft DECnet frames. ~ ~ If he had the ability to craft GRE frames then a Cisco router ~ with a Tunnel interface could most certainly strip off the GRE ~ encapsulation and forward the embedded DECnet packet or, in the ~ reverse direction, accept a DECnet frame, apply GRE encapsulation ~ and forward it to the user's PC. ~ ~ Whether he has the ability to craft (or receive) GRE frames I haven't ~ seen answered yet. ~ ~ I agree that this is probably not an optimum solution to the underlying ~ problem. It was merely a response to the question as asked.

You make your scheme sound a lot easier than it really would be.

Your picture looks like this:

[ PC ] [ router ] [ app ] [ DECnet ] [ mystery device ] [ shim] [ GRE ] [ app ] [ IP ] [ IP ] [ DECnet ] |______ IP network ____ _____DECnet network___

The goal is to get app in PC communicating with app in mystery device. To achieve this, it would be insufficient for the shim in the PC merely to take the app data, slap some DECnet/GRE headers on the data, and hunk the packet out its raw IP interface. The router needs to achieve and sustain DECnetIV reachability status with the router (or spoofed router) on the far side of its GRE tunnel, and the DECnet stack in mystery device needs to achieve and sustain a DECnet NSP (reliable transport) connection with an NSP state machine in its communications peer.

So, the "shim" in the PC would have to implement a full DECnet stack, including routing code - or at least enough of the stack to fool the router and the mystery device. This would be a nontrivial exercise.

That's why I predict that the o.p. will wind up having to get a real DECnet stack for his PC. The quest for a DECnet-TCP (or DECnet-UDP) transport layer protocol translator will provide chimerical, I predict.

A proof of nonexistence is difficult to achieve, but if no one in comp.os.vms has heard of such a protocol translator, that would be pretty close to such a proof.

Aaron

I have no idea if this could be made to work however:-

It strikes me that perhaps a serial link be used between an IP terminal server (whch I know a bit about) and a DECnet terminal server (which I presume exists or existed) to provide the required translation?

[ PC ] [ app ] [mystery device ] [ shim] [term serv]__Serial__[term serv] [ app ] [ IP ] [ IP ] [ DECnet ] [ DECnet ] |____IP____ | |____DECnet_____|

Now a cisco router can be used as an IP terminal server and may well be able to be a DECnet terminal server. Don't know.

If this does work at all there will be some issues.

1. Limited to low bandwidth async links. (115k bps?)
2. The "packets" will not necessarily be maintained as packets on the IP side you will see a TCP stream. DECnet side???

Just a crazy idea - no idea of practicality.

Pardon my butting in here. Aaron cross-posted to comp.os.vms.

When you say "IP terminal server", I assume you are referring to any terminal server which will perform both "normal" and "reverse" TELNET. Later DECservers provide(d) support for TCP/IP in this way.

Not sure what you mean here. "DECnet" does not use "terminal servers". Terminal sessions between systems running a DECnet stack were usually performed using the "SET HOST" command which invokes the RTPAD image. The session is usually conducted using the CTERM (Console Terminal) protocol, a DECnet packet sub-type.

In the DEC realm, terminal servers usually operated using LAT or "Local Area Transport", a non-routable protocol which frequently mistaken for being part of DECnet - it is actually a distinct packet type and operates independent of any DECnet stack elements.

Where you show "DECnet" here substitute either "LAT" or "TELNET".

This was actually a common solution in the pre-IP days, and it "just worked" without further intervention once you got it going - more reliable than TCP/IP, even!

I just assumed that there would be DECnet terminal servers.

If there are not then no use.

I see that comp.protocols.tcpip has a possible solution anyway using GRE and another using winpcap (pcap?) to send arbitrary packets.

No, as mentioned, LAT was typically used in non-IP environments.

Tell me more, if you can, about your "mystery device". If we can identify it, we may be able to arrive at a better solution.

Make?

Model Number?

Any indications regarding the software it runs?

Does it boot itself or boot from another machine over Ethernet?

If from another machine, do you know the boot protocol? (MOP, BOOTP, etc.)

Any additional info. would be useful. DECnet being what it is, such devices usually interacted with software running on a host system that could "speak" DECnet, such as RSX, RSTS, VMS, etc.