Question about conventions?

https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial

Naming: Devices are assigned a name like lan1 , lan2 , wan , wlan1 , vlan1 , etc. By convention, a bridge device gets a prefix of br- , like br-lan . Interfaces by convention, have upper-case names, such as LAN , WAN , WG1 , etc.

Do anyone know what specific convention this relates to? When I google these kind of conventions it seems that every university over the world and every major hardware manufacturer has their own naming convention agreed on by them self.


# ... in /etc/config/network
config device
	option name 'br-home'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'

config device
	option name 'office'
	option type 'bridge'
	list ports 'lan3'
	list ports 'lan4'

config interface 'home'
	option device 'br-home'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'

config interface 'office'
	option device 'office'
	option proto 'static'
	option ipaddr '192.168.13.1'
	option netmask '255.255.255.0'

We don’t even use these name conventions in the actual examples for different switch setups in the instruction.

I plead (semi) guilty here. Despite the fact that I don't have a deep understanding of DSA, I wrote the Terminology section as an attempt to distill notions from the mini-tutorial from the forum, the LuCI web GUI, etc. I also found a DSA "spec" on the wider internet that didn't seem to contain any definitions at all.

That's why I put the disclaimer on the page: This page is a Work In Process. It contains requests for information from future editors. If you can contribute your knowledge, we would be pleased for the help.

To address your specific question, it's my sense that those are OpenWrt conventions.

That said, I am completely prepared to stand aside if anyone who knows more than I wants to update the wiki page. Thanks.

2 Likes

OpenWrt's own, of course.

br-lan is what the LAN bridge is always called. Having "br" inside the name is usuallly a thing for Linux bridges.

also interface names are always shown as UPPERCASE in Luci even though they are not in the actual config files. pfSense and OPNSense also have interface names as UPPERCASE, btw

It's probably good enough to just write this is OpenWrt's convention, to avoid confusion and silly questions about The One True Convention that as you also noticed does not exist.

1 Like

This one is interesting and would be worth examining in a broader context of how this should be done...

In this thread, I was able to correctly guess that the WAN interface was entered as uppercase before even seeing the configuration. My hunch was confirmed, and when the OP changed it to lowercase, it fixed the issue.

So, here we have a bunch of things going on.

  • First, the conventions page says that interfaces are typically in CAPS. However, the default LAN and WAN interfaces are actually in lowercase. I don't know the history behind both the convention and the default case for the standard interfaces, but they don't seem to align (don't know how to rectify this).
  • Next, LuCI displays these interfaces in all CAPS which obfuscates the true case of the interfaces as handled in the UCI / config syntax.
  • The firewall zones, by default, are all lowercase. So you have the 'lan' interface in the 'lan' zone -- this is fine for those who know what is going on, but it might be hard to understand for newcomers. For example, is it okay to have a 'LAN' interface in the 'lan' zone or vice versa, or a 'LAN' zone with 'LAN' interface (of course, the answer is yes, functionally it will work just fine as long as the case-sensitivity is self-consistent)
  • Interestingly, LuCI does display case properly for firewall zones.
  • And finally, since the interfaces and firewall zone are indeed case sensitive, it might be hard for LuCI based users to see that there is a problem such as an uppercase 'WAN' interface such as in the thread I linked above.

I'm don't really have any specific answers about how to handle all of this stuff, but I think it is important to make sure that users understand that case sensitivity is a thing in OpenWrt, that the conventions are a suggestion but not a mandate, and that sometimes the conventions don't line up with the default conditions of OpenWrt.

1 Like

EDIT: The post I was replying to here was deleted by the author, but I think it is actually worth preserving it and my response since it could launch some good discussions... the sentiments was "what if LuCI enforced lowercase?"... and this was my response:

I'm not entirely sure...

  • I think it would make sense to patch LuCI to properly reflect the UCI configuration with respect to case in the network interface configuration.
  • UCI lets you use whatever case you want, so it would be possible to make a significant mess by enforcing lowercase in LuCI but not in UCI. Since LuCI fundamentally is a front-end and the backend of the service is literally just running commands with the normal CLI, it would make more sense for UCI to have the logic and casting to all lowercase, and that LuCI would simply respect what it finds in the config files.
  • But I'm not sure that it makes sense to force lowercase anyway -- there can be good reasons to use upper or mixed cases, even if it is not recommended. Also worth noting -- it's not like we are dealing with a style-guide and linting for a common/shared codebase -- if I use mixed or upper case in my configuration, it won't cause confusion or difficulty with anyone else's setup.
2 Likes

Yes I never understood why Luci has to show as upper or lowercase stuff that is perfectly fine in the UCI config, Maybe it's a legacy thing (it was important in the past and now it is not) or maybe a bug.

I agree that the most sensible thing would be for Luci to show the interface name without changing to upper/lower case, as that is probably how most users would expect it to work.

You might want to open an issue in the github repo https://github.com/openwrt/luci/issues

@jow are there reasons for this behaviour?

1 Like

Not really, it was an ill-made design decision back when implementing the interface overview. I just fear that it will look "odd" when we revert it to the real lowercase. But I am not opposed to change it.

3 Likes

Should I file the LuCI > network > interfaces text rendering ignoring the true case as a bug? And is it considered a bug? Technically it is working as intended, just simply a quirk of some UI design decision made sometime in the distant past. If not a bug, is it a feature request instead?