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.

https://github.com/openwrt/luci/assets/39808643/99680faf-c95b-4e2f-a70e-e85393d171a7

[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 e4bc192012b05078eb7675e42908e0dd9d04ee88 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.

[dannil]

I think I realized why it's probably set up that way, since if you enter an protocol + interface name combo which ends up less than the 15 character limit, and you then change the protocol, the resulting protocol + interface name combo needs to be validated again, and that includes the length of the interface name since it now could exceed those 15 characters... but I'll try and think of a solution.

[systemcrash]

Ah, of course. Like wireguard_wg0. Doesn't leave us with much space. I think the 15 characters isn't a total length limit tho. I have some configs which are 24 characters long with e.g. wireguard_blah_blah_blah.

[tiagogaspar8]

If you need me to test a fix let me know!

[dannil]

If you need me to test a fix let me know!

@tiagogaspar8 If you're equipped to compile your own build from source, you could cherry-pick https://github.com/dannil/luci/commit/0fa2271e86d7f7e15a883bdc04ff1857332e19cd and see how it behaves, I need to properly test if there's any regression cases but it looks promising.

[systemcrash]

Or go to that commit and replace your on-device interfaces.js with that interfaces.js. Clear browser cache and retry.

[tiagogaspar8]

Hi @dannil , sorry I haven't been able to test yet, I will test it this week, as soon as I can I'll give some feedback, thanks for the awesome work!

[tiagogaspar8]

Hi @dannil, This seems to fix my issue, I changed the file on my router (so not a complete build), and I could add the second GRE interface as I tried in the video. Great work! 😄

[dannil]

Hi @dannil, This seems to fix my issue, I changed the file on my router (so not a complete build), and I could add the second GRE interface as I tried in the video. Great work! 😄

Awesome, I've created #7306 to bring it into the code base.