[HECnet] Multinet Tunnel Connections to SG1::

[Rob Jarratt]

-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Mark Benson
Sent: 07 June 2012 07:27
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Connections to SG1::

Now, you have due permission to beat me with a dried haddock if I'm being
naive (I'm not a programmer, just a user observing a conversation that's
50%
over my head) but...

Wouldn't a kernel-agnostic DECnet implementation be a better shot? I mean
if you can skim DECnet packets using libpcap (which is kernel agnostic as
far
as I can tell, hell it even works on Windows :)) and use that to handle
DECnet
for the bridge or SimH what's stopping it being used for a full DECnet
comms
package? It might not be very *fast* and it's sure as hell not secure but
it'd
work, right?

With the fast pace of kernel change and the dropping of kernel support
(and
OSs like Ubuntu update the kernel regularly which will break things) for
DECnet in the 3.x kernel it may be that kernel-based support is no longer
practicable on modern Linux.

Just a thought...



This is such a big thread that it breached my attention span limit, so
apologies if I miss something.

This was exactly my plan, and I intend to give it a go, but no promises on
when I will have something.

I think it would be running a user-mode program running as root, use
promiscuous mode, and on linux/unix run as a daemon, while on Windows it
would run as a service. Being user mode it would be possible to run it on
multiple platforms with ease.

I am no DECnet expert, so I don't fully understand why I would need some
kind of other interface to the routing function, I got a bit lost when
people started talking about needing sockets to talk to the daemon. I think
I would probably just use a config file to drive it, rather than provide
some kind of command interface. Not sure if this would break something?

Regards

Rob