[OpenWrt-Devel] Netifd: are the protocol-based prefixes still needed for interface names?

Hannu Nyman hannu.nyman at iki.fi
Fri Nov 6 08:58:01 EST 2015

Netifd (or the protocol defintions) add a prefix like "br-", "6in4-", 
"pppoe-" etc. to names of interfaces with selected protocols and bridge 
interfaces. Example: 6in4-tunnel interface "sixxs" gets created in the system 
as "6in4-sixxs".

That long name is shown e.g. by 'ifconfig' and used by dnsmasq and firewall etc.

To my knowledge, there are at least these prefixes:
br-, 6in4-, 6to4-, 6rd-, ds-, map-, pppoe-, pppoa-

Is that prefix really needed today, or is that just a leftover from 
pre-netifd times?

The question arose in connection with Luci and limiting firewall zone & 
interface name lengths.
Reference to:

There is apparently a 15 character limit to the "real" interface name, 
enforced both in the firewall and dnsmasq. The real interface name
includes the possible prefix "br-", "6in4-" etc. Example of an error:
   interface name `br-lan_protected' must be shorter than IFNAMSIZ (15)

Afaik, the limit is coming from Linux itself:
    #define IFNAMSIZ 16

The 15-characrater hard limit combined to a possibly 6-character long prefix 
(like "pppoe-") restricts in practice the interface name allowed to the user 
to only 9 characters if that name should work with any protocol. Verifying 
the allowed length (e.g. in Luci GUI) gets unnecessarily difficult, if the 
protocol causes this kind of huge impact. The easy approach would be to 
restrict the name to the "guaranteed to work with any protocol" length, = 9 

I question if that prefix is really needed and used for something?
Or could we drop that practice and just leave the interface names to those 
that the user has configured?
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list