HECnet

hecnet@lists.dfupdate.se

15586 discussions

Introducing myself... and my little network

by roll＠Stupi.SE

I've got also some emulated PDP10 which I've not networked (yet). I'm having trouble plugging into DECNET a TOPS20/Panda machine... If someone could point me to any docs I would appreciate it a lot. Does Ethernet-Multicast get set up correclty on your host? I'm trying too to DECNETize a TOPS10 running on a KLH10 simulated machine; this one kinda works... I get the adjacency up messages but I can't talk to the machine (neither FROM the machine). The only docs I've found are for the 7.03 version of the monitor, but I've got 7.04. Again, any pointers to docs will be appreciated. There is no real change to DECnet 703a/7.04, the changes are 7.01/7.02. I don't think your problems are in the PDP10 code, it's KLH/Host_Networking. Can the T10 box talk to itself? -P

13 years, 6 months

Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-07 23:12, Rob Jarratt wrote: -----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? Welcome to the world of confusion. No, you would not need an interface to a routing function. The problem is that people are not talking about a routing function. You went down the same path I was going... :-) What people are talking about now is a full blown DECnet implementation. Then you need an API for all the user land programs who might want to talk DECnet, and then you need an interface to it. Johnny

13 years, 6 months

Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-08 07:21, Peter Lothberg wrote: On 06/07/2012 02:26 AM, Mark Benson 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? This should be possible, OSI-IP requred this function to, but in addition to that you need to get the MAC-level multicast packets in both directions. Changing the MAC address outside of the kernel? Depends on the kernel. Linux have an API to do this. Some other Unixes does not. In fact, some Unixes have no capabilities for doing so even in the kernel, although if your code is in the kernel you can definitely do such a thing yourself. Problem is how to interface it to userland... (If I remember right, there is an ioctl() to do it in Linux... You do need to be root, obviously...) Johnny

13 years, 6 months

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-08 01:13, Dave McGuire wrote: On 06/07/2012 08:16 AM, Johnny Billquist wrote: Any program that needs access to raw ethernet packets needs to run as root. Promiscuous mode or not. Promiscuous mode itself has little to do with this. So if you want to run anything like a bridge or a router, you will need to run it as root. Promiscuous mode is basically just allowing you to share the same interface as the system is otherwise using, instead of having to dedicate a separate ethernet interface for this. Maybe you're just putting this another way, but promiscuous mode is correctly defined a bit differently than this. When an Ethernet controller is placed into promiscuous mode, its on-chip MAC address filters, which normally either select or ignore inbound packets based on their MAC address, are disabled. ALL packets are received by the hardware and passed to the Ethernet driver in the OS, rather than only the ones destined for that specific interface as defined by its MAC address. I'm reasonably certain that you know this but were just explaining it in a more abstract way...? Yes. Well, actually I wasn't describing it in a more abstract way, but in a way more in terms of why you need promiscuous mode instead of what it actually does on the interface. But reading it through now, I see that there was one implicit assumption in my text which I could have pointed out. If you need to share the device with the system, while using a different MAC address, you need to place the device in promiscuous mode. And such is the case if we talk DECnet, since DECnet requires that you use a specific MAC address which is not the same as the default MAC address of a device. And to make a correction to your text, when not in promiscuous mode, your ethernet controller will filter out packets that do not have your MAC address, and packets that don't have the multicast bit set (possibly you can also get it to filter more specific on multicast ethernet packets, but multicast is a separate story from unicast packets on ethernet controllers anyway). Johnny

13 years, 6 months

netowrk flapping....

by roll＠Stupi.SE

NCP> %%%%%%%%%%% OPCOM 8-JUN-2012 07:07:16.01 %%%%%%%%%%% Message from user DECNET on STUPI DECnet event 4.18, adjacency down

13 years, 6 months

Introducing myself... and my little network

by roll＠Stupi.SE

I will set it aside if I find it, and make sure to image it. Image all your TK50's with distribution stuff on drop Al K a copy. -P

13 years, 6 months

Multinet Tunnel Connections to SG1::

by roll＠Stupi.SE

On 06/07/2012 02:26 AM, Mark Benson 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? This should be possible, OSI-IP requred this function to, but in addition to that you need to get the MAC-level multicast packets in both directions. -P

13 years, 6 months

Reaching SOL::, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by roll＠Stupi.SE

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? Is it connetivity (routing), or the fact that the linux implementation only speaks VMSnet? Does the linux box talk to stupi:: -P

13 years, 6 months

lunchbox VAXen, was Re: [HECnet] Introducing myself... and my little network

by mcguire＠neurotica.com

On 06/08/2012 12:13 AM, Boyanich, Alastair wrote: @DaveMc: *Snip!* .. here we called the VS2000's "wine casks" or "goon vax" because cask wine is oft called "goon" over here. I like it! -----Original Message----- I think someone even wrote a driver for VMS to use disks on that controller. I have several of those machines; I really should look into that. Does anyone have any further information on, or actual copies of, those boot ROMs and/or the VMS device driver? Reinhard Heuberger I think? Might've been a controller out of a rainbow in an 11/23 http://www.pdp11gy.com/indexE.html No, the SCSI host adapter in question is actually integrated onto the MicroVAX-2000 and VAXstation-2000 main board. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 6 months

lunchbox VAXen, was Re: [HECnet] Introducing myself... and my little network

by Alastair.Boyanich＠au.fujitsu.com

@DaveMc: *Snip!* .. here we called the VS2000's "wine casks" or "goon vax" because cask wine is oft called "goon" over here. -----Original Message----- I think someone even wrote a driver for VMS to use disks on that controller. I have several of those machines; I really should look into that. Does anyone have any further information on, or actual copies of, those boot ROMs and/or the VMS device driver? Reinhard Heuberger I think? Might've been a controller out of a rainbow in an 11/23 http://www.pdp11gy.com/indexE.html

13 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet