17 May
2024
17 May
'24
5:19 p.m.
On May 17, 2024, at 3:48 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2024-05-17 02:50, Paul Koning wrote:
...
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?)
The DEUNA was designed before the address-per-protocol feature was added to the DEC LAN
datalink spec. QNA can do it because it has an address filter table, which lists 14 (?)
addresses to accept; it doesn't care at all whether those are unicast or multicast.
DEC Ethernet chips, such as Tulip and TGEC (I'm not sure about SGEC), all support
multiple unicast addresses in their address filter. So do DEC FDDI adapters.
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. ...
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.