[HECnet] Re: DECnet on KLH10 with Panda TOPS-20 issues

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