So Mark (Matlock) has been after me to get my HECnet connection up and running and me, being an ace procrastinator, has always said "Real Soon Now™", Mark. I might actually have time to do it as I'm on vacation for a week and a half.  Despite the heat I could set something up.  My question is how do I set it up.  I have a Mac Mini in Las Vegas running VMWare ESXi.  I have a VM (Aniketos) running Vyos for a firewall/router, another VM with an Nginx web server (Hermes - irrelevant just mentioned for completeness) and a really small (1 vCPU) Linux VM (Knight) which I want to run Paul's PyDECnet router for the world to connect to.  From there I have an IPSec VPN to my Ubiquiti EdgeRouter 4 at home.  How can I connect DECnet through the VPN to Knight from home?  Is it even possible?  Do I need or want GRE tunnels through the VPN? Am I just making it too complicated and should I set up a PyDECnet router at home and go that way through my dynamic IP? It's possible I could set up an x86 OpenVMS machine as another VM I'm thinking I need a PyDECnet router at home to collect all the DECnet traffic and shove it through the VPN to the PyDECnet router at the remote site and from there out into the internet to it's HECnet connection points.  Does that make sense? I tried drawing an ASCII picture but apparently I suck at that. Hopefully the description makes sense. Hoping to get people's thoughts and if you're experienced in designing PyDECnet config files, any pointers are welcome.

A router at home that uses the dynamic IP address is certainly a valid option, one a bunch of us use today. I don't know that anyone has tried running a DECnet circuit through an IPSec VPN, but clearly it should work. You'd just point the DECnet circuit to the IP address of the other end of the tunnel, with the local address of the circuit set to the local endpoint of the tunnel. Then you can use any IP based communication method that is enabled by the filter rules of the VPN. For example, if the VPN allows any IP traffic, you could use anything IP based, from GRE to Multinet to DDCMP. If you want to be more restrictive, you could enable just the one protocol and port you want. For example, that could be TCP on which you run Multinet, or TCP or UPD carrying DDCMP. If you do go this VPN route it would be interesting to hear how it works for you, especially if you run into problems. paul _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

On 8/17/2023 8:02 AM, Paul Koning wrote: Thanks Johnny and Paul! I do at least want to try the connection through the VPN. I'm curious if it works as well.  The VPN connection has been very reliable for TCP traffic but it's not heavily loaded.  I keep a "top" session running on each system there just to see if/when it breaks.  It has typicallygone months without a problem other than when we have had extended power outages or my local internet has gone down. I don't have Multinet anywhere (yet) so I will try the DDCMP via TCP. That seems the most reasonable place to start. John H. Reinhardt _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

On Aug 17, 2023, at 12:40 PM, Johnny Billquist <bqt(a)softjar.se> wrote: On 2023-08-17 18:36, Paul Koning wrote: Say what? Did you think something in reverse here, Paul? I thought we had agreed that DDCMP over UDP is the worst idea. TCP makes total sense, but UDP means you can get reordering, duplication and lost packets galore. Or are you thinking of using something that addds the whole DDCMP protocol on top of UDP? Doable. Maybe something in PyDECnet I have forgotten?

DDCMP in SIMH and in PyDECnet is the whole DDCMP data link protocol. It handles all those things you mentioned, though just like any ARQ protocol the performance will drop a lot if those problems occur at significant rates. BTW, UDP (or more precisely, IP) should not normally duplicate packets, and reordering may be rare for many topologies.

Maybe you're thinking about an early "DDCMP data service" that was in SIMH, and existed for a while in PyDECnet. That only works over TCP since it carries the payload, not the DDCMP protocol messages (DLSDU rather than DLPDU, in "Internationalbureaucratspeak" as Andrew Tanenbaum phrased it). The "known very bad" choice is Multinet over UDP. And even Multinet over TCP is iffy, though I admit that part of the reason I avoid it is on architectural purity principles -- the people who designed Multinet clearly demonstrated their lack of interest, or lack of ability, to understand the DECnet protocol specifications. So while, with some care and feeding, it can be made to operate, it just is not and never can be "correct".

