[OpenWrt-Devel] [RFC] netifd: Override interface macaddr/mtu not working when new style vlan devices are used

Hans Dedecker dedeckeh at gmail.com
Fri Sep 12 09:13:11 EDT 2014


As described in the OpenWRT network wiki (http://wiki.openwrt.org/doc/uci/network#options.valid.for.all.protocol.types)
common interface uci parameters can be defined like mtu/macaddr/... which override the default interface values.
This is working fine when "old" style vlan configuration is used to override these parameters as can be seen below

config interface 'wan'
        option proto 'dhcp'
        option mtu '1450'
        option macaddr 'aa:bb:cc:dd:ee:ff'
        option ifname 'ptm0.20'

ip link show
...
22: ptm0.20 at ptm0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default 
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
..

Using the "new" device style configuration to define vlans overriding parameters like mtu/macaddr is not working

config interface 'wan'
        option proto 'dhcp'
        option mtu '1450'
        option macaddr 'aa:bb:cc:dd:ee:ff'
        option ifname 'vlan20'

config device 'vlan20'
        option type '8021q'
        option ifname 'ptm0'
        option name 'vlan20'
        option vid '20'

ip link show
....
21: vlan20 at ptm0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether a4:b1:e9:47:54:54 brd ff:ff:ff:ff:ff:ff
....

However you can workaround the issue by defining mtu/macaddr in the device section

config interface 'wan'
        option proto 'dhcp'
        option mtu '1450'
        option macaddr 'aa:bb:cc:dd:ee:ff'
        option ifname 'vlan20'

config device 'vlan20'
        option type '8021q'
        option ifname 'ptm0'
        option name 'vlan20'
        option vid '20'
        option mtu '1450'
        option macaddr 'aa:bb:cc:dd:ee:ff'

ip link show
...
21: vlan20 at ptm0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default 
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
...

Now I'm a bit puzzled if the oberved behavior (need to define mtu/macaddr in the device section to make override work) is
expected behavior by design choice or does it need to be considered as bug ?
Looking into the netifd code devices are passed the interface config data only when the default_config flag is set which
is not the case for the vlan devices and thus common interface parameters cannot be overridden

Thx,
Hans
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list