14 Dec
2023
14 Dec
'23
4:01 p.m.
Short suggestion: try tossing the dedic=true and ifmeth=tap+bridge from
that configuration line.
Background: I did the something similar maybe 5 or six years ago.
Perhaps this will be useful for you:
I was getting deep into the guts of some things in Tops-20 that was
going to require me to have 'the system' (I.E., TOMMYT:: on HECnet)
standalone while I debugged. But that caused some outages that I didn't
want, so I got another system and rebuilt KLH10 for 64 bit. That HECnet
system is VENTI2::.
For 64 bit execution on Ubuntu, I had to fix the memory locking code
which had gotten broken somehow. I only use separate dedicated NIC's,
and had to write some code to put the adapter into AllMulti mode as
DECnet will not work without this. I may have done something else, I
forget.
I never got into tap devices as that would have involved spending too
much time learning and doing Unix work, which wasn't what I was
interested in at the time. If you use a separate NIC, then it is
conceptually simpler to restrict the area of trouble-shooting to Tops-20.
Recall from dpni20.c that the network interface can only be in one of
two modes, shared or dedicated and certain parameters are applicable,
depending on the mode. Regarding your line, dedic=true means that the
20 has _complete_ control of what is specified by ifc. In this mode,
ipaddr and enaddr will get ignored. I don't have ifmeth in my sources
(which are probably old klh20 2.0h). Here is what I have:
devdef ni0 564 ni20 DEDIC=TRUE IFC=enx8cae4ce9446b
Simple, eh? You also have to do some stuff to tell Ubuntu to not run
anything on that interface. For example,
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
Ditto for ip4.
------------------------------------------------------------------------
On 12/13/23 11:04 AM, Keith Halewood wrote:
Hi,
I’ve been running the Panda distribution of TOPS-20 on the KLH10
simulator on a Raspberry Pi 4 for some years now. It’s WALACH on
HECnet. The version of the Pi’s OS had been the 32 bit implementation
but as some of these were being replaced by 8Gb versions, I recently
took the plunge and updated (by re-imaging) everything to the current
64 bit Raspberry Pi OS.
In rebuilding SIMH and KLH10, I sync’d with the latest sources. With
SIMH, there were no issues but the KLH10 updates, seemingly post ~2021
have broken networking. The line in my klt20.ini file is:
devdef ni0 564 ni20 dedic=true ifc=tapX ifmeth=tap+bridge
ipaddr=192.168.2.46 enaddr=aa:00:04:00:6c:74
With the dpni20 executable running as root, the ‘old’ behaviour causes
it to use the default bridge name ‘bridge0’ and create a tap device
‘tap0’ (it disregards the ifc=tapX part of the line).
The new behaviour results in a whole load of IOCTL errors while
attempting to create the tap device.
I avoided the problem by restoring the original version of the KLH10
simulator sources and compiling.
The whole thing has reminded me that I wanted to fix the code a while
back so that it would make use of an existing tap device, created via
/etc/network/interfaces, with full control granted to the
non-privileged user the rest of KLH10 runs under, then dpni20 would
not need to be privileged. Once I’ve finished with the upgrades I
might have a go…. along with all of the other half-done/half-forgotten
projects in this area.
Keith
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se