On 7 Jun 2012, at 07:39, Dave McGuire wrote:
It's a good idea, but I'm not sure it can be done. We need to change
the MAC address on the interface...can that be done outside the kernel?
SimH does it by building a virtual interface attached to the real ethernet device with it's own MAC address. While it can't communicate with TCP/IP on the same machine it works just fine for DECnet.
Would it work if you created a Sandbox with a virtual DEC network interface and modified MAC address then worked out from there?
SIMH uses libpcap and implements networking for emulated machines by
kicking the interface into promiscuous mode. That's a bit dangerous
from a traffic perspective; I'm not certain that'd be a good idea for
anything other than the most casual use on a quiet network.
I think Johnny's bridge uses PCAP in promiscuous mode too and most of us use that and/or SimH.
Like I said it's not optimal, probably isn't secure and won't be that fast, but as a compromise it's worth thinking about, because the kernel based solution is not optimal either anymore, especially if like me you run up-to-date Linux machines.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 06/07/2012 02:26 AM, Mark Benson wrote:
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...
It's a good idea, but I'm not sure it can be done. We need to change
the MAC address on the interface...can that be done outside the kernel?
SIMH uses libpcap and implements networking for emulated machines by
kicking the interface into promiscuous mode. That's a bit dangerous
from a traffic perspective; I'm not certain that'd be a good idea for
anything other than the most casual use on a quiet network.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Hi Johnny. New bridge.c compiled. Seems fine in GCC, MIPSpro is still
too strict. Build output and config are as follows:
jazz:~/src/HECnet[97]%cc -O2 -o bridge bridge.c -I/opt/skunkware/include
-L/opt/skunkware/lib -lpcap
cc-1515 cc: ERROR File = bridge.c, Line = 229
A value of type "int" cannot be assigned to an entity of type "char
*".
p = index(dst,':');
^
cc-1185 cc: WARNING File = bridge.c, Line = 578
An enumerated type is mixed with another type.
d->type = classify_packet(d);
^
cc-1171 cc: WARNING File = bridge.c, Line = 684
The indicated expression has no effect.
if (port == 0) port == DPORT;
^
1 error detected in the compilation of "bridge.c".
gmake: *** [bridge] Error 2
jazz:~/src/HECnet[98]%gcc -O2 -o bridge bridge.c
-I/opt/skunkware/include -L/opt/skunkware/lib -lpcap
bridge.c: In function 'add_bridge':
bridge.c:218: warning: incompatible implicit declaration of built-in
function 'bzero'
bridge.c:229: warning: incompatible implicit declaration of built-in
function 'index'
jazz:~/src/HECnet[99]%file bridge;ls -l bridge
bridge: ELF N32 MSB mips-4 dynamic executable MIPS - version 1
-rwxr-xr-x 1 uridium clowns 302060 Jun 7 16:25 bridge
jazz:~/src/HECnet[100]%cat bridge.conf
[bridge]
local ec0
update tempo.update.uu.se:4711
[decnet]
local
update
[lat]
local
update
####
Looks like some casting might be in order. I think I'm ready to go with
the port forwarding and bridge setup on this end. Spotted a nice guide a
while ago as to how to configure the decnet side of things. I'll follow
that guide once the bridge is up. :)
Al.
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...
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
Hi Johnny,
Great! Shall do this weekend. Will get the new bridge.c compiled first.
Also it'll be good to see if it builds under MIPSPro on IRIX now instead
of gcc.
Al.
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Thursday, 7 June 2012 3:46 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Size of HECnet
I don't know of any .au on HECnet, so that would be cool... Let me
know
when you want to work on this, and I'll try to help from my end.
Johnny
On 2012-06-07 03:53, Boyanich, Alastair wrote:
Johnny,
Sounds fun. Do you have any other systems down here in .au ? If not
and
you have some spare time this weekend, I'd love a bit of a hand
getting
initially one of my systems online. We have a 3 day weekend/long
weekend
so I'll have more time. I'll try building the newer version of the
bridge.c on the SGI, but the old one appears to function. Ports are
all
still setup as per instructions.
Al.
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On
Behalf Of Johnny Billquist
Sent: Thursday, 7 June 2012 9:01 AM
To: hecnet at Update.UU.SE
Subject: [HECnet] Size of HECnet
Just some fun details...
As of today, there are 321 nodes in the nodename database.
They are spread out over 16 areas.
We have machines located on (at least) three continents, if I
remember
right.
While not online all the time, I think we currently have atleast
the
following OSes represented:
RSX
RSTS/E
VMS
Ultrix
Linux
OSF/1
TOPS-10
Tops-20
Windows XP
IOS
If you know of any errors in this information, more fun facts, or
anything else you'd like to share, feel free to do so.
Johnny
Hi list. I'll introduce myself later when I get a proper keyboard to type (right now I'm typing on an iPhone while riding a bus to my workplace...). I' the proud manager for the new HECnet area 7.
El 07/06/2012, a les 3:02, Dave McGuire <mcguire at neurotica.com> va escriure:
On 06/06/2012 08:59 PM, Johnny Billquist wrote:
On 2012-06-07 02:10, Dave McGuire wrote:
On 06/06/2012 06:11 PM, Johnny Billquist wrote:
By the way, as a warning...
I seem to remember that DECnet support now have been dropped from Linux.
So it might not be in there anymore, if you look at recent versions.
It's still there, at least in the new Ubuntu version (12.04). The routing support is not compiled in (it's marked as experimental) so you need to build the kernel if you want to try to use it as a router. I'm pretty sure it's a way to compile just de decnet modules instead of rebuilding all the kernel, but I don't know how to do it (I tried the obvious way and failed).
I planned to use Linux as my area route. It does not work. If you configure it as a level 2 router it generates corrupted packets (they have 4 additional bytes at the header, it looks like it gets wrong some offset so it should be potentially easy to fix). It SEEMS to work as level 1 router and I was using it to link together multiple tap virtual devices... until I discovered the VDE support in the 3.9 version of SIMH and started using it to have all my emulated toys in the same Ethernet segment as all the real iron (VDE is cool, I recommend you to try it :)).
Well, we'll either have to talk her into re-owning it (Hi Chrissie!
8-)) or someone else will have to take up its maintenance. At least
eventually, when someone breaks the kernel networking APIs again.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
BITXOV::JGUILLAUMES
On 06/07/2012 02:14 AM, Peter Lothberg wrote:
Can you talk to sol::
I can't seem to get to it from my Linux desktop machine, no, but I can
SET HOST to it from my Alpha running VMS. (which I'm reaching from the
aforementioned Linux machine!)
It seems that off-net DECnet routing isn't happening from the Linux
machine..? What's up with this, does anyone know?
(and...an SC-40, VERY VERY nice!!)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
I don't know of any .au on HECnet, so that would be cool... Let me know when you want to work on this, and I'll try to help from my end.
Johnny
On 2012-06-07 03:53, Boyanich, Alastair wrote:
Johnny,
Sounds fun. Do you have any other systems down here in .au ? If not and
you have some spare time this weekend, I'd love a bit of a hand getting
initially one of my systems online. We have a 3 day weekend/long weekend
so I'll have more time. I'll try building the newer version of the
bridge.c on the SGI, but the old one appears to function. Ports are all
still setup as per instructions.
Al.
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Thursday, 7 June 2012 9:01 AM
To: hecnet at Update.UU.SE
Subject: [HECnet] Size of HECnet
Just some fun details...
As of today, there are 321 nodes in the nodename database.
They are spread out over 16 areas.
We have machines located on (at least) three continents, if I remember
right.
While not online all the time, I think we currently have atleast the
following OSes represented:
RSX
RSTS/E
VMS
Ultrix
Linux
OSF/1
TOPS-10
Tops-20
Windows XP
IOS
If you know of any errors in this information, more fun facts, or
anything else you'd like to share, feel free to do so.
Johnny
On 06/06/2012 08:51 PM, Paul_Koning at Dell.com wrote:
By the way, as a warning... I seem to remember that DECnet support
now have been dropped from Linux. So it might not be in there
anymore, if you look at recent versions.
I've also had less than stellar results from trying to talk from
Linux to RSX. So it might not work absolutely right under all
conditions. Developers mostly (it not only) had VMS machines to
test against...
It's been some years ago, but I did a bunch of work to make it talk
well with RSTS/E. And I thought others had done the RSX work.
What work was this? Right now file transfers are mostly
non-functional with RSTS/E...transfers complete successfully, but line
terminators are completely hosed, and no combination of command line
switches will make them work properly.
Incidentally, I can use Linux DECnet support to get files over to a
VMS system, then copy them from THAT to RSTS/E via DECnet, and things
seem ok. (at least I think that worked, the last time I tried it)
I remember the rumor that it was dropped. Too bad. But there's no
reason the older version couldn't be used, unless your chosen
platform requires a later one.
Having to keep another instance of Linux around just to "hop through"
is certainly doable, but kind of a pain. :-(
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
I'll look into it more tomorrow but I think it's similar to doing L3 on the 3560 or 4500/6500. Its L3 is limited to IP and it can't do tunnels, etc.
I'll verify and report back.
-brian
On Jun 6, 2012, at 22:31, Dave McGuire <mcguire at neurotica.com> wrote:
On 06/06/2012 10:11 PM, Joe Ferraro wrote:
This isn't the thread for it, I realize.... the product slick states
that the switch does BGP, HSRP, OSPF, VRRP, etc.. again, not my area of
expertise... is this still considered a switch?
Hmm, it may actually be ok then. I've not worked with any of the 49xx
series. Supporting those dynamic routing protocols certainly suggests
that it knows how to route! ;)
Hey Brian, have you ever worked with those hybrid router/switch boxen?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA