[OpenWrt-Devel] Netifd: are the protocol-based prefixes still needed for interface names?
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
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
The question arose in connection with Luci and limiting firewall zone &
interface name lengths.
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