13 Dec
2023
13 Dec
'23
5:04 p.m.
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
14 Dec
14 Dec
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
15 Dec
15 Dec
7 p.m.
Hi,
I have yet to try any of this with the newer version of klh10. However,
The following config line works:
devdev ni0 564 ni20 dedic=true ifmeth=tap+bridge
It uses the default bridge name ‘bridge0’ to create and configure a tap device ‘tap0’ and
any ‘ifc=’ part is ignored completely.
TOPS-20 brings up DECnet, TCP/IP and LAT successfully and is accessible via any of those
protocols.
The following config line works partially:
devdev ni0 564 ni20 dedic=true ifmeth=tap
A tap device ‘tap0’ is created and configured and any ‘ifc=’ part is ignored completely.
However, I am responsible for adding the device to a bridge with the linux command:
brctl addif bridge0 tap0
After this, the TOPS-20 instance is again accessible via DECnet, TCP/IP and LAT.
There doesn’t seem to be any option for using/specifying an existing tap device. As I
think I mentioned, if this were the case, I’d leave /etc/network/interfaces to create tap
devices with a ‘user’ specification and connect them to the relevant bridge… and remove
the need for dpni20 to run as root.
I think what I’ll do is add another method such as ifmeth=usetap, requiring an ifc=
specifier of an existing tap device to use and work from there.
Keith
From: Thomas DeBellis [mailto:tommytimesharing@gmail.com]
Sent: 14 December 2023 15:02
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet on KLH10 with Panda TOPS-20 issues
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@lists.dfupdate.se<mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to
hecnet-leave@lists.dfupdate.se<mailto:hecnet-leave@lists.dfupdate.se>
16 Dec
16 Dec
5:58 p.m.
That's interesting. Where did you get your klh10 from?
I have klh20 release h, which doesn't have anything like that. I'd like
to give whoever is distributing it some of my fixes to dpni20.c (to set
AllMulti on the Ethernet interface) and dvdte.c (fix to handle
keep-alive not incrementing crash and handle crash dumps). The last
active development work that I saw was to put code in to handle MIT
Chaosnet. I didn't keep up with that as I am focusing on getting Panda
II put together.
As a perhaps useful aside, when and if you get around to further
tinkering with ifmeth, and if this causes your Tops-20 to get confused
enough that crashes flat out (I.E., won't even complete boot), then
having a crash dump can be an extremely useful thing to have. How to go
about getting that isn't documented very well and it doesn't work at all
with dvdte.c which doesn't interpret certain commands from the 20. You
also need to do a set CPU_EXSAFE=1 (its value is normally 2).
Regarding having the networking coming up, recall that all such traffic
is going through the Tops-20 Multinet module (MNETDV.MAC). What this
suggests--and what I've seen in practice--is that if any of TCP/IP,
DECnet or LAT come up, then the NI 'hardware' is working, and that they
all will come up, eventually. In other words, you should focus on your
Tops-20 configuration particulars.
Speaking of having your DECnet up, your DECnet node definition file is
old and appears to date from before June 11th, 2019. This is what I'm
seeing when I sign into WALACH::
Job Line Program User Origin
9* 6 SYSTAT Not logged in 2.520(NRT)
You can pull the latest canonical version from MIM::. If your version
of Tops-20 NFT is not particularly stable, you can try pulling from
VENTI2::, viz:
@*NEW:NFT*
NFT 2.1(85)-5
NFT>*dir mim::fix.t20;0*
MIM::DU1:[DECNET]
FIX.T20;238;P775656 19 38400(8) 27-Nov-2023 18:16:13
NFT>d*ir venti2::node-data.txt.0*
VENTI2::TOMMYT:<OINKY>
NODE-DATA.TXT.1;P424242 15 37442(7) 27-Nov-2023 18:16:13
NFT>
You should probably reboot when trying to install as there are conflicts
between the 2019 and latest versions that will cause Tops-20 to quietly
and mysteriously choke, otherwise.
Finally, may I ask you to send me a copy of your klh20 .ini file?
------------------------------------------------------------------------
On 12/15/23 1:00 PM, Keith Halewood wrote:
Hi,
I have yet to try any of this with the newer version of klh10. However,
The following config line works:
devdev ni0 564 ni20 dedic=true ifmeth=tap+bridge
It uses the default bridge name ‘bridge0’ to create and configure a
tap device ‘tap0’ and any ‘ifc=’ part is ignored completely.
TOPS-20 brings up DECnet, TCP/IP and LAT successfully and is
accessible via any of those protocols.
The following config line works partially:
devdev ni0 564 ni20 dedic=true ifmeth=tap
A tap device ‘tap0’ is created and configured and any ‘ifc=’ part is
ignored completely.
However, I am responsible for adding the device to a bridge with the
linux command:
brctl addif bridge0 tap0
After this, the TOPS-20 instance is again accessible via DECnet,
TCP/IP and LAT.
There doesn’t seem to be any option for using/specifying an existing
tap device. As I think I mentioned, if this were the case, I’d leave
/etc/network/interfaces to create tap devices with a ‘user’
specification and connect them to the relevant bridge… and remove the
need for dpni20 to run as root.
I think what I’ll do is add another method such as ifmeth=usetap,
requiring an ifc= specifier of an existing tap device to use and work
from there.
Keith
> *From:*Thomas DeBellis [mailto:tommytimesharing@gmail.com]
> *Sent:* 14 December 2023 15:02
> *To:* hecnet(a)lists.dfupdate.se
> *Subject:* [HECnet] Re: DECnet on KLH10 with Panda TOPS-20 issues
>
> Short suggestion: try tossing the dedic=trueand 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 tapdevices 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
>>
145
days inactive
148
days old
3 comments
2 participants
participants (2)
-
Keith Halewood -
Thomas DeBellis