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. Advertising

  2. FMonkey

    JF Mezei Guest

    FMonkey wrote:
    > 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.


    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. Advertising

  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. 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 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

    Guest

    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.
     
    , 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. FMonkey

    Guest

    FMonkey wrote:
    > 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.


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

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

    Guest

    Aaron Leonard wrote:
    > [ adding comp.os.vms, my old stomping grounds ]
    >
    > On 4 Jan 2007 15:23:16 -0600, 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.


    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.
     
    , Jan 6, 2007
    #9
  10. wrote:
    > [snip]
    > 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)


    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.

    > and a DECnet terminal
    > server (which I presume exists or existed)


    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.

    > to provide the required
    > translation?
    >
    > [ PC ]
    > [ app ] [mystery device ]
    > [ shim] [term serv]__Serial__[term serv] [ app ]
    > [ IP ] [ IP ] [ DECnet ] [ DECnet ]
    > |____IP____ | |____DECnet_____|
    >


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

    > 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.


    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

    Guest

    David J Dachtera wrote:
    > wrote:
    > > [snip]
    > > 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)

    >
    > 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.
    >
    > > and a DECnet terminal
    > > server (which I presume exists or existed)

    >
    > 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.
    >
    > > to provide the required
    > > translation?
    > >
    > > [ PC ]
    > > [ app ] [mystery device ]
    > > [ shim] [term serv]__Serial__[term serv] [ app ]
    > > [ IP ] [ IP ] [ DECnet ] [ DECnet ]
    > > |____IP____ | |____DECnet_____|
    > >

    >
    > Where you show "DECnet" here substitute either "LAT" or "TELNET".
    >
    > > 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.

    >
    > 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.
     
    , Jan 6, 2007
    #11
  12. wrote:
    >
    > I just assumed that there would be DECnet terminal servers.
    >
    > If there are not then no use.


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

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


    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. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. William J King

    how to halt DECNET processes

    William J King, Dec 23, 2003, in forum: Cisco
    Replies:
    1
    Views:
    485
    News Account
    Dec 24, 2003
  2. Ivan Ostreš

    How to test DECnet?

    Ivan Ostreš, Feb 21, 2005, in forum: Cisco
    Replies:
    8
    Views:
    644
    Ivan Ostreš
    Mar 2, 2005
  3. Replies:
    1
    Views:
    853
    Steve
    Oct 6, 2005
  4. sali
    Replies:
    6
    Views:
    849
  5. Theo Markettos

    VOIP over VPN over TCP over WAP over 3G

    Theo Markettos, Feb 3, 2008, in forum: UK VOIP
    Replies:
    2
    Views:
    978
    Theo Markettos
    Feb 14, 2008
Loading...

Share This Page