luci-mod-network: Can't configure second GRE tunnel

[tiagogaspar8]

Steps to reproduce:

1. Create a GRE interface in Network → Interfaces named gre
2. Attempt to create a second GRE tunnel with a different name

Actual behavior:

Lucy throws an error in the device selector:

Expected behavior:

The GRE tunnel is created.

Additional Information:

OpenWrt version information from system /etc/openwrt_release

DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='11' #my versioning based on master
DISTRIB_REVISION='r26386-1188cae092'
DISTRIB_TARGET='ath79/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='OpenWrt 11 r26386-1188cae092'
DISTRIB_TAINTS='no-all'

If the tunnel is created directly in UCI it works and shows up in LuCI correctly

[systemcrash]

Is there an indication of what error is thrown in the debug console?

[tiagogaspar8]

I'm not seeing anything in the browser console logs, is there any way to turn on the debug mode? or should it show up in console logs?
Not used to this sorry

[systemcrash]

If anything it should appear in the console log.

Maybe some error is logged if the GUI flags a problem and marks it in red. I could not identify any cause in the GRE code, so perhaps the error arises from a different vector.

[tiagogaspar8]

I don't see anything here, am I looking in the wrong place?

[systemcrash]

In your picture, you're in the elements view. Try the console view next to it.

[tiagogaspar8]

here it is:

[systemcrash]

Worked fine for me.

[tiagogaspar8]

Weird, two of the same protocol type?

I was able to reproduce this in two devices 😕

Could I be doing something wrong?

[systemcrash]

Could not on my VM. what is the relevant GRE config?

[systemcrash]

I get these unsaved changes, and can make 2 GRE fine:

uci set network.gre1=interface
uci set network.gre1.proto='gre'
uci set network.gre1.peeraddr='asdf.com'
uci set network.gre2=interface
uci set network.gre2.proto='gre'
uci set network.gre2.peeraddr='qwer.com'

[tiagogaspar8]

What if you create one, apply and then try to create a second tunnel?

That's what I did.

[systemcrash]

I can make 50 tunnels in the same fashion (as you did). No problem.

[systemcrash]

Unless there's enough evidence to find a problem or we can localise a fault, I'm closing this, since you have a custom build going, and nobody else reports anything with GRE.

[jow-]

If you hover the red select box, is any error description shown in the red tooltip? Is the select box colored red after hitting any button or automatically? Does it turn white if you select another protocol?

[tiagogaspar8]

Ok, I nailed down on the issue after making a video that almost embarrassed me 😓
The issue arises when the first tunnel is created with the name gre.
When i hover over the tooltip it says the interface name is already used.

Magic.-.LuCI.-.Google.Chrome.2024-06-17.22-31-50.mp4

[systemcrash]

Video was corrupt. Were you attempting to show us the problem?

[tiagogaspar8]

I can see it in my phone and my laptop 😅
But yeah, basically, if you create the first tunnel with the name gre you won't be able to create the second one.

[dannil]

I took at look at this problem and the reason is at least simple; the protocol validate functionality reuses the name validate functionality, which means that if you create the first GRE tunnel with name gre, when creating the second one, uci.get('network', 'gre') will not return null, causing the red tooltip to appear for the protocol.

This affects every case where the name of the first interface collides with the protocol name of the second interface, I just tried DHCPv6 as an example.

@jow- is there a special reason why it reuses it one-to-one as implemented in e4bc192 or was it just for convenience sake? The protocol is a list value so I assume that we won't need the too long of an interface name either. This is a corner case of course, since you could just name the interface something else, but it's not obvious to the user what the actual issue is.

[systemcrash]

Seems to be for convenience. If you see a trivial fix, like anchoring on additional conditions, we're open to suggestions.