16 May
2024
16 May
'24
11:56 p.m.
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 you can'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:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se 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