if_tun module doesn't autoload if opening /dev/tunN

[Paul Goyette]

According to the tun(4) man page, you can create an interface "by using
the ifconfig(8) create command" and this works just fine. The man page
goes on to say "An open() call on /dev/tunN, will also create a network
interface..." but this does not work.

I think this is because the code in sys/miscfs/specfs/spec_vnops.c
assumes that the module name is the same as the device name, ie it
expects that /dev/tunN will be handled by module tun.kmod However, the
module is actually named if_tun.kmod so it never gets loaded, and the
open() fails.

I can see a couple of ways to "fix" this:

1. Rename the module (with all appropriate updates to the
sets lists in src/distrib/sets/lists), or
2. Add code to spec_vnops.c to try loading module if_xxx if the
autoload of module xxx fails.

Comments? Preferences? Any other options I haven't yet seen?


+------------------+--------------------------+------------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+

[Paul Goyette]

FWIW, even if you manually create the tun0 interface with ifconfig, it
is not accessible via /dev/tun0 - accessing the /dev/tun0 node results
in ENXIO (errno == 6, Device not configured).

I suspect that similar issues may well exist with other "cloners" such
as if_tap ... (Note that if_gif, if_gre, if_ppp, and if_pppoe do not
claim to be accessible via /dev so there shouldn't be any problems...)

I'll try to have a look at these sometime in the next few days, but if
anyone else wants to dive in, please don't hesitate! :)

[Martin Husemann]

On Wed, Sep 07, 2016 at 01:50:07PM +0800, Paul Goyette wrote:
> I can see a couple of ways to "fix" this:
>
> 1. Rename the module (with all appropriate updates to the
> sets lists in src/distrib/sets/lists), or
> 2. Add code to spec_vnops.c to try loading module if_xxx if the
> autoload of module xxx fails.

Add a static list of name exceptions? There probably are few.

Martin

[Paul Goyette]

Yeah, I thought of that, too, but I generally don't like such lists;
they tend to be forgotten and bit-rot. Let me reconsider....

[Paul Goyette]

On Wed, 7 Sep 2016, Martin Husemann wrote:

OK, perhaps something like the attached diffs?

I'm building now....

[Martin Husemann]

On Wed, Sep 07, 2016 at 06:17:59PM +0800, Paul Goyette wrote:
> OK, perhaps something like the attached diffs?

Yes, but renaming the modules sounds also like an acceptable solution.
I don't like the "always try both if the first name fails" aproach.

Martin

[Michael van Elst]

pa...@whooppee.com (Paul Goyette) writes:

>According to the tun(4) man page, you can create an interface "by using
>the ifconfig(8) create command" and this works just fine. The man page
>goes on to say "An open() call on /dev/tunN, will also create a network
>interface..." but this does not work.

You could create a dummy "tun" module that depends on "if_tun".

--
--
Michael van Elst
Internet: mle...@serpens.de
"A potential Snark may lurk in every tree."

[Paul Goyette]

On Wed, 7 Sep 2016, Martin Husemann wrote:

Renaming the modules means we'd have some if_* interface modules, and
some without the if_ prefix. I think that's confusing, and it's my
least favorite option.

[Paul Goyette]

On Wed, 7 Sep 2016, Michael van Elst wrote:

> pa...@whooppee.com (Paul Goyette) writes:
>
>> According to the tun(4) man page, you can create an interface "by using
>> the ifconfig(8) create command" and this works just fine. The man page
>> goes on to say "An open() call on /dev/tunN, will also create a network
>> interface..." but this does not work.
>
> You could create a dummy "tun" module that depends on "if_tun".

Hmmm, interesting possiblity.

[Paul Goyette]

On Wed, 7 Sep 2016, Paul Goyette wrote:

> On Wed, 7 Sep 2016, Martin Husemann wrote:
>
>> On Wed, Sep 07, 2016 at 01:50:07PM +0800, Paul Goyette wrote:
>>> I can see a couple of ways to "fix" this:
>>>
>>> 1. Rename the module (with all appropriate updates to the
>>> sets lists in src/distrib/sets/lists), or
>>> 2. Add code to spec_vnops.c to try loading module if_xxx if the
>>> autoload of module xxx fails.
>>
>> Add a static list of name exceptions? There probably are few.
>
> OK, perhaps something like the attached diffs?
>
> I'm building now....

Well, I did have to make a few minor changes to the patch (new diffs are
attached to this Email). But it appears to work. Opening /dev/tun0
results in ifconfig showing the new device. So progress has been made
and the module is correctly auto-loaded if needed. I plan to commit
these changes tomorrow unless there's some strong objections.

I don't have enough qemu networking clue to actually test for any real
functionality (passing of packets), but I've got a real-life scenario
where I can make that test. :) I'll check that out in the next few
days.

Thanks, Martin, for the suggestion of an appropriate fix mechanism.

[Michael van Elst]

That wouldn't work because 'ifconfig create' tries to load the existing
module name.

ifconfig create -> module name if_$driver
open device -> module name $driver

[Ryota Ozaki]

On Wed, Sep 7, 2016 at 2:50 PM, Paul Goyette <pa...@whooppee.com> wrote:
> According to the tun(4) man page, you can create an interface "by using the
> ifconfig(8) create command" and this works just fine. The man page goes on
> to say "An open() call on /dev/tunN, will also create a network
> interface..." but this does not work.
>
> I think this is because the code in sys/miscfs/specfs/spec_vnops.c assumes
> that the module name is the same as the device name, ie it expects that
> /dev/tunN will be handled by module tun.kmod However, the module is
> actually named if_tun.kmod so it never gets loaded, and the open() fails.
>
> I can see a couple of ways to "fix" this:
>
> 1. Rename the module (with all appropriate updates to the
> sets lists in src/distrib/sets/lists), or
> 2. Add code to spec_vnops.c to try loading module if_xxx if the
> autoload of module xxx fails.
>
> Comments? Preferences? Any other options I haven't yet seen?

Cannot we have an alias name for a device to use it for module_autoload?
I'm assuming cdevsw#d_mod_filename for example. It's simpler and explicit.

ozaki-r