I have the Panda Distribution set up to run TOPS20 using the klt20
emulator running on Debian 12. This works fine except that I can't
access the local network. On bootup, the emulator first reports that

[dpni20: Using default interface "eth0"]

Despite being told elsewhere that this should be enough, it doesn't
work. So I tried setting up a bridge. There seem to be a lot of ways
to do that, and I keep finding ones that Don't Work. What is a
known-good and up-to-date way of getting my emulated pdp10 access to the
local network and hopefully able to ftp out across the internet?

--
David Griffith
dave@661.org

dave@661.org (David Griffith) writes:

> I have the Panda Distribution set up to run TOPS20 using the klt20
> emulator running on Debian 12. This works fine except that I can't
> access the local network. On bootup, the emulator first reports that
>
> [dpni20: Using default interface "eth0"]
>
> Despite being told elsewhere that this should be enough, it doesn't
> work. So I tried setting up a bridge. There seem to be a lot of ways
> to do that, and I keep finding ones that Don't Work. What is a
> known-good and up-to-date way of getting my emulated pdp10 access to the
> local network and hopefully able to ftp out across the internet?

What is the definition line from your config file for the NI? Are you using an
appropriate IP address for your network?

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Rich Alderson <news@alderson.users.panix.com> wrote:
> dave@661.org (David Griffith) writes:

>> I have the Panda Distribution set up to run TOPS20 using the klt20
>> emulator running on Debian 12. This works fine except that I can't
>> access the local network. On bootup, the emulator first reports that
>>
>> [dpni20: Using default interface "eth0"]
>>
>> Despite being told elsewhere that this should be enough, it doesn't
>> work. So I tried setting up a bridge. There seem to be a lot of ways
>> to do that, and I keep finding ones that Don't Work. What is a
>> known-good and up-to-date way of getting my emulated pdp10 access to the
>> local network and hopefully able to ftp out across the internet?

> What is the definition line from your config file for the NI? Are you
> using an appropriate IP address for your network?

My local network uses 10.0.0.x. This is how I started:
devdef ni0 564 ni20 ipaddr=10.0.0.51

I've ensured that the system files described at
http://www.ldx.ca/notes/tops-20-notes.html are set correctly:
SYSTEM:HOSTS.TXT
SYSTEM:INTERNET.ADDRESS
SYSTEM:INTERNET.GATEWAYS

--
David Griffith
dave@661.org

David Griffith wrote:
>>> On bootup, the emulator first reports that
>>> [dpni20: Using default interface "eth0"]
>
> My local network uses 10.0.0.x. This is how I started:
> devdef ni0 564 ni20 ipaddr=10.0.0.51

Since you didn't say otherwise, KLH10 is using the eth0 interface.
This may well work in some situation. Back when I was doing this,
I got a second (hardware) network interface and had KLH10 use that.

But you said you want to use a bridge. For that to work, you need to
tell KLH10 to use the bridge interface, not eth0. Checking install.txt,
I see you should add IFC=<name>, where <name> is the right bridge
interface. Maybe also DEDIC=TRUE, since the interface isn't shared
between the host and KLH10. Maybe also IFMETH=<something>. You should
probably drop IPADDR.

Lars Brinkhoff <lars.spam@nocrew.org> wrote:
> David Griffith wrote:
>>>> On bootup, the emulator first reports that
>>>> [dpni20: Using default interface "eth0"]
>>
>> My local network uses 10.0.0.x. This is how I started:
>> devdef ni0 564 ni20 ipaddr=10.0.0.51

> Since you didn't say otherwise, KLH10 is using the eth0 interface.
> This may well work in some situation. Back when I was doing this,
> I got a second (hardware) network interface and had KLH10 use that.

> But you said you want to use a bridge. For that to work, you need to
> tell KLH10 to use the bridge interface, not eth0. Checking install.txt,
> I see you should add IFC=<name>, where <name> is the right bridge
> interface. Maybe also DEDIC=TRUE, since the interface isn't shared
> between the host and KLH10. Maybe also IFMETH=<something>. You should
> probably drop IPADDR.

