Linux kernel interface max length

Installing and Using OpenWrt Network and Wireless Configuration
1

According to OpenWrt documentation here and here, Linux kernel interface name is limited to 15 characters.

I have a bridge namely br-switch0, and I create some bridge-vlan on it.

# this works
config bridge-vlan
	option device 'br-switch0'
	option vlan '999'
	list ports 'lan1:t'
	list ports 'lan2:t'

config interface 'pub_wifi'
	option device 'br-switch0.999'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '64'

# but this doesn't
config bridge-vlan
	option device 'br-switch0'
	option vlan '1000'
	list ports 'lan1:t'
	list ports 'lan2:t'

config interface 'lan'
	option device 'br-switch0.1000'
	option proto 'static'
	option ipaddr '192.168.2.1'
	option netmask '255.255.255.0'
	option ip6assign '64'

It is 15 characters. Why does it not work?

root@OpenWrt:~# echo -n "br-switch0.1000" | wc -c
15
[SOLVED] GRE tunnels not working in 23.05.0-rc#
2

Iirc for other limitations is it actually 12 char. Various sources indicate that. Serval Years ago I stumbled upon this too and tried personally to stick with 7 or 8 char to have some room...

3

Hi

i think it is wrong
it should be
option device 'switch0.1000'
without br-

4

The syntax was correct, because I had defined the bridge as follow:

config device
	option name 'br-switch0'
	option type 'bridge'
	list ports 'wan'
	list ports 'lan1'
	list ports 'lan2'

When I find and replace all br-switch0 with br-sw0, all interfaces work.

I was careful when I counted the interface length. Unfortunately it did not work as expected, and I had quite a lot of headache isolating the problem.

5

hmmm ?

but then ...

but this doesn't

config bridge-vlan
option device 'br-lan'

br-switch0 on one place, br-lan on other ?

6

It was a typo. I did not copy paste my real configurations -- it is quite complex and beyond the purpose of the question. For now we should focus on the problem: interfaces with length of 15 characters are not created by the kernel.

7

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704072#22

1 Like
8

This generally is only a good idea if the toy configuration was also tested... this kind of typo in artificially "reduced" configs is not all that uncommon...

1 Like
9

So, you can easily test it to determine the actual max length and update the documentation.

10

He already did, 14 characters work, 15 fails... his question is why?
Last time I ran into this issue I also came away thinking the limit is 15, not sure how well I tested that at the time.

11

Because the referenced documentation is inaccurate.
Perhaps it has never been accurate and only mentioned theoretical limitations without thorough practical testing and considering caveats like EOL and netifd implementation specifics, or maybe it is no longer accurate due to DSA migration.

12

Which OpenWrt version? netifd had a fix after 22.03.

1 Like
13

Coming back to some non-trivial configuration after several years, it seems as though the DSA transition may have caused the limitations on and choice of interface names in OpenWrt to become annoyingly draconian.

Where previously there was 15 characters to work with, now I find that things like GRE interface names can only be two characters long before apparently running afoul of the character limitation. Naming the interface ab seems to be as long as you can go to not have gre4t-ab.1234 exceed the limit.

14

What about setting option name foo manually to avoid auto name assignment issues?

15

A reasonable idea, but it seems the name is hard-wired in the proto handler

proto_gretap_setup() {
	local cfg="$1"

	local network
	json_get_vars network

	gre_setup $cfg "gretapip"

	json_init
	json_add_string name "gre4t-$cfg"
	json_add_boolean link-ext 0
	json_close_object

	for i in $network; do
	    logger -t gre.sh "$i: add_device $(json_dump)"
		ubus call network.interface."$i" add_device "$(json_dump)"
	done
}

if I want to stay with something reasonably close to the stock codebase, it looks like I'm stuck with what seems to be a naming decision that made some sense back in the White Russian days but has not aged well.

(The logger line is trying to debug another problem related to bridging causing the parent interface to be non-existent on the system.)

1 Like