Lib functions network

I'm looking at migrating some old code that uses the uci -P /var/state style syntax.

In regard to the functions defined at /lib/functions/network.sh and the following article:

Get WAN interface

  • Backfire
    uci -P/var/state get network.wan.ifname

The uci state vars are deprecated and not used anymore for network related information. In Trunk (not really uci) do

. /lib/functions/network.sh; network_get_device if_wan wan; echo $if_wan
Or
. /lib/functions/network.sh; network_get_physdev if_wan wan; echo $if_wan

Can someone please explain to me the difference between network_get_device and network_get_physdev with some examples? What each one is actually telling me, and when you might want to use the result from each one?
For some interfaces, it appears that they return the same result. I found that on a PPPoE interface, network_get_device returned nothing, but network_get_physdev returned the eth device.

For some specific examples, lets talk about what are the replacements for the following:
uci -P /var/state get network.wan.ifname
and
uci -P /var/state get network.wan.device

Please assume basic understanding for this question, as i think i'm missing something fundamental given that i even have to ask.

Should you really assume the wan interface is called "wan"? Isn't it better to use network_find_wan and network_find_wan6?

network_find_wan name_wan; echo $name_wan
network_find_wan6 name_wan6; echo $name_wan6

For some specific examples, lets talk about what are the replacements for the following:
uci -P /var/state get network.wan.ifname
and
uci -P /var/state get network.wan.device

.ifname seems to correspond to network_get_device at least for my 6in4 interface.

For the LAN bridge .device is the ethernet interface, but it's neither returned by network_get_device nor network_get_physdev. (Both returns the bridge name.) I can't find the Ethernet interface in the result from ubus call network.interface dump which is used by network_get_device and network_get_physdev

1 Like

@jow you implemented most of the functions in that file. Are you able to provide any comment to the above please?

@lantis1008 few days ago I've got a similar topic in banIP. For debugging I wrote this small script for a user with a pppoe interface where banIP sets iptables rules for the wrong network device:

#!/bin/sh

. "/lib/functions/network.sh"

interfaces="wan"

for iface in $interfaces
do
        network_get_physdev tmp "${iface}"
        echo "DEV-Layer2: $iface, $tmp"
        network_get_device tmp "${iface}"
        echo "DEV-Layer3: $iface, $tmp"
done

Input is always the logical interface name used in OpenWrt. Output for this test case as follows:

DEV-Layer2: wan, eth0.2
DEV-Layer3: wan, pppoe-wan

Derived from the output, banIP determines now the correct device in the following order: L3 => L2

Hope this helps a bit!

3 Likes

Thanks for that.
In my previous testing on a PPPoE connection, network_get_device returned nothing. Now the interface was not actually up which may lead to the differences in testing? I'm not sure. It also could have been misconfigured. I quickly set it up because i had a hunch that it would be a special (or at least different) case.

My (personal) thoughts on this, are that i should almost always want to use the output of network_get_device, and use network_get_physdev where it returns nothing, or if i need to specifically address an eth device.

yep, in banIP it's implemented like that.