Proper way of dealing with aliased interfaces and UCI?

If you have the standard configuration for dual stack devices, with wan and wan6, you get:

$ uci get network.wan6.ifname
@wan <--- alias!
$ uci get network.wan.ifname
eth0

The code in luci-app-mwan3/luasrc/controller/mwan3.lua there is using UCI to pick up the name
inflame of the interface, and then calling ping -I @wan instead of ping -I eth0 if you're tracking a
v6 interface.

How should this be done? Should there be a second resolution step?

I've filed an issue against luci-app-mwan3 @feckert but this is a general issue as well.

Solely using uci to resolve ifnames has always been unreliable. Various tunnel protocols (e.g. 6in4) do not have an ifname property at all, single unbridged wireless networks neither, some protocols like pppoe use the uci ifname as physical layer 2 interface but have a different effective layer 3 one (pppoe-$netname) and so on.

The proper way to resolve the effective layer 3 interface (the one you most likely want to use for things like "ping" or "traceroute") is to use netifd interface state information exposed via ubus.

On the shell you can use the wrapper procedures in /lib/functions/network.sh:

 . /lib/functions/network.sh 
if network_get_device dev wan6; then
    echo "wan6 has device $dev"
fi

In LuCI you can use the luci.model.network class which provides high level access to general network state information as I wrote in your bug report:

2 Likes

Thank you jow. Pull request created.