The usefulness of tap interfaces without bridge #67
Comments
|
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. |
|
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? |
|
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. |
|
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. 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,
|
|
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 But I also think it's a separate issue? |
|
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. |
|
@jayjwa did you try this? |
|
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. Here you can see it's by itself, as the newly created tap isn't in the bridge.
I did check to run the new binary. |
|
I suggest you add some debug printouts for the interesting code path in pfopen(), to see what happens. |
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
tunaddrparameter was given (indicating that it is to be used as a tunnel device) rather than checkingpfdata->pf_ip4_only(indicating atun(rather thantap) 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_IPONLYshould be abolished in favor ofpfdata.pf_ip4_only, but that's another matter.(Sorry if this looks more like a rant than an issue.)
The text was updated successfully, but these errors were encountered: