Does dnsmasq-x.conf.add in jffs/configs/ still work if your VLAN has the same subnet as the Primary LAN?

[jksmurf]

As title really, does creating a dnsmasq-x.conf.add (where x is the VLAN Number in order of adding in GNP, not the VLAN ID) in jffs/configs/ still work if your VLAN has the same subnet as the Primary LAN or should you just use the WebGUI (YazDHCP or the Built-in One) for DHCP assignments. Mine seems to be completely ignored (but may not be working for other reasons, just trying to rule reasons out).

Thanks!

 

[dave14305]

If it’s used, you should see a syslog entry saying “Appending content of…” during dnsmasq restarts.

 

[jksmurf]

If it’s used, you should see a syslog entry saying “Appending content of…” during dnsmasq restarts.

I think that’s a no?. Guest is SDN 1 and IoT is 2. It’s picking up 1 only?

 

[dave14305]

I think that’s a no?. Guest is SDN 1 and IoT is 2. It’s picking up 1 only?

It would make sense to me if IoT is sharing the main network and therefore the main dnsmasq instance (dnsmasq.conf.add).

 

[bennor]

Guess I'll be the one to ask the question. If setting a manual IP address for Guest Network Pro Profile clients for which "Use same subnet as main network" is enabled (on); why bother using a separate dnsmasq-x.conf.add file to set the manual IP reservations? Why not just add the reservations to the main LAN DHCP Server section then save the list via the apparently already installed YazDHCP script?

One can likely quickly add via copy/paste those dnsmasq-x.conf.add manual IP reservations to a exported YazDHCP file, modify the IP addresses of the new clients to match the main LAN, then reimport that modified and updated YazDHCP file to add those manual reservations to the main LAN DHCP Server manual reservation list.

PS: Just did a quick and dirty test. Seeing the same. When the GNP profile is set to Use same subnet as main network, the firmware does not read the dnsmasq-x.conf.add for that GNP. In my case, it reads GNP IoT #1 (dnsmasq-1.conf.add) and 2 (dnsmasq-2.conf.add) both of which have Use same subnet as main network disabled, but doesn't read GNP #3's dnsmasq-3.conf.add which has Use same subnet as main network enabled. The client connected to GNP #3 does correctly pull it's manual IP reservation that was previously assigned to the LAN DHCP Server reservation list. Best guess is that the Asus-Merlin portion of the custom firmware is structured not to poll for dnsmasq-x.conf.add file and include when that specific GNP profile is using the main LAN DHCP Server range and any manual reservations on it.