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.