After fiddling with this some more, I followed what I found at
https://jim-st.blogspot.com/2019/07/running-pdp10klh10-on-raspberry-pi.html
exactly, with a Debian 10 (buster) install on a Pi 4. It didn't work.

Contents on /etc/network/interfaces on the host:
auto lo br0 tap1 tap2 tap3
iface lo inet loopback
iface eth0 inet manual
iface tap1 inet manual
pre-up ip tuntap add tap1 mode tap user dave
iface tap2 inet manual
pre-up ip tuntap add tap2 mode tap user dave
iface tap3 inet manual
pre-up ip tuntap add tap3 mode tap user dave
iface br0 inet static
bridge_ports eth0 tap1 tap2 tap3
bridge_fd 0
address 10.0.0.200
netmask 255.255.255.0
gateway 10.0.0.1

The networking line from the .ini file is this:
devdef ni0 564 ni20 ifc=tap1 dedic=TRUE

When I start the simulation, I get this:
KLH10# ; Ready to GO
KLH10# [EOF on tops20.ini]
KLH10# go
Starting KN10 at loc 040000...
....
BOOT V11.0(315)
....
BOOT>
....
[BOOT: Loading] [OK]
....
[TOPS20 mounted]
Panda Distribution, PANDA TOPS-20 Monitor 7.1(21733)-4 Internet: Loading host names [OK]
....
System restarting, wait...
Date and time is: Sunday, 15-October-2023 4:10PM
Why reload? new
Run CHECKD? n
DDMP: Started
[dpni20: ifc "tap0" => ether f2:b:a4:2c:71:6c]
[dpni20: VHOST 0.0.0.0]
[KNILDR: Loading microcode version 1(172) into Ethernet channel 0]
....
SYSJOB 7A(88)-4 started at 15-Oct-2023 1610
SJ 0: @LOGIN OPERATOR
SJ 0: @ENABLE
SJ 0: $SYSTEM:STSJ1
15-Oct-2023 16:10:41 SYSJB1: SYSJB1 started.
SJ 0: $^ESET LOGIN ANY
SJ 0: $OPR
....
[NCP]: Waiting for ORION to start
....
@login operator
@ftp ftp.661.org
?No such host - Unknown host name - "ftp.661.org"
@

At this point, I don't know how to get an instance of TOPS20 running
with network access working. How is anyone else here doing this?

--
David Griffith
dave@661.org

> @ftp ftp.661.org
> ?No such host - Unknown host name - "ftp.661.org"

What if you use the ip address instead of the name?

De

Dennis Boone <drb@ihatespam.msu.edu> wrote:
> > @ftp ftp.661.org
> > ?No such host - Unknown host name - "ftp.661.org"

> What if you use the ip address instead of the name?

Same thing.

--
David Griffith
dave@661.org

David Griffith wrote:
> The networking line from the .ini file is this:
> devdef ni0 564 ni20 ifc=tap1 dedic=TRUE
[...]
> [dpni20: ifc "tap0" => ether f2:b:a4:2c:71:6c]

I wonder why the devdef says tap1 but dpni20 says tap0? I would have
thought they should match.

> At this point, I don't know how to get an instance of TOPS20 running
> with network access working. How is anyone else here doing this?

Come to think of it, I think there's at least one person running TOPS-20
on KLH10 with network access. I'll go ask.

Lars Brinkhoff wrote:
> David Griffith wrote:
> > The networking line from the .ini file is this:
> > devdef ni0 564 ni20 ifc=tap1 dedic=TRUE
> [...]
> > [dpni20: ifc "tap0" => ether f2:b:a4:2c:71:6c]
> I wonder why the devdef says tap1 but dpni20 says tap0? I would have
> thought they should match.
> > At this point, I don't know how to get an instance of TOPS20 running
> > with network access working. How is anyone else here doing this?
> Come to think of it, I think there's at least one person running TOPS-20
> on KLH10 with network access. I'll go ask.

