But the current functionality is not being completely re-created. In the current GUI, if 'use internal DNS' is disabled then instead of the local (to that dhcp range) interface being passed as the dns server option in DHCP, then either any statically defined DNS servers are passed as option 6 (which your changes do cope with) *OR* the currently supplied DNS servers from the ISP (presumably provided by dhcpc) are. If there are no currently defined dns servers ('cos the WAN link is still being brought up say) then the lease time is reduced to 2 minutes (presumably in the hope that the WAN link will be up soon) and the DNS servers are then passed on.
Exactly how this code is 'kicked' such that it knows the WAN is up is something I definitely do not understand. And it's something that shouldn't be changed without full understanding of the existing code behaviour which I and you do not have.
Also, your BR3 example is something by your own statement that cannot realistically be configured. I have to agree with Simon here in that the program *is* called *DNS*masq not dhcpmasq or dhcpdnstftpmultimegaloadsofoptionsserver (you've read the man page like me, I think it has enough bl**dy options already!)
Until all the implications are understood, I still subscribe to a per interface flag that in essence says 'use existing behaviour' or 'don't even think about touching the config file for this interface' - that will not break anything and is much easier to implement. Yes it's not as sexy but it'll work.
If the plan is to really go for it on this, then there's at least one other parameter that should be configurable per interface and that's the WINS server - 3 states 'disabled', 'statically defined', 'use internal SAMBA server' (which will change according to which interface we're talking about) And then there's IPv6 which I really don't want to get into!
The VLAN code is/was an add on - Toastman still considers it experimental - I think this is probably just one example of why it should still be considered so. Yes it can and should be fixed.....by someone who understands and can write code and also understands networking.
Exactly how this code is 'kicked' such that it knows the WAN is up is something I definitely do not understand. And it's something that shouldn't be changed without full understanding of the existing code behaviour which I and you do not have.
Also, your BR3 example is something by your own statement that cannot realistically be configured. I have to agree with Simon here in that the program *is* called *DNS*masq not dhcpmasq or dhcpdnstftpmultimegaloadsofoptionsserver (you've read the man page like me, I think it has enough bl**dy options already!)
Until all the implications are understood, I still subscribe to a per interface flag that in essence says 'use existing behaviour' or 'don't even think about touching the config file for this interface' - that will not break anything and is much easier to implement. Yes it's not as sexy but it'll work.
If the plan is to really go for it on this, then there's at least one other parameter that should be configurable per interface and that's the WINS server - 3 states 'disabled', 'statically defined', 'use internal SAMBA server' (which will change according to which interface we're talking about) And then there's IPv6 which I really don't want to get into!
The VLAN code is/was an add on - Toastman still considers it experimental - I think this is probably just one example of why it should still be considered so. Yes it can and should be fixed.....by someone who understands and can write code and also understands networking.
