Stubby "option trigger" help

Installing and Using OpenWrt
1

Hello people,

was trying to understand the "option trigger" syntax in /etc/config/stubby since my need would be to get it work with 2 interface (one is wan and the other is called h3g).

I've tried to state the option 2 times

option trigger 'wan'
option trigger 'h3g'

or

option trigger 'wan h3g'

or to use comma

option trigger 'wan, h3g'

but it doesn't seem to work.. it only works if i state only one interface..

any of you aware of correct syntax or if the config can work with 2 interface?

many thanks

2 
option trigger 'wan wan1'

worked fine for me

3

@AndrewZ thank you for your feedback but it does not work as intended for me. to be more specific:

  • case 1:

option trigger 'wan'

router reboot, wan gets connectivity stubby gets triggered and starts, clients connect and have full working connectivity. all good.

  • case 2:

option trigger 'h3g'

i disconnect ethernet cable from wan for testing, router reboot, i manually ifup h3g and gets connectivity stubby gets triggered and starts, clients connect and have full working connectivity. all good.

  • case3:

option trigger 'wan h3g'

i disconnect ethernet cable from wan for testing, router reboot i manually ifup h3g and gets connectivity stubby does NOT trigger and does NOT start, clients connect and have limited connectivity, no dns obviously. no good.

--

i did other test but it seems that the config is ignoring multiple interfaces, even is no errors are reported for bad configuration file. so my guess is that it is not intended to be triggered by multiple interfaces.

please advice or correct me if i'm wrong.

many thanks

4

Hi.
In /etc/init.d/stubby replace

procd_add_interface_trigger "interface.*.up" "$trigger" "$stubby_init" start

by

       for trigger_item in $trigger
        do
            procd_add_interface_trigger "interface.*.up" "$trigger_item" "$stubby_init" start
        done
2 Likes
5

Should this be reported upstream? I'm interested in this as well for multi WAN interfaces.

Edit: Reported to package repo https://github.com/openwrt/packages/issues/15723

2 Likes
6

Did they make that changes?

7

Sorry, I originally created an issue about it but the previous maintainer is no longer interested in owning the stubby package in OpenWrt.

I have now submitted a PR with the original suggestion from @ddy64 here:

I have created one for the OpenWrt 21.02 branch and OpenWrt 19.07 as it's just a small modification to the init script. I've had running on my own router for a while, works fine.

1 Like
8

I used the snapshot version and saw these changes are live. However, mine is not working.

9

I don't think it is live, the init script was last changed over a year ago in master. This is the code in the master branch right now (as of writing):

And this is the change with the proposed PR linked above across all three branches.

The code isn't in master and therefore cannot be part of any snapshot build right now.

1 Like
10

This was merged into master now, next snapshot build should have the changes to the init script.

You can manually modify the init script though, for testing if you wish.

1 Like
11

I like the change, but not the implementation. Multiple values (space-separated) in an option seems like a throwback to ye olde ways. It's much more obvious to use a list of values:

list trigger 'wan'
list trigger 'h3g'
2 Likes
12

Yes, using a list would have been the correct fix. Am surprised @dibdot merged that.

13

Why not? Both ways are correct & supported. It's all about what you semantically prefer in your configuration file - this doesn't change a single bit in the implementation of the init script.

1 Like
14

Using different APIs can lead to inconsistent behavior, resulting in configuration corruption:
Inconsistent list handling in UCI and LUCI

In addition, the list offers an easier way to incrementally customize the configuration.

15

Not related, as stubby has no LuCI frontend - at least I think so (I don't use the stubby package).

16

Yes, stubby doesn't have any LuCI front end app as far as I know. If a LuCI companion app is developed in the future, then it is likely the init script needs revisiting. Although as highlighted by @dibdot, it would appear the original init script itself was copied from 18.06 anyway.

stubby doesn't have any active maintainer either now, so if anyone wants to add to my PR or improve on it, please do so! This was more of small fix to allow multi WAN trigger support.

1 Like
17

Indeed, it doesn't. UCI doesn't care about the format. Sorry for the noise.

1 Like
18

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.