I've "always" used klh10 with a tap interface (no bridge). My devdef line is

devdef ni0 564 ni20 ipaddr=192.168.65.20 tunaddr=192.168.65.1 ifmeth=tap decnet=false

Note: no interface specified, no gwaddr. This creates a tap interface (typically tap0) where the TOPS-20 end has 192.168.65.20 and the host end has 192.168.65.1. In order to have external access, you need to set up IP forwarding and firewalls. You can have a look at MMcM's setup from 2003 at https://gist.github.com/MMcM/c2f99cc7656af6c15aac#file-klh10-firewall or I can share my current scripts with you?

-- Björn

Hello,

> Come to think of it, I think there's at least one person running TOPS-20
> on KLH10 with network access. I'll go ask.

I am running it, with full network support (DECNET included). My universal solution for VM/Simulator network connectivity is always the same:

Use VDE.

My networking configuration line:

devdef ni0 564 ni20 dedic=true decnet=true ifmeth=vde ifc=/tmp/vde.ctl dppath=/home/jguillaumes/bin/klh10-kl/dpni20

I set up vde at debian startup. This is my /etc/network/interfaces:

auto lo
iface lo inet loopback

auto eth0
auto tap0
iface tap0 inet manual

auto br0
iface br0 inet static
address 192.168.0.15
netmask 255.255.255.0
gateway 192.168.0.128
broadcast 192.168.0.255
bridge-ports tap0 eth0
dns-nameservers nnn.nnn.nnn.nnn
dns-domain xxxxxx.xxxxx.xxxx

(Of course, replace the placeholders with your network configuration).

You should have also these files (IIRC they are created by dkpg at package install):

jguillaumes@emul00:/etc/network$ ls -l if-pre-up.d/
total 8
lrwxrwxrwx 1 root root 29 Jan 27 2019 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root 144 Jan 10 2018 tuntap
-rwxr-xr-x 1 root root 1793 Dec 10 2016 vde2

I can run klh10, simh, QEMU and 86box instances and they see each other (in different servers, each one with its VDE hub running).

Jordi Guillaumes Pons wrote:
>> Come to think of it, I think there's at least one person running
>> TOPS-20 on KLH10 with network access. I'll go ask.
> I am running it, with full network support (DECNET included). My
> universal solution for VM/Simulator network connectivity is always the
> same: Use VDE.

Thanks for this information! Will VDE also let the guest systems reach
outside running on a wifi-only host?

dave@661.org (David Griffith) writes:
>Lars Brinkhoff <lars.spam@nocrew.org> wrote:
>> David Griffith wrote:
>>>>> On bootup, the emulator first reports that
>>>>> [dpni20: Using default interface "eth0"]
>>>
>>> My local network uses 10.0.0.x. This is how I started:
>>> devdef ni0 564 ni20 ipaddr=10.0.0.51

My day job is writing simulators for modern SoCs.

Here is the recipe we use to setup tap device(s)
bridged to a host network port (on RHEL, but the
concepts are universal):

# tunctl -p -u USERNAME -t simnic0
# brctl addbr sim-br0
# brctl addif sim-br0 simnic0
# brctl stp sim-br0 off
# ifconfig simnic0 up
# ifconfig sim-br0 172.25.17.100/24 up
# ethtool -K sim-br0 tx off
# iptables -t nat -A POSTROUTING -o eth0 -s 172.25.17.0/24 -j MASQUERADE

> # tunctl -p -u USERNAME -t simnic0
> # brctl addbr sim-br0
> # brctl addif sim-br0 simnic0
> # brctl stp sim-br0 off
> # ifconfig simnic0 up
> # ifconfig sim-br0 172.25.17.100/24 up
> # ethtool -K sim-br0 tx off
> # iptables -t nat -A POSTROUTING -o eth0 -s 172.25.17.0/24 -j MASQUERADE

Does this recipe allow the sim to talk to the host, or just the
outside world?

