17 May
2024
17 May
'24
11:25 a.m.
Regarding KLH10 running Panda TOPS-20, I have the following line in the ini file:
devdef ni0 564 ni20 dedic=true ifmeth=tap+bridge
This will attempt to create a tap device on the default bridge 'bridge0' - you
need a env variable set if you want to change the name of the bridge used. So far,
I've not found that the ifc=tapx overrides the choice of tap device name.
The executable dpni20, I set uid to root so that it runs as root - required as it sets the
base priority of its process high, though this may be an old requirement now - systems are
so much faster.
My networking arrangement is as follows:
auto lo tap1 tap2 tap3 tap4 tap5 eth0 bridge0
iface tap1 inet manual
pre-up ip tuntap add tap1 mode tap user simh
{etc for tap2-5}
iface bridge0 inet static
bridge_ports eth0 tap1 tap2 tap3 tap4 tap5
bridge_fd 0
address 192.168.x.y
netmask 255.255.255.0
gateway 192.168.x.1
When dpni20 runs, it'll create tap0 and add it to bridge0 and I've had no issues
with DECnet or TCP/IP since to/from the KLH10 instance, other than a log file which grows
and grows due to an unrecognised packet, I think.
Keith
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 17 May 2024 08:49
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: pydecnet on LinuxMint
On 2024-05-17 02:50, Paul Koning wrote:
A bit surprised a VP was making such decisions. But I guess someone had to. But yeah,
it's a bit of an annoying "feature".
Uh? I was surprised by that claim. I know for sure the DEUNA/DELUA do not allow that, and
reading through the DEQNA manual now, it seems it also would not allow this. Although you
could do it by using promiscuous mode I think. But that would be a bit costly.
(The QNA allows you to set anything in the source MAC field of outgoing packets, the
UNA/LUA force the own address in there. But the filter list according to the QNA manual
states it should only contain multicast addresses - Hmm, I wonder if it actually would
work putting other unicast addresses in there maybe?)
I was trying to remember if I've seen DECnet over CI or not. And I can't remember
for sure, but at the same time, it seems weird if DEC did not do it when you have a
cluster with this high speed link between the nodes. They definitely run some other
protocols for the cluster operation over CI, but I was basically thinking that I would
expect DECnet also to be done.
I know for sure that Ultrix can talk IP over CI at least.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
On May 16, 2024, at 4:47 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
DECnet addresses are AA-00-04-00-xx-yy, which I'm sure most people are aware of. As
such, as long as each machine has it's own DECnet address, they will also have their
own MAC address. The question is, though, if KLH handles this completely transparent to
you, or if you need to do some things yourself here. For other simulators, it sortof
depends on the host system and your setup, and so on, since there is no standardized API
under Unix (or Windows, I believe) to set the MAC address on an interface. But there
sometimes do exist an API for it.
FYA, internally that scheme was sometimes referred to as "Bernie LaCroute's
hack" after the VP who insisted that using real 48 bit addresses was too hard.
For real
hardware, the network interfaces do have a MAC from the factory, but it's also stated
in the standards that ethernet interfaces should support software changing the MAC address
of the interface. And that is what DECnet normally does, and all DEC ethernet interfaces
certainly allows this to be changed.
Not only that, most DEC LAN NICs supported multiple individual addresses per NIC, so you
could start up the system with LAT or IP enabled (bound to the default MAC address) and
then afterwards start DECnet Phase IV and have it use the Bernie address only for its use,
i.e., for traffic on protocol type 60-03. I'm not sure all OS supported this, and
early hardware didn't, but the QNA could and all DEC internally designed silicon could
as well. And that means
any emulator/simulator also gets informed about the MAC address change, since the OS
running on the emulator will poke at the controller for it to change the MAC address to
whatever DECnet needs it to be.
The question is then, what does the emulator/simulator do when this happens?
Johnny
On 2024-05-16 22:41, Thomas DeBellis wrote:
> On a KL emulation running Tops-20, if you want to run Phase IV, you have a choice of
the CI or NI. In order to not implement ARP for DECnet, they came up with the idea of a
certain range of 48 bit MAC address having a direct mapping.
> For the CI, this is built off of the CI interface number and there is no getting
around that, as I recall. For the NI, it wants to pick the MAC address. You can get
around this by knowing what MAC address it will pick and configuring that. It's
sometimes easier to just spend the $15 and get another USB interface and dedicate it to
the engine.
Interesting. I never heard of any spec for DECnet over CI. DECnet supported any number
of quite obscure devices, from PCL-11 to 802.5 token ring (sort of), but not CI in any
document I have ever seen.