On Aug 17, 2023, at 1:25 PM, Brian Angus <brian.angus(a)gmail.com> wrote: I'm curious if I understand the suggestions correctly? If I was to have connections from several DECnet capable machines on my home network connecting to a PyDECnet/HECnet router hosted elsewhere with each one configured to use DDCMP over the slower WAN/VPN link, then any local machine to machine traffic would end up traversing the WAN link twice - that is unless the home systems are configured with multiple circuits? While I'm sure this is quite possible, I suspect it would be a more complex configuration. Having a PyDECnet router on the home LAN and just using standard ethernet circuits for DECnet would simplify the configuration for all the local nodes. You could still have the choice of whether the HECnet destined traffic is routed directly out over the dynamic IP of the home circuit, or the fixed IP of the business circuit (via the VPN)? Just some thoughts... :)

I'm curious if I understand the suggestions correctly?  If I was to have connections from several DECnet capable machines on my home network connecting to a PyDECnet/HECnet router hosted elsewhere with each one configured to use DDCMP over the slower WAN/VPN link, then any local machine to machine traffic would end up traversing the WAN link twice - that is unless the home systems are configured with multiple circuits? While I'm sure this is quite possible, I suspect it would be a more complex configuration.  Having a PyDECnet router on the home LAN and just using standard ethernet circuits for DECnet would simplify the configuration for all the local nodes.  You could still have the choice of whether the HECnet destined traffic is routed directly out over the dynamic IP of the home circuit, or the fixed IP of the business circuit (via the VPN)?  Just some thoughts...  :) Cheers - Brian On Thu, Aug 17, 2023 at 1:03 PM Johnny Billquist &lt;bqt(a)softjar.se <mailto:bqt@softjar.se>> wrote: On 2023-08-17 18:55, Paul Koning wrote: <mailto:bqt@softjar.se>> wrote: &lt;johnhreinhardt(a)thereinhardts.org <mailto:johnhreinhardt@thereinhardts.org>> wrote: via TCP. That seems the most reasonable place to start. default choice. TCP makes total sense, but UDP means you can get reordering, duplication and lost packets galore. DDCMP protocol on top of UDP? Doable. Maybe something in PyDECnet I have forgotten? protocol.  It handles all those things you mentioned, though just like any ARQ protocol the performance will drop a  lot if those problems occur at significant rates.  BTW, UDP (or more precisely, IP) should not normally duplicate packets, and reordering may be rare for many topologies. Ah. You were thinking of the full DDCMP over the link. Ok. But yes, both lost, reordered and duplicated packets in IP are unusual, but it can happen, for various reasons. was in SIMH, and existed for a while in PyDECnet.  That only works over TCP since it carries the payload, not the DDCMP protocol messages (DLSDU rather than DLPDU, in "Internationalbureaucratspeak" as Andrew Tanenbaum phrased it). Multinet over TCP is iffy, though I admit that part of the reason I avoid it is on architectural purity principles -- the people who designed Multinet clearly demonstrated their lack of interest, or lack of ability, to understand the DECnet protocol specifications. So while, with some care and feeding, it can be made to operate, it just is not and never can be "correct". I was more thinking of the latter. But it was probably a bit of mixum from my side. Multinet pretends to be DDCMP, but don't actually do DDCMP. Which is where things go bad.    Johnny -- Johnny Billquist                  || "I'm on a bus                                    ||  on a psychedelic trip email: bqt(a)softjar.se <mailto:bqt@softjar.se>             || Reading murder books pdp is alive!                    ||  tryin' to stay hip" - B. Idol _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se <mailto:hecnet@lists.dfupdate.se> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se <mailto:hecnet-leave@lists.dfupdate.se> _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

On Aug 17, 2023, at 2:10 PM, Brian Angus &lt;brian.angus(a)gmail.com&gt; wrote: F.Y.I: I've been running PyDECnet on a Raspberry Pi 3B+ for a couple of years with no issues (about $35.00). I suspect it would work fairly well on even older and slower model Pi's, but then again, I'm not stressing anything with my usage levels. Another quick point in favour of configuring one's DECnet nodes to use simple Ethernet circuits and having a local router is that the local network (both DECNET and IP) will be up and moderately happy even when the WAN links and/or VPN server have other unfortunate challenges. And yes, everyone here should have several DECnet nodes up and running...