De

drb@ihatespam.msu.edu (Dennis Boone) writes:
> > # tunctl -p -u USERNAME -t simnic0
> > # brctl addbr sim-br0
> > # brctl addif sim-br0 simnic0
> > # brctl stp sim-br0 off
> > # ifconfig simnic0 up
> > # ifconfig sim-br0 172.25.17.100/24 up
> > # ethtool -K sim-br0 tx off
> > # iptables -t nat -A POSTROUTING -o eth0 -s 172.25.17.0/24 -j MASQUERADE
>
>Does this recipe allow the sim to talk to the host, or just the
>outside world?

Both. It taps into the kernel network stack as if it were just another
network adapter. The NATing means you don't need to allocate an IP
address on your local net for the "guest" os. It will correctly route
packets with local network addresses and if the host default gateway
is setup properly, will reoute non-local network addresses to the
default gateway. (or any configured gateway for unusual network configurations).

The spanning tree protocol is disabled on the bridge.

On Monday, October 16, 2023 at 12:31:25 PM UTC+2, Lars Brinkhoff wrote:

> Thanks for this information! Will VDE also let the guest systems reach
> outside running on a wifi-only host?

Yes, by using either vde_cryptcab or a combination of vde_plug and nc or dpipe.

VDE works by creating a "virtual ethernet switch" in your machine. This switch has ports, and ports can be connecter to either programs supporting vde, like simh, klh10, qemu or 86 box, or to "vde cables". Those virtual cables can be "plugged"

On Saturday, October 21, 2023 at 12:41:21 PM UTC+2, Jordi Guillaumes Pons wrote:
> On Monday, October 16, 2023 at 12:31:25 PM UTC+2, Lars Brinkhoff wrote:
>
> > Thanks for this information! Will VDE also let the guest systems reach
> > outside running on a wifi-only host?
> Yes, by using either vde_cryptcab or a combination of vde_plug and nc or dpipe.
>
> VDE works by creating a "virtual ethernet switch" in your machine. This switch has ports, and ports can be connecter to either programs supporting vde, like simh, klh10, qemu or 86 box, or to "vde cables". Those virtual cables can be "plugged"

Damn, I fat-fingered something...

Those virtual cables can be "plugged" to:

- A tap network interface, if your OS supports it.
- PCAP (and hence, another interface)
- stdin/stdout
- Another "cable"

There are several kinds of cables, to achieve those connection options. You will be probably interested in:

- vde_plug, which simply connects to stdin/stdout. All the bytes written into its stdin are injected into the virtual switch (and if they are valid ethernet frames they will be read by all the virtual machines plugged into it), and all traffic in the switch is sent to stdout. This way you can pipe one vde_plug into another and you will have two connected switches. If you use nc or dpipe you will be able to connect two switches in different machines.
- vde_cryptcab, which is designed to be connected to another vde_cryptcab in another machine and establish an encrypted tunnel between two switches.

Most setup is the following:

- I have a VM running several instances of simh, plus one instance of klh10, and vde_cryptcab in "server mode". Something like this:

vde_cryptcab -s /tmp/vde.ctl -p 52100

/tmp/vde.ctl is the socket directory where the virtual switch establishes its connections, and 52100 is the TCP port number the vde_cryptcab server will listen on.

Then, in my laptop I set up a virtual switch bridged to physical ethernet (cabled!) and I launch vde_cryptcab in client mode:

vde_cryptcab -s /tmp/vde.ctl -c $VDEHOST:52100 -d

$VDEHOST contains the ip address or host name of the machine where the other cryptcab is running. Now the virtual switch in my laptop is part of the same ethernet segment! Any machine I spawn in my laptop using that vde switch is adjacent to the ones running in the server. And since the server switch is plugged into a real ethernet interface, I have internet access.

It works perfectly for IP and DECNET. It should also work for IPX and any other level 2 protocol but I have not tested that.

