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 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
>
--
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