The usefulness of tap interfaces without bridge

[bictorv]

I'm about to migrate my oldest TOPS-20 system from klh-2.0h (last touched 2012) to this version, and discovered that NI20 tap interfaces don't work as they used to. It seems there is a little bit of confusion about the usefulness of tap-only devices (as opposed to tap+bridge devices), given comments in the code.

In my experience, tap-only devices are very useful as tunnel devices if they have their IP addresses set up (as they were in 2.0h). I just committed 510aedc which changes the crucial test to whether (in effect) the tunaddr parameter was given (indicating that it is to be used as a tunnel device) rather than checking pfdata->pf_ip4_only (indicating a tun (rather than tap) device).

I'm not sure if the other places in the code where tap+bridge is mentioned also need looking at.

And I think OSN_USE_IPONLY should be abolished in favor of pfdata.pf_ip4_only, but that's another matter.

(Sorry if this looks more like a rant than an issue.)

[Rhialto]

Looks good to me. I see you also adjusted the documentation. Nice.

I think it was this code in klh10 for setting up all those different networking scenarios for several operating systems that made me decide that from now on, I would not do it like that again. This stuff has lots of potential use cases, and is very non-portable, so it is easy to miss something. In the future I will leave all that sort of setup to the user. With a little script with the appropriate ifconfig and brconfig etc commands, you can set it up any way you want, even in ways that are difficult to handle when it's built into the virtual machine emulator. The documentation can mention some example cases that work for a system where I can test it, of course.

[bictorv]

I think usability is quite important, to support people who are not networking wizards, and to make it easier to get things running. "Most people" are probably more interested in running the historic OS, rather than setting up the network in the host system. Perhaps a new option "noconf=yes" to turn such things off, if you really need to do things differently? "If it works, don't break it"?

People like you and me can always get by (although I must admit getting bridging to work on Linux seems a hassle without extensive examples and/or screen+keyboard - but for me, tap (with IP config) suffices.)

Maintaining support for n+1 different operating systems is a hassle, of course. In this particular case, I wonder if the "ifconfig" method for setting it up wouldn't work basically everywhere? Doing it "manually" with ioctls adds possibilities of headaches?

[Rhialto]

Yes especially the ioctl way is annoying. I guess that's why there are some cases where an external program is called to do a step of the work.

And you remind me of the time when I went to set up a bridging configuration on Linux (bridging a tap to eth0) and it broke the whole networking. After lots of searching it turned out that this is even by design. I don't know who thought of doing it that way, but they should never be let anywhere near a network interface ever again. So since then I have a permanent bridge configured, for the occasions where I want to try klh or simh or hercules or whatever. Just to avoid the stupid moving of the IP address from interface to bridge and back again.

I haven't looked in detail if a "noconf=yes" is needed; I seem to have managed without it so far. I think it autodetects if a new tun/tap needs to be created, or if it already exists. This of course also complicates the logic and if we overhaul it again, such an option could be useful to simplify.

But for the moment I'm in no hurry to change it.

[jayjwa]

SIMH's style (ATT XQ tap:tap3) where it just grabs the interface you tell it would be useful. QEMU will do this too (-net tap,ifname=tap8). I have 1-10 taps ready to go, all under br0, but KLH10 will not use one, even if told. It will always create a new one and leave it disconnected. As a work-around, I found that I can start TOPS20, and quickly move the new tap under the bridge while the system is coming up.
ip -c link set dev tap11 master br0

Previously I tried (Linux host) tap+bridge, thinking this would get me the desired behavior as described above, but this created a tap device and pasted an IP address on it. It was a week before I could find out why I could no longer connect to a news website, nypost.com (192.0.66.32), and several others. 192.168.20.x is my internal LAN. tap+bridge had changed the routing table.

Currently this is working well,
devdef ni0 564 ni20 dedic=true ifmeth=tap ifc=tap11 decnet=true
other than the part of having to manually add the tap to the bridge (br0). In other words, it will not use the tap already available (tap10); it wants a new one each time, no matter what I specify for ifc= . For clarity, I've set ifc=tap11 since this is the interface that will be created, even if tap10 is available and ifc=tap10 is specified. This is contrary to what's listed in install.txt.

With both tun and tap you can specify with ifc=tun33 which of the tun/tap devices you want to use, for instance if you have one pre-set-up. Otherwise, one will be created for you.

devdef ni0 564 ni20 dedic=true ifmeth=tap ifc=tap10 decnet=true
yields:

[KNILDR: Loading microcode version 1(172) into Ethernet channel 0]

[dpni20: ifc "tap11" => ether f2:b:a4:75:b4:1a]
[dpni20:   VHOST 0.0.0.0]
[dpni20-W: "tap11" E/N addr changed: Old=f2:b:a4:75:b4:1a New=aa:0:4:0:13:4]

20: tap11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 72:80:14:96:26:77 brd ff:ff:ff:ff:ff:ff

[bictorv]

It looks like pfopen() in osdnet.c should (like the CENV_SYS_NETBSD case) check if an explicit tunnel unit number is specified, and then just use that (with open()). Probably something like

    /* See if an explicit tunnel unit number is given */
    if (isdigit(osnpf->osnpf_ifnam[3])) {
#if CENV_SYS_NETBSD
	fd = pfopen_create(basename, tt_ctx, osnpf);
#else
	fd = open(osnpf->osnpf_ifnam, O_RDWR, 0);
#endif /* CENV_SYS_NETBSD */
	if (fd >= 0) {
	    return fd;
	}
    }

But I also think it's a separate issue?

[Rhialto]

It has been a long time since I wrote this networking stuff, so what @bictorv says sounds plausible but I didn't check it in depth.

Since then I have come to the conclusion that I simply should have left out as much as possible of this stuff from the emulator code base, and just ask the user to run the appropriate commands before starting emulation. The system dependencies and differences are just too horrible.

[bictorv]

@jayjwa did you try this?

[jayjwa]

I did try it, but it does not produce the desired result. It still wants to make its own tap, which won't be in the bridge unless you put it there, bypassing the already created one.

[TOPS20 mounted]
AMATSU KLH, PANDA TOPS-20 Monitor 7.1(21733)-4 Internet: Loading host names [OK]

System restarting, wait...
Date and time is: Friday, 24-January-2025 12:42PM
Why reload? CM
Run CHECKD? n
 DDMP: Started
[KNILDR: Loading microcode version 1(172) into Ethernet channel 0]

[dpni20: ifc "tap11" => ether f2:b:a4:93:d1:2e]
[dpni20:   VHOST 0.0.0.0]
[dpni20-W: "tap11" E/N addr changed: Old=f2:b:a4:93:d1:2e New=aa:0:4:0:13:4]
24-Jan-2025 12:43:14 Internet: Network atr2net on, Output on

@info decnet
 Local DECNET node: AMATSU.  Nodes reachable: 1.
 Accessible DECNET nodes are:   AMATSU

Here you can see it's by itself, as the newly created tap isn't in the bridge.

devdef ni0 564 ni20 dedic=true ifmeth=tap ifc=tap10 decnet=true

I did check to run the new binary.

[bictorv]

I suggest you add some debug printouts for the interesting code path in pfopen(), to see what happens.