dnsmasq.conf.add not working on Guest Network Pro clients

[David Cavalli]

So maybe dnsmasq-x.conf.add really is for you... me... I'm very happy with my colours.

As it turns out, probably. However, had I understood the Yaz / amtm comment made in 2023, I wouldn't be so married to my own way of doing things. So much functionality in amtm, but steep learning curve if you don't know it exists / what you are looking for.

Always enjoy learning, so thanks again for all the new toys to investigate! <3

 

[David Cavalli]

You should be fine just restarting dnsmasq, over SSH:

service restart_dnsmasq

Ran the command. Got the "done". Same (current) numbering for the two "Bryan" devices online, not dnsmasq-4 ones. I'm assuming the "4" is correct, and it's just a matter of him signing out/in in order for it to achieve the new dnsmasq-4 IP allocation.

Thanks for the command!

 

[David Cavalli]

That value is an internal index. You need to match it with the corresponding network to know which is which - @dave14305 's command will do that.

Looked at the get_mtlan again, as I document it in my personal notes so future me won't forget. Upon second look, saw *two* potential "index" values. Here's an edited view of the output, with relevant sections:

|-name:[Guest]
|-createby:[WEB]
|-*Network:
  |--IPv4:
        |-idx:[4]
        |-ifname:[br57]
        |-dhcp_min:[192.168.55.1]
|-*SDN Feature Index/Switch:
        |-sdn_idx:[6]
        |-apg_idx:[6]

Initially, I assumed idx=4. Seeing the later output, I'm now considering that "SDN" might also be the right value, and idx=6 for my dnsmasq. Any input on the final answer would save me some reboot / restart testing. Thanks!

 

[rung]

Looked at the get_mtlan again, as I document it in my personal notes so future me won't forget. Upon second look, saw *two* potential "index" values. Here's an edited view of the output, with relevant sections:

|-name:[Guest]
|-createby:[WEB]
|-*Network:
  |--IPv4:
        |-idx:[4]
        |-ifname:[br57]
        |-dhcp_min:[192.168.55.1]
|-*SDN Feature Index/Switch:
        |-sdn_idx:[6]
        |-apg_idx:[6]

Initially, I assumed idx=4. Seeing the later output, I'm now considering that "SDN" might also be the right value, and idx=6 for my dnsmasq. Any input on the final answer would save me some reboot / restart testing. Thanks!

Interesting! Can you post the result of this command?

nvram get subnet_rl

Thanks!

 

[dave14305]

Seeing the later output, I'm now considering that "SDN" might also be the right value, and idx=6 for my dnsmasq. Any input on the final answer would save me some reboot / restart testing

Use 6. Also look at the different dnsmasq files in /etc.

asuswrt-merlin.ng/release/src/router/rc/sdn.c at e6461ffd11c64d4ad5a2c6ed0ade5cac21d964bf · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

 

[David Cavalli]

nvram get subnet_rl

nvram get subnet_rl
<3>br55>192.168.54.1>255.255.255.0>1>192.168.54.2>192.168.54.254>86400>>,>>0>>0>0>1>1000>2000>,,>0>1><4>br57>192.168.55.1>255.255.255.0>1>192.168.55.1>192.168.55.254>86400>>,>>0>>0>0>1>1000>2000>,,>0>1>

Looks like idx=4 after all.

 

[David Cavalli]

Use 6. Also look at the different dnsmasq files in /etc.

asuswrt-merlin.ng/release/src/router/rc/sdn.c at e6461ffd11c64d4ad5a2c6ed0ade5cac21d964bf · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

ls /etc/dns*
/etc/dnsmasq-6.conf /etc/dnsmasq.conf

But "6" makes a comeback...

 

[rung]

nvram get subnet_rl
<3>br55>192.168.54.1>255.255.255.0>1>192.168.54.2>192.168.54.254>86400>>,>>0>>0>0>1>1000>2000>,,>0>1><4>br57>192.168.55.1>255.255.255.0>1>192.168.55.1>192.168.55.254>86400>>,>>0>>0>0>1>1000>2000>,,>0>1>

Looks like idx=4 after all.

Apparently subnet_rl is not enough! Why has Asus made this so complicated?

Does anyone have a better way to script this info from nvram variables?

 

[rung]

nvram get subnet_rl
<3>br55>192.168.54.1>255.255.255.0>1>192.168.54.2>192.168.54.254>86400>>,>>0>>0>0>1>1000>2000>,,>0>1><4>br57>192.168.55.1>255.255.255.0>1>192.168.55.1>192.168.55.254>86400>>,>>0>>0>0>1>1000>2000>,,>0>1>

Looks like idx=4 after all.

Sorry for this. Can you show this:

nvram get vlan_rl

 

[David Cavalli]

Can you show this:

nvram get vlan_rl

nvram get vlan_rl
<3>52>0><4>53>0>

 

[jksmurf]

So maybe dnsmasq-x.conf.add really is for you...

Goodness me, after seeing all this gafuffle trying to find the correct SDN index you must be revelling in the inner workings of dnsmasq for GNP.

I wonder how @Martinski determines this in YazDHCP…

 

[David Cavalli]

Goodness me, after seeing all this gafuffle trying to find the correct SDN index you must be revelling in the inner workings of dnsmasq for GNP.

I wonder how @Martinski determines this in YazDHCP…

No kerfuffle. I'm 99.99% sure it's "6". I think @rung is just trying to find a way to achieve this return value in his nvram. (Happy to keep givng return values, rung!) My guess is that I deleted a Guest account or two at some point. The *active* list has it at "4", but the persistent list has it at "6". I'm sure YazDHCP knows to use the SDN Feature Index to get this.

 

