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. Otherwise, if you have three separate klh10's, they will insist on having their own separate MAC address. I wasn't sure how you could do that except maybe with virtual machines and some kind of hypervisor. ------------------------------------------------------------------------ On 5/16/24 4:17 PM, Johnny Billquist wrote: _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

As far as I am aware, the NI will not handle having multiple simultaneous MAC addresses.  I don't recall there being any production code to put the transceiver into promiscuous mode, sniffing packets and changing the MAC address on a transmit.  In theory, it would appear to be possible in that the NI would do this.

If you are not running DECnet, you can change the MAC address to whatever you want while the machine is up and you just have to wait for ARP caches to catch up.  There is some support for multi-homing, but I had thought that this required separate hardware interfaces, such as an IMP interface or CI, in addition to an NI. If you do have DECnet, and you change the MAC address after SETSPD has set the machine's DECnet address, DECnet won't work. Changing the DECnet address to correspond to the new MAC address won't work; you have to reboot.  I don't really quite remember, but I had thought that youcan't change your CI's hardware address at all as this is based on where you plug into the STAR connector.

I run a separate, dedicated Ethernet interface on a per-KLH10 instance. I did have both the host and the 20 sharing the same interface and this will work as long as you use the MAC address that the 20 wants you to. I ran into trouble with that (I don't remember what, this was 20 years ago), so I bought an additional NIC for the 20 and never looked back.

I don't know enough about tap interfaces to have an informed opinion.

On 5/16/24 4:47 PM, Johnny Billquist 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. > > 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. 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. >> >> Otherwise, if you have three separate klh10's, they will insist on >> having their own separate MAC address. >> >> I wasn't sure how you could do that except maybe with virtual >> machines and some kind of hypervisor. >> >> ------------------------------------------------------------------------ >> >> >> On 5/16/24 4:17 PM, Johnny Billquist wrote: >>> Oh. One more thing - tap2 and tap3 are for KLH, right? Is there some >>> trickery you need to do in order to get the DECnet correct MAC >>> address on things here? Also applies for the PyDECnet instance >>> perhaps... >>> >>>   Johnny >>> >>> On 2024-05-16 20:30, Anders Andersson wrote: >>>> Thank you foryourfeedback Yes,the KLH10istancesall run on thsame >>>> Linux Mint >>>> host that runs the apydecanet router calledKSKAL,and I haveno >>>> additioal >>>> hardware on that internal segment which lookslike this now: >>>> >>>> oot@kaskal:/home/andersa# brctl show >>>> bridge name    bridge id       STP enabled    interfaces >>>> bridge0        8000.26d039e4c0f4    no        tap1 >>>>                              tap2 >>>>                              tap3 >>>> >>>> If that doesn't indicate that thethreetap interfaceshavbeen addedto >>>> the bridge,I don't know what does. Are there any other diagnostics you >>>> want me to check? I dont know whether the following add anything >>>> relevant: >>>> >>>> root@kaskal:/home/andersa# ifconfig bridge0 >>>> bridge0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >>>>          inet 192.168.9.78  netmask 255.255.255.0  broadcast >>>> 192.168.9.255 >>>>          inet6 fe80::4cf6:1fff:fe01:f257  prefixlen 64 scopeid >>>> 0x20<link> >>>>          ether 26:d0:39:e4:c0:f4 txqueuelen 1000  (Ethernet) >>>>          RX packets 557072  bytes 143985475 (143.9 MB) >>>>          RX errors 0  dropped 450854  overruns 0  frame 0 >>>>          TX packets 106193  bytes 4586565 (4.5 MB) >>>>          TX errors 0  dropped 0overruns 0  carrier 0 collisions 0 >>>> >>>> root@kaskal:/home/andersa# ifconfig tap1 >>>> tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500 >>>>          inet6 fe80::6032:eff:fedb:7b94  prefixlen 64 scopeid >>>> 0x20<link> >>>>          ether 62:32:0e:db:7b:94 txqueuelen 1000  (Ethernet) >>>>          RX packets 176227  bytes 46414104 (46.4 MB) >>>>          RX errors 0  dropped 0  overruns 0  frame 0 >>>>          TX packets 318825  bytes 90356527 (90.3 MB) >>>>          TX errors 0  dropped 0overruns 0  carrier 0 collisions 0 >>>> >>>> root@kaskal:/home/andersa# ip tuntap show >>>> tap0: tap persist >>>> tap1: tap >>>> tap2: tap >>>> tap3: tap >>>> >>>> The threeTOPS-20 hosts arealso awareof and can communicate with each >>>> other. When I run tcpdump -i bridge0 I do see DECnet, DEC LAT and >>>> TCP/IP >>>> ARP traffic to or from the three TOPS-20 hosts pass by,according to >>>> the >>>> ethertype code as well as decoding done by tcpdump. >>>> >>>> The KLH10 instances obtain their tap interfaces as part of their >>>> startup configuration, so I have to restart them whenever I have reset >>>> the bridge which I haven't done in a few days now. This is a sample >>>> net >>>> device onfiguration line from one host: >>>> >>>> devdef ni0  564   ni20 dedic=true ifc=tap2 ifmeth=tap+bridge >>>> ipaddr=192.168.9.72 >>>>   dpdelay=3 >>>> >>>> >>>> The number of the interface specified with ifc= doesn't seem to >>>> matter the machine >>>> still gets assigned the next unassiged tap interface in order.And >>>> it did work previously. >>>> >>>> Eventually I hope to put all the bridge and pydecnet configuration >>>> intoa >>>> hecnet.service file andstart it from systemd. >>>> >>>> Now I plan to restartpydecnet while logging bridg0 traffic using >>>> tcpdmpto see >>>> what comes up. >>>> >>>>   /AndersAndersson >>>> >>>> >>>> _______________________________________________ >>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se >>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se >>> >> >> _______________________________________________ >> HECnet mailing list -- hecnet(a)lists.dfupdate.se >> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se >

As I recall, our ultimate configuration at Columbia was one machine (CU20B) with a CI and NI, three machines with just a CI (CU20A, CU20C and CU20D).  CU20B routed IP and DECnet to the other three nodes. However, this was about 1985, so I could be completely, totally, thoroughly, and utterly wrong.

That being said, it appears that the monitor will definitely do DECnet over the CI.  CIDLL (CI Data Link Layer) is the module which implements this.  I had thought that the only way to change your CI hardware address is to plug into a different slot in the STAR connector, but I wouldn't swear to it at this point.

I would really love to get my hands on a CI implementation for klh10. There is a lot of cool code that does stuff with the CI.

On 5/16/24 6:13 PM, Johnny Billquist wrote: > Hi. > > On 2024-05-16 23:56, Thomas DeBellis wrote: >> As far as I am aware, the NI will not handle having multiple >> simultaneous MAC addresses.  I don't recall there being any >> production code to put the transceiver into promiscuous mode, >> sniffing packets and changing the MAC address on a transmit.  In >> theory, it would appear to be possible in that the NI would do this. > > That is not what I said. The NI (any of the DEC ones) will not > allow/handle having multiple MAC addresses simultaneously. But every > NI have a MAC address from manufacture. DECnet have a fixed MAC > addresses expected for any DECnet node. So a machine running DECnet > have to change the MAC address. So in fact, the MAC address the NI > uses is not the one programmed at manufacture, but one that is set by > the software on the NI. > > As for promiscuous mode, and so on. That's a question for each OS if > possible, and how you would do it and so on. All controllers I've ever > seen have the capability of doing that in the hardware. > >> If you are not running DECnet, you can change the MAC address to >> whatever you want while the machine is up and you just have to wait >> for ARP caches to catch up.  There is some support for multi-homing, >> but I had thought that this required separate hardware interfaces, >> such as an IMP interface or CI, in addition to an NI. >> >> If you do have DECnet, and you change the MAC address after SETSPD >> has set the machine's DECnet address, DECnet won't work. Changing the >> DECnet address to correspond to the new MAC address won't work; you >> have to reboot.  I don't really quite remember, but I had thought >> that youcan't change your CI's hardware address at all as this is >> based on where you plug into the STAR connector. > > I don't remember how CI works. Not even sure if you can run DECnet > over CI, but it seems likely it would be possible. But usually, as a > part of the whole starting of DECnet on a node, the MAC address of the > NI is changed at that point, since only then and there will you be > able to know what the MAC address should be. > >> I run a separate, dedicated Ethernet interface on a per-KLH10 >> instance. I did have both the host and the 20 sharing the same >> interface and this will work as long as you use the MAC address that >> the 20 wants you to. I ran into trouble with that (I don't remember >> what, this was 20 years ago), so I bought an additional NIC for the >> 20 and never looked back. > > I've not used KLH, so I can't really comment on that one. > But with E11, as well as simh, you can run both the host machine, and > the emulator on the same NI, usually (it do depend on the ethernet > controller being a bit flexible). And that without changing the host > NI MAC address at all. If I talk this through in a simh context, what > it does is that it places the interface in promiscuous mode. Ethernet > traffic to either the host or the simulator both comes in on the NI, > and if not meant for either machine, the network stacks discard the > packets. Which also means that DECnet will work, since simh will use > the programmed MAC address of the guest OS, no matter what MAC address > you might have placed in the configuration for simh. Just as with real > hardware. > And outgoing packets gets set the correct source MAC address as well. > But this do require that you can send packets out where you setup the > full packet yourself, and not have the NI forcibly fill some bits in. > But that is working right on anything that I've tried in the last 20 > years. > One more thing - using a bridge might help, since there otherwise is > usually a bit of a problem that the outgoing packets from simh are not > looped back in to the host system, so you have a problem talking over > the network between the simulator and host specifically. Towards > everything else, things work fine. > >> I don't know enough about tap interfaces to have an informed opinion. > > tap is basically just a virtual ethernet interface. With those, you > can create a network bridge, where each virtual network interface has > its own MAC address, and if you also bridge this with the real > ethernet inferface, it appears as if they are all on the same ethernet > segments, but each with their own ethernet interface connected to it. > > Which is better than what I described above, which is basically just > directly connecting simh to the actual ethernet interface. But it's > also a bit more work than just connecting directly to the ethernet > interface. > >   Johnny > >> >> On 5/16/24 4:47 PM, Johnny Billquist 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. >>> >>> 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. 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 whatMAC >>>> 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. >>>> >>>> Otherwise, if you have three separate klh10's, they will insist on >>>> having their own separate MAC address. >>>> >>>> I wasn't sure how you could do that except maybe with virtual >>>> machines and some kind of hypervisor. >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> On 5/16/24 4:17 PM, Johnny Billquist wrote: >>>>> Oh. One more thing - tap2 and tap3 are for KLH, right? Is there >>>>> some trickery you need to do in order to get the DECnet correct >>>>> MAC address on things here? Also applies for the PyDECnet instance >>>>> perhaps... >>>>> >>>>>   Johnny >>>>> >>>>> On 2024-05-16 20:30, Anders Andersson wrote: >>>>>> Thank you foryourfeedback Yes,the KLH10istancesall run on thsame >>>>>> Linux Mint >>>>>> host that runs the apydecanet router calledKSKAL,and I haveno >>>>>> additioal >>>>>> hardware on that internal segment which lookslike this now: >>>>>> >>>>>> oot@kaskal:/home/andersa# brctl show >>>>>> bridge name    bridge id       STP enabled    interfaces >>>>>> bridge0        8000.26d039e4c0f4    no        tap1 >>>>>>                              tap2 >>>>>>                              tap3 >>>>>> >>>>>> If that doesn't indicate that thethreetap interfaceshavbeen addedto >>>>>> the bridge,I don't know what does. Are there any other >>>>>> diagnostics you >>>>>> want me to check? I dont know whether the following add anything >>>>>> relevant: >>>>>> >>>>>> root@kaskal:/home/andersa# ifconfig bridge0 >>>>>> bridge0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >>>>>>          inet 192.168.9.78  netmask 255.255.255.0 broadcast >>>>>> 192.168.9.255 >>>>>>          inet6 fe80::4cf6:1fff:fe01:f257  prefixlen 64 scopeid >>>>>> 0x20<link> >>>>>>          ether 26:d0:39:e4:c0:f4 txqueuelen 1000 (Ethernet) >>>>>>          RX packets 557072  bytes 143985475 (143.9 MB) >>>>>>          RX errors 0 dropped 450854  overruns 0  frame 0 >>>>>>          TX packets 106193  bytes 4586565 (4.5 MB) >>>>>>          TX errors 0 dropped 0overruns 0  carrier 0 collisions 0 >>>>>> >>>>>> root@kaskal:/home/andersa# ifconfig tap1 >>>>>> tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >>>>>>          inet6 fe80::6032:eff:fedb:7b94  prefixlen 64 scopeid >>>>>> 0x20<link> >>>>>>          ether 62:32:0e:db:7b:94 txqueuelen 1000 (Ethernet) >>>>>>          RX packets 176227  bytes 46414104 (46.4 MB) >>>>>>          RX errors 0 dropped 0  overruns 0  frame 0 >>>>>>          TX packets 318825  bytes 90356527 (90.3 MB) >>>>>>          TX errors 0 dropped 0overruns 0  carrier 0 collisions 0 >>>>>> >>>>>> root@kaskal:/home/andersa# ip tuntap show >>>>>> tap0: tap persist >>>>>> tap1: tap >>>>>> tap2: tap >>>>>> tap3: tap >>>>>> >>>>>> The threeTOPS-20 hosts arealso awareof and can communicate with each >>>>>> other. When I run tcpdump -i bridge0 I do see DECnet, DEC LAT and >>>>>> TCP/IP >>>>>> ARP traffic to or from the three TOPS-20 hosts pass by,according >>>>>> to the >>>>>> ethertype code as well as decoding done by tcpdump. >>>>>> >>>>>> The KLH10 instances obtain their tap interfaces as part of their >>>>>> startup configuration, so I have to restart them whenever I have >>>>>> reset >>>>>> the bridge which I haven't done in a few days now. This is a >>>>>> sample net >>>>>> device onfiguration line from one host: >>>>>> >>>>>> devdef ni0  564   ni20 dedic=true ifc=tap2 ifmeth=tap+bridge >>>>>> ipaddr=192.168.9.72 >>>>>>   dpdelay=3 >>>>>> >>>>>> >>>>>> The number of the interface specified with ifc= doesn't seem to >>>>>> matter the machine >>>>>> still gets assigned the next unassiged tap interface in order.And >>>>>> it did work previously. >>>>>> >>>>>> Eventually I hope to put all the bridge and pydecnet >>>>>> configuration intoa >>>>>> hecnet.service file andstart it from systemd. >>>>>> >>>>>> Now I plan to restartpydecnet while logging bridg0 traffic using >>>>>> tcpdmpto see >>>>>> what comes up. >>>>>> >>>>>>   /AndersAndersson >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se >>>>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se >>>>> >>>> >>>> _______________________________________________ >>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se >>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se >>> >

On 5/16/24 19:15, Johnny Billquist wrote:   Plug: We have a real CI cluster at LSSM. B-)

On May 16, 2024, at 4:47 PM, Johnny Billquist &lt;bqt(a)softjar.se&gt; 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.

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.

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.

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.

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.

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.

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. It seems quite reasonable except for the fact that CI has such a limited range and station count. It's just that it wasn't specified in any DNA spec. paul

------------------------------------------------------------------------ On 5/17/24 11:19 AM, Paul Koning wrote: It seems quite reasonable except for the fact that CI has such a limited range and station count. It's just that it wasn't specified in any DNA spec. paul

On May 17, 2024, at 11:47 AM, Thomas DeBellis &lt;tommytimesharing(a)gmail.com&gt; wrote: ... I wouldn't swear to it, but when we were a field test for 6.x, there was some internal documentation on DECnet over the CI. I think there is still some kind of write up on it, somewhere. > On 5/17/24 11:19 AM, Paul Koning wrote: > It seems quite reasonable except for the fact that CI has such a limited range and station count. It's just that it wasn't specified in any DNA spec.