Comment 1 Kubilay Kocak 2022-10-12 22:49:16 UTC

Request feedback from Kyle, who's played in the dev/tun area of the tree in the not distant past and has tinkers with race conditions (with make_dev_s, in src 6869d530c791)

Comment 2 Kyle Evans 2022-10-13 04:29:27 UTC

(In reply to Seyed Pouria Mousavizadeh Tehrani from comment #0)

error == 17, EEXIST

Across the entire system, can you describe how you create and use tun interfaces? Are you just letting openvpn create them in their own vnets, or do you do any manual tun creation + moving them into a jail?

Do you do any tun interface renaming?

I have two net/ocserv applications in separate jails and give them unhide access to the "/dev/tun*" with devfs. The ocserv will use the /dev/tun special control device file to create tun interfaces and then rename it to the one listed in ocserv.conf ("device = vpns" by default). The default with "vpns" was not working, so I changed the configuration to the "device = tun" and it worked.

I also need openvpn-client on my host in another FIB, and to make things more predictable (actually for PF), I used two cloned tun interfaces (tun257, tun258) in "rc.conf". Finally, I allocated them via my openvpn-client configurations.

Note 1: I used same devfs rule for both jails. I want it to be separate for a clean configuration, but when I separate the devfs rules, the jail that uses a lower number in my rules will not see the "/dev/tun" special control note.
https://forums.freebsd.org/threads/ocserv-in-jail-cannot-open-dev-tun.86627/

Note 2: openvpn-client is not in jail, but last night due to multiple crashes of the entire system, I created an openvpn-server in another jail concurrent to the ocserv jails, which is doing tun allocation dynamically in their VNET.

Comment 4 Kyle Evans 2022-10-13 06:38:43 UTC

So, to be clear:

 - openvpn-client is using tun257 and tun258, it is in its own vnet.
 - The two ocserv jails also each have their own vnets, and use whatever tun interfaces they get from opening /dev/tun

Correct?

 - openvpn-client is using tun257 and tun258, it is in its own vnet:

No. openvpn-clients are in *host* and not in *jail* so their are not using vnet.

host rc.conf:
"""
openvpn_client_enable="YES"
openvpn_client_fib="1"
openvpn_client_configfile="/usr/local/etc/openvpn/client.conf"
openvpn_client2_enable="YES"
openvpn_client2_fib="2"
openvpn_client2_configfile="/usr/local/etc/openvpn/client2.conf"
"""

Here is the client configurations:
% grep dev /usr/local/etc/openvpn/client.conf 
dev tun257
% grep dev /usr/local/etc/openvpn/client2.conf
dev tun258


 - The two ocserv jails also each have their own vnets, and use whatever tun interfaces they get from opening /dev/tun:
Exactly.

one of my ocserv jail configurations:
"""
...
export jail_overlay_vnet_enable="YES"
export jail_overlay_vnet_interface="epair0b epair1b"
export jail_overlay_exec_prestart0="service netif cloneup epair0 epair1 || echo interfaces are already exists"
export jail_overlay_exec_prestart1="service routing static inet || echo static routes are already exists"
export jail_overlay_exec_prestart2="service openvpn_client restart"
export jail_overlay_exec_poststop0="/sbin/route del -net *.*.*.0/24 -gateway *.*.*7.2"
export jail_overlay_exec_poststop1="/sbin/route del -net *.*.*.0/24 -gateway *.*.*8.2 -fib 1"
export jail_overlay_exec_poststop2="/sbin/ifconfig epair0a destroy"
export jail_overlay_exec_poststop3="/sbin/ifconfig epair1a destroy"
"""

cloned interfaces in rc.conf:
"""
...
cloned_interfaces="lo1 gre0 gre1 tun257 tun258 epair5 epair4 epair3 epair2 epair1 epair0"
ifconfig_epair0a="inet *.*.*7.1/30 -tso -rxcsum descr vnet-overlay"
ifconfig_epair0b="-tso -rxcsum descr vnet-overlay"
ifconfig_epair1a="inet *.*.*8.1/30 fib 1 -tso -rxcsum descr vnet-overlay-fib-1"
ifconfig_epair1b="fib 1 -tso -rxcsum descr vnet-overlay-fib-1"
...
"""

Errata in previous comment: *Special Control Device*

Not sure if relevant but interface renaming seems to conflict with the name checks performed by `make_dev_sv`. For example, the following commands trigger the panic:

    # Destroy all existing tuns
    ifconfig -l -g tun | xargs -I {} ifconfig {} destroy

    # Create a new tun "/dev/tun0", and add a symbolic link "/dev/tun1" pointing on it
    ifconfig tun create name tun1

    # KERNEL PANIC here
    # panic: make_dev_sv: bad si_name (error=17, si_name=tun1)
    ifconfig tun create

(Tested on 653738e895ba, which is a bit old)

Comment 7 Konstantin Belousov 2023-12-12 00:18:45 UTC

https://reviews.freebsd.org/D43001

Comment 8 commit-hook 2023-12-12 04:02:47 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=0365e5fc905b425313a0a2d89f0d8e2566924df2

commit 0365e5fc905b425313a0a2d89f0d8e2566924df2
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: 2023-12-12 00:13:59 +0000
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2023-12-12 04:02:11 +0000

    if_tun: check device name

    to avoid panic if the name already exists, which is possible with the
    interface renaming.

    PR:     266999
    Reviewed by:    kevans
    Sponsored by:   The FreeBSD Foundation
    MFC after:      1 week
    Differential revision:  https://reviews.freebsd.org/D43001

 sys/net/if_tuntap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comment 9 commit-hook 2023-12-19 00:29:53 UTC

A commit in branch stable/14 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=399961e0a4132fb14b9b975c937cbc46849f8b39

commit 399961e0a4132fb14b9b975c937cbc46849f8b39
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: 2023-12-12 00:13:59 +0000
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2023-12-19 00:28:47 +0000

    if_tun: check device name

    PR:     266999

    (cherry picked from commit 0365e5fc905b425313a0a2d89f0d8e2566924df2)

 sys/net/if_tuntap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comment 10 commit-hook 2023-12-19 00:30:56 UTC

A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=a317a58658d4a529211c66b675ec7998032ecb4e

commit a317a58658d4a529211c66b675ec7998032ecb4e
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: 2023-12-12 00:13:59 +0000
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2023-12-19 00:29:28 +0000

    if_tun: check device name

    PR:     266999

    (cherry picked from commit 0365e5fc905b425313a0a2d89f0d8e2566924df2)

 sys/net/if_tuntap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comment 11 Mark Linimon 2024-01-02 03:29:26 UTC

^Triage: the 12 branch is now out of support.  Already MFCed to 13.

Assign to committer that resolved.