DECnet over IP

Discussion in 'Cisco' started by FMonkey, Jan 3, 2007.

  1. FMonkey

    FMonkey Guest

    Could someone suggest the simplest (and least expensive) cisco router
    that could encapsulate (and de-encapsulate) DECnet traffic into TCP or
    UDP packets? I am network newbie. Thanks.
     
    FMonkey, Jan 3, 2007
    #1
    1. Advertisements

  2. FMonkey

    JF Mezei Guest

    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.
     
    JF Mezei, Jan 4, 2007
    #2
    1. Advertisements

  3. FMonkey

    FMonkey Guest

    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.
     
    FMonkey, Jan 4, 2007
    #3
  4. ~
    ~ 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 http://linux-decnet.sourceforge.net/ .

    Have fun,

    Aaron
     
    Aaron Leonard, Jan 4, 2007
    #4
  5. FMonkey

    briggs Guest

    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.
     
    briggs, Jan 4, 2007
    #5
  6. FMonkey

    FMonkey Guest

    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
    <UDP header><DECnet header><data>, 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.
     
    FMonkey, Jan 5, 2007
    #6
  7. 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.

    http://www.wanware.com/products_syncserver.html

    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
     
    steve_schefter, Jan 5, 2007
    #7
  8. [ adding comp.os.vms, my old stomping grounds ]

    On 4 Jan 2007 15:23:16 -0600, 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
     
    Aaron Leonard, Jan 5, 2007
    #8
  9. FMonkey

    Bod43 Guest

    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.
     
    Bod43, Jan 6, 2007
    #9
  10. 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!

    --
    David J Dachtera
    dba DJE Systems
    http://www.djesys.com/

    Unofficial OpenVMS Marketing Home Page
    http://www.djesys.com/vms/market/

    Unofficial Affordable OpenVMS Home Page:
    http://www.djesys.com/vms/soho/

    Unofficial OpenVMS-IA32 Home Page:
    http://www.djesys.com/vms/ia32/

    Unofficial OpenVMS Hobbyist Support Page:
    http://www.djesys.com/vms/support/
     
    David J Dachtera, Jan 6, 2007
    #10
  11. FMonkey

    Bod43 Guest

    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.
     
    Bod43, Jan 6, 2007
    #11
  12. 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.

    --
    David J Dachtera
    dba DJE Systems
    http://www.djesys.com/

    Unofficial OpenVMS Marketing Home Page
    http://www.djesys.com/vms/market/

    Unofficial Affordable OpenVMS Home Page:
    http://www.djesys.com/vms/soho/

    Unofficial OpenVMS-IA32 Home Page:
    http://www.djesys.com/vms/ia32/

    Unofficial OpenVMS Hobbyist Support Page:
    http://www.djesys.com/vms/support/
     
    David J Dachtera, Jan 6, 2007
    #12
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.