If I create multiple tun interfaces and specify .ifname='tun' (without tunnel number) in /etc/config/network for all of them, they get automatically numbered depending on wherever the tunnel is up/down.
Is there a ubus call or something to retrieve the mapping between the interface name and specific tunX interface name in that case? uci command returns just tun from the config file, I'm interested in getting the tunX with the tunnel number.
Thanks!
#!/bin/sh
. /lib/functions/network.sh
iface="lan"
network_get_device dev "$iface"
echo "Device of $iface is $dev"Thanks for the suggestion, I just tried that and it didn't work:
WRT3200 in ~ # source /lib/functions/network.sh
WRT3200 in ~ # network_flush_cache
WRT3200 in ~ # iface=pia
WRT3200 in ~ # uci show network.${iface}
network.pia=interface
network.pia.proto='none'
network.pia.ifname='tun'
WRT3200 in ~ # network_get_device dev $iface
WRT3200 in ~ # echo "Device of $iface is $dev"
Device of pia is
Anything else I could try?
Seems this is not tracked by netifd then, some external program appears to manage these interfaces. I am also not aware of any tunnel name auto-allocation in netifd, especially not for proto none.
What is actually creating those tun0 etc. interfaces?
I wish I knew, ifconfig shows them as tun0, tun1, etc. However there's no link between ifconfig and the interface name. 
Do you use openvpn?
Ah, yes, I do.
So first of all, whatever is in /etc/config/network is totally unrelated to the tun interfaces spawned by OpenVPN. What you can do is assigning fixed interface names in your OpenVPN configuration.
Instead of
dev tun
use
dev-type tun
dev foobar0
You can replace foobar0 with any valid interface name you like. This way the same OpenVPN instances will always create the same named interfaces.
Thanks for the information.
From my limited testing on 17.01.4, I've discovered that if the tunnel name is set with dev_type=tun and dev=ovpnc0 then:
network_get_device dev pia sets dev to an empty string.pia interface reload.Everything works fine if I use tunX instead of ovpnc0 as the device/tunnel name tho.
Is that expected? Should I file a bug on that? Against what?
UPDATE: I've looked at the system logs a bit more and turns out that if the device name is set to tunX then I do get the following in the log: daemon.notice netifd: Network device 'tun1' link is up. If the device name is set to ovpnc0 I do not get the Network device 'ovpnc0' link is up notice in the log and neither fw3 nor my PROCD service get reloaded. Oh, and network_get_device doesn't work as intended.
We're missing a piece of the picture here. Do you have any custom up scripts for OpenVPN or any hotplug scripts performing additional actions? Can you share your redacted full OpenVPN configuration as well as your network config?
No, no custom up/down scripts. As soon as I change tun0 to ovpns0 and/or tun1 to ovpnc0 I stop getting netifd notices on the interface up.
WRT3200 in ~ # ls /etc/hotplug.d/iface/
00-netstate 11-sqm 15-teql 20-firewall 50-miniupnpd
WRT3200 in ~ # tail /etc/config/network
config interface 'vpnserver'
option proto 'none'
option ifname 'tun0'
option auto '1'
config interface 'pia'
option proto 'none'
option ifname 'tun1'
WRT3200 in ~ # cat /etc/config/openvpn
config openvpn 'vpnserver'
option enabled '1'
option dev_type 'tun'
option dev 'tun0'
option port '1194'
option proto 'tcp'
option comp_lzo 'yes'
option keepalive '10 120'
option persist_key '1'
option persist_tun '1'
option ca '/etc/openvpn/ca.crt'
option cert '/etc/openvpn/*.crt'
option key '/etc/openvpn/*.key'
option dh '/etc/openvpn/*.pem'
option tls_auth '/etc/openvpn/*.key'
option mode 'server'
option tls_server '1'
option server '192.168.*.* 255.255.255.0'
option topology 'subnet'
option route_gateway 'dhcp'
option client_to_client '1'
option key_direction '0'
list push 'comp-lzo yes'
list push 'persist-key'
list push 'persist-tun'
list push 'topology subnet'
list push 'route-gateway dhcp'
list push 'redirect-gateway def1'
list push 'route 192.168.*.* 255.255.255.0'
list push 'dhcp-option DNS 192.168.*.*'
config openvpn 'pia'
option enabled '1'
option client '1'
option dev_type 'tun'
option dev 'tun1'
option resolv_retry 'infinite'
option nobind '1'
option persist_key '1'
option persist_tun '1'
option tls_client '1'
option remote_cert_tls 'server'
option ca '/etc/openvpn/*.crt'
option crl_verify '/etc/openvpn/*.pem'
option auth_user_pass '/etc/openvpn/*.pem'
option auth_nocache '1'
option comp_lzo 'yes'
option verb '1'
option reneg_sec '0'
option keepalive '10 60'
option float '1'
option auth 'SHA1'
option cipher 'AES-128-CBC'
option disable_occ '1'
option proto 'udp'
list remote '*.*.* 1198'
option mute_replay_warnings '1'The network config is different to what you have posted previously
It is important that you provide the exact configuration. Previously you said you use option ifname 'tun' on pia which wouldn't make any sense. Now it seems it actually uses tun1.
What is reported by ifstatus vpnserver and ifstatus pia after the VPNs are established?
Yeah, with just tun as the ifnames for both vpnserver and pia things didn't work at all. 
Discovered the problem -- I forgot to change the ifname in the network config to reflect the new dev settings in openvpn config. Once I changed it to ovpns0 and ovpnc0 in both openvpn and network config files everything works.
Ah - great. Thanks for the update 