Discussion:
[OpenWrt-Devel] netifd: handling of interfaces with proto "none"
Lars Kruse
2015-06-08 01:56:08 UTC
Permalink
Hi,

currently I am struggling with the management of dynamically created network
interfaces.
Specifically I want to create an openvpn connection to a server and add the
automatically generated network interface (tapX; managed by openvpn) to a
specific zone.

I planned to use the following commands in the up-script of my openvpn setup:
uci set "network.${netname}=interface"
uci set "network.${netname}.proto=none"
uci set "network.${netname}.ifname=$ifname"
uci add_list "***@zone[1]=${netname}"
uci commit network
uci commit firewall
reload_config

But the above fails to work. Just a second after the execution of
"reload_config" the configured IP address of the openvpn client interface is
removed.
Instead I expected that the setting "proto=none" would cause this network
interface to be ignored by any network configuration code.

The high-level line of code causing the deconfiguration of the openvpn network
interface is:
ubus call network reload
I failed to analyze the netifd code in such a depth that I could tell where
the IP address is removed.
For example I tried to distribute "netifd_log_message" calls at various places
within netifd/interface.c. Sadly these log lines caused network setup
problems/lockups if placed within specific functions (e.g.
"interface_set_proto_state"). Since I used a physical device without a serial
console for testing, this debugging procedure was quite cumbersome as I had to
flash the device over and over again.


Now I am not sure how to proceed:
1) Is my assumption correct that the network interface configuration should
stay unchanged for devices with "proto=none" (luci seems to call this
setting "unmanaged")?
2) Could someone please give me a hint how to debug the network setup in order
to find the specific piece of code that manipulates network devices with the
above setting?

Cheers,
Lars


PS: the following shell commands show the effect of the deconfiguration with a
quite simple setup:
1) create a previously non-existing interface (as a vlan)
2) configure the interface
3) create a uci section for the interface with "proto=none"
4) reload the network configuration
5) one second later the previously configured IP is removed
Instead I expected it to remain unchanged.

ip addr show dev foo
ip link add link eth0 name foo type vlan id 17
ip addr show dev foo
ifconfig foo 172.16.145.1
ip addr show dev foo
uci set "network.foo=interface"
uci set "network.foo.proto=none"
uci set "network.foo.ifname=foo"
uci commit network
reload_config
ip addr show dev foo
sleep 1
ip addr show dev foo
uci delete network.foo
uci commit network
reload_config
ip link del dev foo
Jo-Philipp Wich
2015-06-08 08:17:06 UTC
Permalink
Hi Lars,

I struggled with this issue as well and after a brief chat with nbd the
conclusion was to force the tap device to be "external", this will cause
netifd to leave its routes and address config alone, even when ifup is
called on the network.

In short you need to prepare the vpn interface without any ifname option,
using something like that:

# prepare network if not existing yet
if ! uci -q get network.${netname}; then
uci set network.${netname}=interface
uci set network.${netname}.proto=none
ubus call network reload
fi

# externally attach netdev
ubus call network.interface.${netname} add_device '{ "name": "'$ifname'" }'


If you then call "ifstatus" on $netname you should see "device" and
"l3_device" pointing to "$ifname". Calling "devstatus" on $ifname should
display "external: true".


HTH,
Jow

Loading...