[jksmurf]

No kerfuffle.

lol, oops, my phonetic spelling … I’m laughing at myself …

I'm 99.99% sure it's "6". I think @rung is just trying to find a way to achieve this return value in his nvram. (Happy to keep givng return values, rung!) My guess is that I deleted a Guest account or two at some point. The *active* list has it at "4", but the persistent list has it at "6". I'm sure YazDHCP knows to use the SDN Feature Index to get this.

No worries, actually it will ultimately help the wider community, at least those who prefer the dnsmasq-x.conf.add approach, so all good stuff.

 

[rung]

nvram get vlan_rl
<3>52>0><4>53>0>

This is hilarious. So where, oh, where would one find that mysterious <6> value in nvram?

Maybe let's try:

nvram show | grep "<6>"

 

[David Cavalli]

nvram show | grep "<6>"

nvram show | grep "<6>"
size: 102466 bytes (94142 left)
sdn_rl=<0>DEFAULT>1>0>0>0>0>0>0>0>0>0>0>0>0>0>0>0>0>WEB>0>0<4>Guest>0>3>3>4>0>0> 0>0>0>0>0>0>0>0>0>0>0>WEB>0>0>0<5>IoT>1>0>0>5>0>0>0>0>0>0>0>0>0>0>0>0>0>WEB>0>0> 0<6>Guest>1>4>4>6>0>0>0>0>0>0>0>0>0>0>0>0>0>WEB>0>0>0

 

[rung]

nvram show | grep "<6>"
size: 102466 bytes (94142 left)
sdn_rl=<0>DEFAULT>1>0>0>0>0>0>0>0>0>0>0>0>0>0>0>0>0>WEB>0>0<4>Guest>0>3>3>4>0>0> 0>0>0>0>0>0>0>0>0>0>0>WEB>0>0>0<5>IoT>1>0>0>5>0>0>0>0>0>0>0>0>0>0>0>0>0>WEB>0>0> 0<6>Guest>1>4>4>6>0>0>0>0>0>0>0>0>0>0>0>0>0>WEB>0>0>0

That's where it lives. Thanks!

 

[RMerlin]

Apparently subnet_rl is not enough! Why has Asus made this so complicated?

Because it was never intended to be used by end-users. This is for their own internal use. The new Network implementation has to be flexible enough to handle any kind of variation: main, guest, VLAN, not VLAN, etc...

VLANs are defined separately from networks. You need some way to associate a network with a VLAN configuration, hence the use of indexes in separate lists.

 

[David Cavalli]

You should be fine just restarting dnsmasq, over SSH:

service restart_dnsmasq

The Switch has updated the Name and IP field. The dnsmasq-6.conf.add is working! (The phone will likely update when he logs out/in or router reboot.)

Thanks everyone in the community for helping me achieve this and learning some new things!

 

[jksmurf]

That's where it lives. Thanks!

Hi @rung, so for future reference would it be correct to say that the (*easier) command to determine sdn number 'x' for the purposes of defining dnsmasq-x.conf.add is: ?

nvram get sdn_rl

Which on my system shows this:

ASUSWRT-Merlin RT-AX88U_PRO 3006.102.6_beta1 Wed Nov 12 02:11:26 UTC 2025
xxxxxxx@RT-AX88U-Pro:/tmp/home/root# nvram get sdn_rl
<0>DEFAULT>1>0>0>0>0>0>0>0>0>0>0>0>0>0>0>0>0>WEB>0>0>0<1>Guest>1>1>1>1>0>0>0>0>0 >0>0>0>0>0>0>0>0>WEB>0>0>0<2>IoT>1>2>2>2>0>0>0>0>0>0>0>0>0>0>0>0>0>WEB>0>0>0

and the first sdn number (of your GNP Networks) is not before DEFAULT, but rather the network AFTER each instance of ">WEB>", which for me would be

<1>Guest>
<2>IoT>

and for @David Cavalli would be:

<4>Guest>
<5>IoT>
<6>Guest>

Whilst not the name folks actually give their network, I guess the identification of the network is generally assisted by the order in which they show in GNP, so here @David Cavalli seems to have (remaining, after adding and deleting some as evidenced by 4/5/6 and not by 1/2/3) a Guest Network then an IoT one, then another Guest one. It would be interesting to know what names would be given to Guest Portal <GP?>, Kids Network <Kids?>, VPN Network <VPN?> and Custom Network <Custom?>. I am sure that will eventually turn up but in theory should only ever be 1 of 6 Types.

* everyone has a preference, but having seen both, nvram get sdn_rl is certainly 'easier' for me to identify the SDN no. "x", as whilst get_mtlan suggested above also shows the -sdn_idx: (x) under a tree format headed by the SDN -name: it just seems a bit agricultural in comparison...

[NOTE] I like nvram get subnet_rl for checking the brxx though (although brctl show will give you similar details as these brxx values are needed (in the correct number format) to be able make IPTables work correctly.

 

[rung]

Yes, it appears to get all the info, one must look at multiple variables. For @David Cavalli, we have the following info from the first couple of fields of each:

sdn_rl:
0:DEFAULT,1,0
4:Guest,0,3
5:IoT,1,0
6:Guest,1,4

subnet_rl:
3:br55,192.168.54.1,255.255.255.0,1,192.168.54.2
4:br57,192.168.55.1,255.255.255.0,1,192.168.55.1

So from the first variable we find an idx to look into the subnet list to find the bridge name, etc.

Strange though, it looks like the dhcp min for br57 starts at 192.168.55.1 and not 2?