By the way, if you use a mac, you won't be able to connect to a tap interface, and vde_cryptcab is not included (or wasn't included the last time I checked) in the available homebrew binary package. The good news is it IS included in the source code (https://github.com/virtualsquare/vde-2), implemented by yours truly, so if you build it from sources, you will have it.

Hope this helps!

Scott Lurndal writes:
>>Does this recipe allow the sim to talk to the host, or just the
>>outside world?
> Both. It taps into the kernel network stack as if it were just
> another network adapter. The NATing means you don't need to allocate
> an IP address on your local net for the "guest" os.

Wifi is a stumbling block for many. It seems your recipe might work for
wifi due to rewriting the guest IP number using NAT, but will it also
rewrite the MAC address? I should just try it and see, but I and others
have tried this so many times without success so I have almost given up.

I recently read about doing NAT on the Ethernet level. It seemed
promising, but when I tested it there was some step that wasn't allowed
by my wifi card. Something or other about 4addr not being supported.

Scott Lurndal <scott@slp53.sl.home> wrote:
> drb@ihatespam.msu.edu (Dennis Boone) writes:
>> > # tunctl -p -u USERNAME -t simnic0
>> > # brctl addbr sim-br0
>> > # brctl addif sim-br0 simnic0
>> > # brctl stp sim-br0 off
>> > # ifconfig simnic0 up
>> > # ifconfig sim-br0 172.25.17.100/24 up
>> > # ethtool -K sim-br0 tx off
>> > # iptables -t nat -A POSTROUTING -o eth0 -s 172.25.17.0/24 -j MASQUERADE
>>
>>Does this recipe allow the sim to talk to the host, or just the
>>outside world?

> Both. It taps into the kernel network stack as if it were just another
> network adapter. The NATing means you don't need to allocate an IP
> address on your local net for the "guest" os. It will correctly route
> packets with local network addresses and if the host default gateway
> is setup properly, will reoute non-local network addresses to the
> default gateway. (or any configured gateway for unusual network
> configurations).

> The spanning tree protocol is disabled on the bridge.

Suppose I want to run multiple emulators on the same machine and give
each emulated machine its own IP address -- how would the above
instructions change?

--
David Griffith
dave@661.org

Lars Brinkhoff <lars.spam@nocrew.org> wrote:
> Scott Lurndal writes:
>>>Does this recipe allow the sim to talk to the host, or just the
>>>outside world?
>> Both. It taps into the kernel network stack as if it were just
>> another network adapter. The NATing means you don't need to allocate
>> an IP address on your local net for the "guest" os.

> Wifi is a stumbling block for many. It seems your recipe might work for
> wifi due to rewriting the guest IP number using NAT, but will it also
> rewrite the MAC address? I should just try it and see, but I and others
> have tried this so many times without success so I have almost given up.

> I recently read about doing NAT on the Ethernet level. It seemed
> promising, but when I tested it there was some step that wasn't allowed
> by my wifi card. Something or other about 4addr not being supported.

It's still not working. For my latest attempt, I'm using this script to
set up an ethernet bridge:

#!/bin/sh

TAPUSER="dave"
#DEV="enp3s0"
DEV="eth0"

IFCONFIG="/sbin/ifconfig"
ROUTE="/sbin/route"
TUNCTL="/usr/bin/tunctl"
BRCTL="/sbin/brctl"

#HOSTIP=`hostname -I`
HOSTIP=`$IFCONFIG $DEV | gawk -- '/inet/{ print substr($2,1) }' | head -n1`
HOSTNM=`$IFCONFIG $DEV | gawk -- '/inet/{ print substr($4,1) }' | head -n1`
HOSTBR=`$IFCONFIG $DEV | gawk -- '/inet/{ print substr($6,1) }' | head -n1`
HOSTGW=`$ROUTE -n | gawk -- '/^0.0.0.0/{ print $2 }' | head -n 1`

#
echo "Device: $DEV"
echo "Host Addr: ${HOSTIP}"
echo "Netmask: ${HOSTNM}"
echo "Broadcast: ${HOSTBR}"
echo "Default GW: ${HOSTGW}"
# #exit

$TUNCTL -t tap0 -u $TAPUSER
#$TUNCTL -t tap1 -u $TAPUSER
#$TUNCTL -t tap2 -u $TAPUSER
$IFCONFIG tap0 up
#$IFCONFIG tap1 up
#$IFCONFIG tap2 up

#
# Now convert eth0 to a bridge and bridge it with the TAP interface
$BRCTL addbr br0
$BRCTL addif br0 $DEV
$BRCTL setfd br0 0
$IFCONFIG $DEV 0.0.0.0
$IFCONFIG br0 $HOSTIP netmask $HOSTNM broadcast $HOSTBR up
# set the default route to the br0 interface
$ROUTE add -net 0.0.0.0/0 gw $HOSTGW
# bridge in the tap device
$BRCTL addif br0 tap0
#$BRCTL addif br0 tap1
#$BRCTL addif br0 tap2
$IFCONFIG tap0 0.0.0.0
#$IFCONFIG tap1 0.0.0.0
#$IFCONFIG tap2 0.0.0.0
echo "nameserver $HOSTGW" >>/etc/resolv.conf

I now have this from ifconfig -a:

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.200 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 fe80::dea6:32ff:fe8d:beb1 prefixlen 64 scopeid 0x20<link>
ether 62:81:39:ef:9c:60 txqueuelen 1000 (Ethernet)
RX packets 6665 bytes 687214 (671.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4392 bytes 616787 (602.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.200 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 fe80::2bd:675c:d87c:eea0 prefixlen 64 scopeid 0x20<link>
ether dc:a6:32:8d:be:b1 txqueuelen 1000 (Ethernet)
RX packets 107392 bytes 18851135 (17.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 17072 bytes 2104538 (2.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 39181290 bytes 3795708610 (3.5 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 39181290 bytes 3795708610 (3.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 62:81:39:ef:9c:60 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.200 netmask 255.0.0.0 broadcast 10.255.255.255
inet6 fe80::d0d7:b6ff:fe1c:dd45 prefixlen 64 scopeid 0x20<link>
ether d2:d7:b6:1c:dd:45 txqueuelen 1000 (Ethernet)
RX packets 76 bytes 7734 (7.5 KiB)
RX errors 0 dropped 26 overruns 0 frame 0
TX packets 36 bytes 4593 (4.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.125 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 fe80::fcff:d312:9210:7935 prefixlen 64 scopeid 0x20<link>
ether dc:a6:32:8d:be:b2 txqueuelen 1000 (Ethernet)
RX packets 52372 bytes 8347062 (7.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 269 bytes 13736 (13.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

This is the .ini file I'm giving to the kn10-kl executable:

; Define basic device config - one DTE, one disk, one tape
devdef dte0 200 dte master
devdef rh0 540 rh20
devdef rh1 544 rh20
devdef dsk0 rh0.0 rp type=rp07 format=dbd9
devdef mta0 rh1.0 tm03 type=tu45

; Set Ethernet address
devdef ni0 564 ni20 ipaddr=10.0.0.200 ifc=tap0 decnet=false dedic=TRUE

; Define the idle device on 700
devdef idler 700 host

; Set switch register
set sw=254200,,147

; Set console lights I/O base register
;Uncomment the following line if you have a Panda display.
;lights 378

; Load disk bootstrap directly
load boot.sav

; Ready to GO

Now to run it, I've made sure that dpni20 is setuid-root, but when I
start the emulation as a normal user, I get these error messages having
to do with networking:

Run CHECKD? no
DDMP: Started
SIOCSIFADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
SIOCSIFDSTADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
SIOCSIFFLAGS: Operation not permitted

[dpni20: Fatal error: osn_pfinit_tuntap: ifconfig failed to initialize tunnel device? - Success]
[KNILDR: Loading microcode version 1(172) into Ethernet channel 0]

14-Nov-2023 21:05:29 ***BUGCHK KNIINF*** PHYKNI - NIA20 initialization timed out Job: 0, User: OPERATOR, Data: 400007000036
14-Nov-2023 21:05:34 ***BUGCHK IPDWNS*** Datagram was
SYSJOB 7A(88)-4 started at 14-Nov-2023 2105
not sent Job: 0, User: OPERATOR, Data: 36, 2
14-Nov-2023 21:05:34 ***BUGCHK KNIRLF*** PHYKNI - NIA20 Reload Failed Job: 0, User: OPERATOR, Data: 10

Here's what happens if I run it as root:

Run CHECKD? no
DDMP: Started
[dpni20: ifc "tap2" => ether f2:b:a4:54:52:4]
[dpni20: VHOST 10.0.0.200]
[dpni20: Enabled net.ipv4.conf.tap2.arp_accept]
[KNILDR: Loading microcode version 1(172) into Ethernet channel 0]

I believe this is now correct behavior. But the TOPS20 instance is
still not getting access to the network, not even to itself:

@ftp ftp.foo.bar
?No such host - Unknown host name - "ftp.foo.bar"
@ftp 123.123.123.123
?No such host - Unknown host name - "123.123.123.123"
@ftp 10.0.0.200

--
David Griffith
dave@661.org

dave@661.org (David Griffith) writes:

[ snip ]

> Here's what happens if I run it as root:

> Run CHECKD? no
> DDMP: Started
> [dpni20: ifc "tap2" => ether f2:b:a4:54:52:4]
> [dpni20: VHOST 10.0.0.200]
> [dpni20: Enabled net.ipv4.conf.tap2.arp_accept]
> [KNILDR: Loading microcode version 1(172) into Ethernet channel 0]

> I believe this is now correct behavior. But the TOPS20 instance is
> still not getting access to the network, not even to itself:

> @ftp ftp.foo.bar
> ?No such host - Unknown host name - "ftp.foo.bar"
> @ftp 123.123.123.123
> ?No such host - Unknown host name - "123.123.123.123"
> @ftp 10.0.0.200

Well, I see a serious error right off the bat.

Back before Unix screwed up the networking world, IP addresses were syntactically
different from DNS names, and TOPS-20 expects the old syntax.

What happens if you use the correct syntax?

@ftp [10.0.0.200]

The square brackets are required for an IP address.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Rich Alderson <news@alderson.users.panix.com> wrote:
> dave@661.org (David Griffith) writes:

> [ snip ]

>> Here's what happens if I run it as root:

>> Run CHECKD? no
>> DDMP: Started
>> [dpni20: ifc "tap2" => ether f2:b:a4:54:52:4]
>> [dpni20: VHOST 10.0.0.200]
>> [dpni20: Enabled net.ipv4.conf.tap2.arp_accept]
>> [KNILDR: Loading microcode version 1(172) into Ethernet channel 0]

>> I believe this is now correct behavior. But the TOPS20 instance is
>> still not getting access to the network, not even to itself:

>> @ftp ftp.foo.bar
>> ?No such host - Unknown host name - "ftp.foo.bar"
>> @ftp 123.123.123.123
>> ?No such host - Unknown host name - "123.123.123.123"
>> @ftp 10.0.0.200

> Well, I see a serious error right off the bat.

> Back before Unix screwed up the networking world, IP addresses were
> syntactically different from DNS names, and TOPS-20 expects the old
> syntax.

> What happens if you use the correct syntax?

> @ftp [10.0.0.200]

> The square brackets are required for an IP address.

10.0.0.200 corresponds to the wired ethernet interface on the host
machine, a Pi4, and is assigned by a local DHCP host.

When I used square brackets, the command took around a minute to
process, but I did manage to log into the TOPS20 instance from that
instance. But if I ftp in from some other IP address or from the host
system, the attempt goes to the host system.

I got the script from "kiteguy" on #pdp-10 at Libera.

--
David Griffith
dave@661.org