17 May
2024
17 May
'24
9:48 a.m.
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
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.