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.