1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Shibby v107,v108 - BUG with dnsmasq v2.66test16

Discussion in 'Tomato Firmware' started by RDHLLC, Mar 26, 2013.

  1. RDHLLC

    RDHLLC Serious Server Member

    THIS POST WAS RETROACTIVELY EDITED TO SAVE YOU TIME:

    The "problem" as you will read later down this thread is that in v107 & v108 Shibby releases contain an update to dnsmasq (DNS & DHCP server for tomato) to version v2.66test16. This newer version of dnsmasq has some important bug-fixes for IPV6 but it also changed something that has broken Tomato.

    The issue has to do with using Tomato's custom configuration options for dnsmasq and the new issue of the in-ability to change certain default values created by Tomato. The specific case involves the need to specify an alternate DNS server for a VLAN interface. Dnsmasq's new version does not allow you to change an option value once it has been set higher up inside the dnsmasq.conf file. It did in older versions, but this new version does not. This breaks things and needs to be handled properly by Tomato. Plus, it has really come to light that Tomato never handled the .config file quite right, and dnsmasq basically has become less tolerant of it.

    Issue detailed below
     
  2. RDHLLC

    RDHLLC Serious Server Member

    Post removed
     
  3. koitsu

    koitsu Network Guru Member

    I can tell you right now that in Toastman's builds (specifically tomato-K26USB-1.28.0501.3MIPSR2Toastman-RT-N-Ext.trx), dnsmasq's custom configuration works fine, including dhcp-option. I know because I used it for a multitude of things.
     
  4. RDHLLC

    RDHLLC Serious Server Member

    In version shibby v107 dnsmasq was updated to 2.66TEST16, what version is Toastman running?
     
  5. Toastman

    Toastman Super Moderator Staff Member Member

    I didn't update yet, could be that's the reason.
     
  6. shibby20

    shibby20 Network Guru Member

    Have you enabled DHCP for br1 on Basic -> Network? IMO you do. Disable and it will works.
     
  7. RDHLLC

    RDHLLC Serious Server Member

    This post was retroactively edited to avoid you from reading a bunch of crap that doesn't matter. We get to the heart of the issue later on down the thread. Shibby's suggestion above was not the solution. The problem is in the way that the new dnsmasq is reading .conf files AND the way tomato is handling DNS assignments for interfaces in the GUI. Read on for more info.

    (I just saved you three minutes of your life ;) )
     
  8. kthaddock

    kthaddock Network Guru Member

    My config is like this and it works
     
  9. RDHLLC

    RDHLLC Serious Server Member

    retroactively edited.....
    again to save you time.
     
  10. kthaddock

    kthaddock Network Guru Member

     
  11. leandroong

    leandroong Addicted to LI Member

    I have experience errors with dnscrypt enabled when I try to install entware optware, problem downloading repositories. When disabled, all download went well.
     
  12. RDHLLC

    RDHLLC Serious Server Member

    Again, retroactively edited to save you time in your life ;)
     
  13. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    I did the 'port' of dnsmasq2.66test16. Simon Kelley (the maintainer of dnsmasq) regularly updates the code and is now very close to releasing 2.66 (currently on rc2) There is some custom code in the Tomato version of dnsmasq that needs to be maintained across releases (you'll know if it's included as it has 'tomato-helper' in the compile options at startup, and I've currently got 2.66rc2 running on my router here (shibby108 - eventually got it to compile, but that's a whole other story)

    The first thing to do is upgrade to 2.66rc2 as this issue may well have already been identified. The other thing to do is check that your custom dnsmasq configs are being merged in a sensible way with the default dnsmasq.conf... the combined file can be found at /tmp/etc/dnsmasq.conf, that is the file that's presented to dnsmasq for config purposes.

    edit: Oh and I should say that I've a load of custom options in my dnsmasq config that are being read and acted upon correctly (mostly related to IPv6)
     
  14. RDHLLC

    RDHLLC Serious Server Member

    Kevin, Thanks for the helpful informtion. I can confirm that the dnsmasq.conf file does contain the custom options entered by the web interface. I'm going to run some tests today; however, I did have a question. Shibby mentioned disabling the DHCP for the interface in the basic section of the web interface since I was going to enable it with custom options. I noticed that when I did this no-dhcp-interface=br1 was added to the config file. Of course later down the file, the custom options are set to enable it. But it brings up a good question and possibly the source of some of the problems. Does dnsmasq override options set at the top of the conf file with options set at the bottom? If not there is a problem. See if I leave DHCP enabled in the basic section of the web interface it populates the conf file with improper information which I then try to over-ride with the custom options; however, if I disable DHCP in the basic section, it adds that no dhcp option which prevents dhcp from running on that interface at all.

    This didn't seem to be a problem with the older verison of dnsmasq, but may be an issue with this newer one. Again, I'll have to run some tests today (I'm not onsite, so I have no way of testing dhcp remotely on that interface).
     
  15. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    I'm afraid I can't answer the 'which sticks...the first option instance or the last' off the top of my head. Would have to test it which I definitely can't do today - sorry.
     
  16. RDHLLC

    RDHLLC Serious Server Member

    Ok.

    BUG CONFIRMED

    Here is the deal.
    • The version update of dnsmasq to 2.66test16 changed the way that dnsmasq parses the dnsmasq.conf file. In the older version it allowed you to specify something at the top of the conf file and then over-ride that option by re-specifying it near the bottom of the file (custom config options by tomato places it at the bottom of the file). This change has broken the ability to make manual changes to dhcp options that already automatically get specified by the Basic->Network->Lan options.
    There are several easy fixes...and shibby would need to do only ONE of these:

    • If the user specifies NOT to use dhcp for an interface in the Basic->Network->Lan options, DO NOT place "no-dhcp-interface=br1" in the config file. Because once this is specified, you can't change any options for dhcp using custom configuration info later on in the .conf.
    • Change the placement of the custom config options to append to the TOP of the .conf file instead of the bottom. This would give the user the ability to override any setting by specifying it first using the custom config. Since apparently dnsmasq ignores settings that have already been set higher up (this would need to be tested)
    • Change the UI to show the entire dnsmasq.conf as it will be written according to the options chosen, and give the user a check box that says, over-ride dnsmasq.conf with the contents as show here in this text box.
    Again, guys, I worked on this for over an hour and if I manually edited the dnsmasq.conf file and removed the line no-dhcp-interface=br1 and ran dnsmasq manually it worked fine. Or if I enabled DHCP for the interface and manually edited the dnsmasq.conf and removed the auto generated conflicting configuration information at the top of the .conf file...again, worked fine. So there is a definite relation to configuration information in the dnsmasq.conf file generated by Tomato, and the order specifed. In older versions of Shibby (prior to v107) and consequently the older version of dnsmasq, this was not the case. In the older version the last specified value of an option was the one that stuck.

    Please ask me any questions about these procedures, but this is in my opinion now a confirmed bug and needs to be handled in a future release.
     
  17. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    I've had a very quick look at the code in router/rc/services.c which generates the dnsmasq config file. For dnsmasq to respond to dns queries on an interface it has to see a corresponding 'interface=intfn' line in the config. This enables both dns AND dhcp service for that interface. If you subsequently only want dns service then you have to add a 'no-dhcp-interface=intfn' to disable dhcp but you must have previously entered an 'interface=intfn' line to at least enable dns. This is exactly what tomato does when you disable dhcp service for an interface. It has to create an 'interface=intfn' line to enable dns, and it has to create a 'no-dhcp-interface' line 'cos you've told it you don't want dhcp. Thus 'solution 1' above won't work.

    Hmmmm. I'll check that rc2 hasn't fixed this is some way (should be easy enough) and if not hop on the dnsmasq mailing list and see what Simon thinks. My personal opinion would be something like 'well you should really be generating sensible config files that either disable or enable things once and not change them throughout the file' - that puts the problem back in Tomato's court. On the other hand I do think 'the last option should be the one that sticks'.

    Edit: Confirmed behaviour still in rc2 - ideally dnsmasq needs a method to clear the 'no-dhcp-interface' flag.
     
  18. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    I'm probably being really stupid here but why can you not enable DHCP for br1 with the range you require (10,0.0.0.20,10.0.0.254,255.255.255.0,1h) in the gui and then add the dhcp options to the custom config file as before:

    #Set the default gateway for the br1 clients
    dhcp-option=br1,3,10.0.0.1
    #Set DNS servers with google servers
    dhcp-option=br1,6,8.8.8.8,8.8.4.4
    I'm sure I'm missing something!
     
  19. RDHLLC

    RDHLLC Serious Server Member

    You are right in that some of the settings specified are redundant if you use the gui to enable DHCP...but (and this is what you are missing) DNS specification for enabled interfaces is done automatically by tomato and is not something you can change the setting of using the GUI when "use internal dns" is unchecked.

    Once DNS option is set it can not be changed later on down the .conf file (do to update of dnsmasq as outlined above..older version allowed over-rides later in the .conf file. So the main reason for the custom config I am loading is to change the "dhcp-option=br1,6. . ." (dns) option. The other stuff was just there to tell the whole story of the network layout to someone who was reading the thread.

    Note: the "use internal DNS" option is NOT checked. This is because the main interface (br0) is using a domain controllers DNS at 192.168.1.2. Tomato is guessing that that since DNS is to used for the br1 interface, and there is no where else to define a dns in the GUI, tomato assumes that you must want to use the primary dns addresses for br1 as well.... Well in this case that won't work as br1 is not to have access to the br0 lan's domain controller DNS. Thus I wanted to specify an alternate public DNS for the br1 interface (br1 is guest wireless so just general surfing is all this required).

    Tomato is automatically assigning the same DNS server for both interfaces when you click the enable DHCP setting in the GUI with "use internal network" unchecked. Both networks are being given the DNS address of 192.168.1.2. This probably didn't come up b/c most home users of tomato, use tomato router as the dns for all networks; however, this will not work in a windows domain enviornment where clients need to use the DNS & WINS of the domain controller as the primary DNS and WINS.

    EDITED POST KEVIN"S COMMENT TO CLARIFY WHAT I WAS TRYING TO SAY. I EDITED IT FOR THOSE READING THE THREAD LATER ON.
     
  20. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    Ok I understand now, and have also discovered that tomato only specifies dhcp option 6 if you're not using the internal dns on br0. It's an unusual set up. What about this as a work around...... create a br0 that goes nowhere and shuffle your existing br0 to br1 and so on. Then set use internal DNS which would force a dns address on br0 but not on br1 or br2 which you can then override in the config file. I know this is truly horrid!

    Also, now that I get the problem I'll clarify my request into Simon. What is really needed is a 'use the last instance of an option, not the first'.
     
  21. RDHLLC

    RDHLLC Serious Server Member

    Thanks...I love out of the box thinking....but yes that is truely horrid. The work around I currently have in place is a bash script that:
    Code:
    service dnsmasq stop
    cp /jffs/dnsmasq.conf /tmp/etc/dnsmasq.conf
    dnsmasq
    Also not cool because now 1) it's all hard coded which I hate and 2) jffs has to be maintained between firmware updates and 3) is not running as a service. I'm glad you understand the issue.

    I'm actually surprised this hasn't come up before b/c using Tomato in a small business where there is a Windows domain controller should't be that uncommon. Note: I tried using "use internal DNS" and having the primary dns of tomato point to the internal domain controller's DNS, but sadly this makes windows logon and logoff procedure of computers on the network domain take forever. Network operation on the LAN where active directory domain information was required was seriously effected performance wise. I just wanted to spell out the fact that I did try this...but please (other thread readers) don't get hung up on this topic, I don't want to thread hijack my own thread ;). Let's stick to the problem with dnsmasq and custom configuration options here.
    • Use the last instance of an option, not the first (required dnsmasq code change back to way it used to be)
    • Move custom configuration options to the TOP of the .conf file, making them the first (requires tomato mod)
    • Add the ability to specify DNS servers individually for each interface in the GUI (requires tomato mod)
    • Add the ability to see the .conf information in a text box, and over-ride it with a check box that says, "use this .conf information instead" (most flexible, for those that know what they are doing) (requires tomato mod)
    • Have tomato stop assuming that a network that enables DHCP and is set to not use the internal DNS wants to use the dns setup as primary for the first network, and thus allowing you to setup the DNS manually with a config option. (requires tomato mod)
    Any of the above would be an acceptable solution to this specific issue. But there are bound to be others not currently being discussed b/c of the problem created by how the newer version parses the .conf file (not allowing over-rides).
     
  22. koitsu

    koitsu Network Guru Member

    BTW, not to get off track, but I recommend folks consider using non-numeric DHCP options in their dhcp-option lines (ex. dhcp-option=br1,dns-server,xxx instead of dhcp-option=br1,6,...) -- it makes things a lot easier to understand and less error-prone. You can get a list of the option strings and their numerics via dnsmasq --help dhcp (per the docs).
     
  23. Monk E. Boy

    Monk E. Boy Network Guru Member

    On networks with Windows domain I've always elected to run DHCP and DNS on Windows servers, with DHCP & DNS completely disabled on the router.

    Active Directory is basically Microsoft fudgery added on top of LDAP and DNS. Putting a non-Microsoft DNS server into the mix is just asking for trouble, and if you're got a MS server running DNS, you may as well add on DHCP. There's some Active Directory integration that can be performed by the DHCP server when both are running on a domain controller, so it's done for a reason.

    It's not quite the Tomato norm, but you could elect to have a separate DNS/DHCP server on all your networks. Unless I missed something, it sounds like dnsmasq can still be completely disabled on all interfaces. Heck, you could use that server to run a http/https proxy for the guest network, which would likely be the best option (from a legal standpoint at least).

    Good detective work hunting down the cause... stuff like this always drives me batty until I figure it out...
     
  24. RDHLLC

    RDHLLC Serious Server Member

    Thanks and you are right. I want to stress to others that I really want to stay on topic on this thread and don't want to get off on the whole reasoning behind trying to use the dhcp custom options in the first place.

    You are exactly right though Monk. That's the reason that br0 needs to point all DNS to the Windows domain controller for a majority of the network. There is a need for a separate DHCP on the network to hand out IP's to wireless guests on interface br1. HOWEVER, br1 is completely cut off from the br0 network for security reasons so no PC can do that job from that side.

    Long story short. I know what needs to happen with tomato in a Windows domain environment; however, due to changes in Shibby v107, v108 and dnsmasq 2.66test16 it's not a possible combination right now as outlined above. This is most likely NOT the only issue that users will run into due to the inability to specify custom config options with dnsmasq 2.66test16 and tomato that need to override defaults, so the problem needs to be addressed.
     
  25. Monk E. Boy

    Monk E. Boy Network Guru Member

    Yeah, sorry, I realize this is most definitely a bug in dnsmasq, but thought it'd be nice to have some better explanation for why you shouldn't just enable DNS/DHCP in dnsmasq for br0. Login taking forever for clients is one symptom of DNS being munged from the standpoint of a Windows client logging into a Windows domain. I could explain in far more detail why that happens, but let's just leave it at that.
     
  26. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    I slightly object to the statement that 'this is definitely a bug in dnsmasq'. If you were presented with:
    'mythical_command optiona=A optiona=B optiona=C'
    or a config file that said

    optiona=A
    optiona=B
    optiona=C

    what would YOU decide 'optiona' should be set to? It's clear it should never be 'B' but should it be first that sticks or last that sticks and I can argue that both ways! That's exactly the dilemma dnsmasq is being presented with so actually the issue really comes down to generating sensible config files.

    I'm hoping to get a response from Simon the maintainer of dnsmasq soon for his comment on this. He would be quite correct to say 'generate sensible config files' and leave it at that but this is a 'backwards compatiblity' behaviour thing so who knows. You're not going to get a fix in 5 minutes.

    In the meantime there may be another workaround to RDHLLC's issue. You can specify a 'dhcp-optsfile=path' where you can place dhcp options. Now as these are re-read on a SIGHUP they're expected to be dynamic...and I'm wondering if this provides a way to override values - I'll have a quick test after I've typed this. EDIT- Doesn't work - damn, rats & blast!

    From a tomato point of view, I'd like to understand what is intended to happen by disabling 'use internal DNS' Was it to force using the statically defined DNS servers entered on the basic setup page or is it really 'stop using DNS' The way these options inter-relate between the global dnsmasq config page and the individual VLAN dhcp enable is not clear.
     
  27. jerrm

    jerrm Network Guru Member

    Considering the nature of many if not most of the devices that run dnsmasq, there is a definite need to be able to overwrite system generated options. The order of precedence doesn't really matter, but if historically it's been last option wins and that changes, then it is a bug, maybe just in the documentation, but still a bug.

    It doesn't mean anything, but I've always coded last option wins in the order system config file, user config file, folder config file, command line specified config file(s), and finally command line options. Not all steps are there for all programs, but the order is deliberate and consistent.
     
  28. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    Perhaps you want to have a look at the code then. I'm certainly no programmer, don't know how it all works and you're clearly more experienced than me.

    Perhaps the easiest solution is to back-out dnsmasq 2.66 and go back to 2.61. That breaks a few dhcpv6 things for me but then I don't think anyone else is using dnsmasq for IPv6 RA & DHCPv6 services.
     
  29. RDHLLC

    RDHLLC Serious Server Member

    My vote is to try and move forward and find a solution to the issue. I don't want tomato to have to be stuck in the past. I think that tomato should be updated to allow editing of the dnsmasq.conf file with GUI and checking a box that says "dnsmasq config override" and stores the value of that conf in nvram. This would allow an advanced user (like us) to specify the exact configuration of the .conf without concern for all of the eccentricities and workarounds.
     
  30. jerrm

    jerrm Network Guru Member

    He may well have a real need for the change, or it may just be a regression. It can be hard to tell what all the repercussions could be without taking time to really get your head around the code. Just glancing at the changelog, there are a couple of items that look like they could be a starting point. I have a another tomato pet project first, but of it doesn't get resolved, I may take a look - could be a while though.

    I don't think we should regress, just clarify what the behavior should be and determine the best course going forward.
     
  31. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    Ok, so I've tweaked services.c to pre-pend dnsmasq.custom to the dnsmasq.conf file and then generate all the usual config stuff. It works...or isn't obviously broken. I think this should be regarded as a workaround until either a) the author of dnsmasq clarifies which direction he will take and or b) the logic behind the dnsmasq config file generation with regard to dhcp options is clarified.

    I've taken a look at that generation logic and it has some oddities, here's the pseudo code of what I understand it to be:

    do_dns = dhcpd_dmdns : global use dnsmasq for dns=1 (true)

    for each bridge interface starting at 0->3
    if using dhcp for this interface then
    write interface=br[n]
    if NOT using dnsmasq for dns (do_dns=0) then
    if we don't know of any DNS servers (static or supplied by ISP) then
    set the lease time to 2m (!)
    Set do_dns=1 flag that we ARE using DNSmasq for the next loop interation(!) ie for interfaces br 1,2,3 - WHY?
    else we do have some dns servers defined so
    write dhcp-option=br[n],6,dns-servers
    fi
    write out dhcp-range etc parameters for br[n]
    write out dhcp-option 3 gateway for br[n]
    write out dhcp wins option for br[n]

    else not using dhcp for this interface then
    write interface=br[n] - assumes we want DNS and that it's provided by dnsmasq
    write no-dhcp-interface=br[n] - disable DHCP though
    end if
    next interface

    So, what *should* it be? I think that there should be a 'use dnsmasq dns' option per interface like the 'use dhcp' option. If 'use dnsmasq' is disabled then it doesn't even write an 'interface=br[n]' line into the config, ready for someone else to override this using the custom config.
     
  32. RDHLLC

    RDHLLC Serious Server Member

    I like the idea of having a toggle "use dns" added to the table as a short route to victory because then if you do need to do something strange you can toggle it to 'NO' and then interface=br[n] and no-dhcp-interface=br[n] would not be written to the dnsmasq.conf at all. THEN you could go into custom config and do it manually b/c there would be nothing conflicting and no pre-existing specifications for the interface at all.

    But as long as we are editing the GUI....why not do it the sexy way and just add a field that let's you specify the dns for each interface? You can always pre-populate it with the default DNS but now you have a mechanism to change the value without the need for custom configuration additions. So it can continue to behave as it has by automatically setting it to the primary DNS address for those that really don't understand this stuff, but for power users it gives them an option to edit the setting.

    Example of configuration above specified in purposed GUI change:
    Bridge------ STP ----------IPAddress --------Netmask ------------DNS ----------------**DHCP --------IP Range (first/last) ------Lease Time (mins)
    br0 -----------Disabled ---192.168.1.1 ------255.255.255.0 --192.168.1.1 ----Enabled ----192.168.1.2 - 199 -------1440
    br1 -----------Disabled -- 10.0.0.1 ------------255.255.255.0 --8.8.8.8,8.8.4.4 Enabled ----10.0.0.2 - 254 -------------1440

    **Note: To gain the extra room in the GUI you could even do away with the toggle field for DHCP, and instead put in 0.0.0.0 to disable either DNS or DHCP. This is shown in the table below.

    Either way you are changing tomato code so that
    1. Proper dnsmasq.conf files for this specific problem are actually generated correctly and that no over-ride race conditions (programming term for who set the option first/last) exists
    2. You have added flexibility to the system and the ability to completely turn off ANY dnsmasq config information for a specific interface, thus allowing you full access via the custom config option.
    Example of configuration where DNS and DHCP are disabled:
    Bridge------ STP ----------IPAddress --------Netmask ------------DNS ----------------IP Range (first/last) ------Lease Time (mins)
    br0 -----------Disabled ---192.168.1.1 ------255.255.255.0 --192.168.1.1 ----192.168.1.2 - 199 -------1440
    br1 -----------Disabled -- 10.0.0.1 ------------255.255.255.0 --0.0.0.0 ----------- 0.0.0.0 - 000 ---------------1440

    Either way is a win. BUT it requires changes to Tomato. (man I wish Shibby would chime in on this).
     
  33. jerrm

    jerrm Network Guru Member

    When you tested, is it consistent that NO options are replaced with later entries, or is it an issue with no-dhcp-interface=br[n] specifically not being "unset."

    In other words if I have:
    Code:
    dhcp-range=br1,10.0.0.20,10.0.0.254,255.255.255.0,1h
    dhcp-option=br1,6,8.8.8.8,8.8.4.4
    dhcp-range=br1,192.168.2.20,192.168.2.254,255.255.255.0,1h
    dhcp-option=br1,6,208.67.222.222 208.67.220.220
    Which one wins? Sorry, not where I can test today.
     
  34. RDHLLC

    RDHLLC Serious Server Member

    Answer: "No options".
    In your dnsmasq.conf example above...
    Code:
    dhcp-range=br1,10.0.0.20,10.0.0.254,255.255.255.0,1h
    dhcp-option=br1,6,8.8.8.8,8.8.4.4
    Would not be changed by the later definition of:
    Code:
    dhcp-range=br1,192.168.2.20,192.168.2.254,255.255.255.0,1h
    dhcp-option=br1,6,208.67.222.222,208.67.220.220
    in dnsmasq v2.66test16 as it would have in prior dnsmasq versions included with Shibby releases older than v107.

    So end result would be:
    Code:
    dhcp-range=br1,10.0.0.20,10.0.0.254,255.255.255.0,1h
    dhcp-option=br1,6,8.8.8.8,8.8.4.4
    Note: I only tested dhcp-option statements but I image it's the same for range statements too.
     
  35. jerrm

    jerrm Network Guru Member

    Thanks, just wanted to be sure it was a general issue and not specific to no-dhcp-interface=br[n].
     
  36. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    I also get the impression from Simon the author of dnsmasq, that once you've done 'no-dhcp-interface' on an interface then there's no way to subsequently re-enable it. That's another factor that says to me that the tomato gui should get it right in the first place rather than being overridden by custom tweaks.
     
  37. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    I like your second idea however a couple of implementation questions remain, and I also know which one I would prefer to attempt to implement if a more experienced developer doesn't turn up :)

    Questions that popped into my head (clearly whilst I was sleeping) are:

    0.0.0.0 in interface DNS field means 'don't use dnsmasq for this I/F' - also inherently means no dhcp service

    xxx.xxx.xxx.xxx,yyy.yyy.yyy.yyy,zzz.zzz.zzz.zzz means use supplied DNS server address/es for that I/F (managed by dnsmasq) also means DHCP must be enabled...otherwise who will find out?

    127.0.0.1 means use dnsmasq for that I/F and it will forward queries to either statically configured servers or those supplied by ISP's auto configuration. Again implies we must be doing dhcp for this interface otherwise who's to know! This would be the default config, but I'm not sure I like the idea of using 127.0.0.1 as the marker to use default behaviour. I think it's non-intuitive.

    And that's quite a bit of code to do all the validation, and I wonder if it's a sledgehammer to crack a nut. A per I/F 'use DNSmasq' flag is much easier to implement. Comments?
     
  38. RDHLLC

    RDHLLC Serious Server Member

    Proposal #1:
    It does get a bit tricky when I start to relate back the dnsmasq man pages about how the options are done but I think the following will work. I sumit the following as a potential road map to help guide us to a final destination of an elegant programmatic solution to this and other future dnsmasq configuration issues in Tomato.
    There are four possible configuration options for on/off:
    -DNS------- DHCP --------- DNSMASQ.CONF OPTIONS ADDED
    - -------- -------- -interface=br[n] & -no-dhcp-interface=br[n] (I think this is sloppy on dnsmasq's part)
    - -------- -------- (nothing added for interface br[n])
    - -------- ------- -interface=br[n] & -dhcp-option=br[n],6, ... & -dhcp-range=br[n], ...
    - -------- -------- -interface=br[n] & -dhcp-range=br[n], ... & (no -dhcp-option,br[n],6,... specified for the interface)

    This should cover all the possible combinations of enabling and disabling DNS and DHCP and work with the current version of Dnsmasq as it stands. However, for scenario four, Dnsmasq should not make any assumptions about DNS if the switch to set it is not in the .conf however, it currently does. So as dsnmasq stands in its current incarnation, option four will not work.
    To me 0.0.0.0 is logical for disabled, but 127.0.0.1 is not logical for default. I think that the default values should be pre-populated by Tomato (meaning whatever the current default values are should be put into the DNS Servers field). Regardless of scenario one and four above, the proposal I make below for Tomato's GUI should be valid. It will allow for all four scenarios above and has the ability to do custom options where needed.

    Here are some sample combinations in the spirit of the four scenarios above and how the GUI would handle them ( Default DNS = 192.168.1.1 ).
    br0 = Use default DNS but no DHCP (currently Dnsmasq will not allow custom DNS with no DHCP)
    br1 = Don't use either DNS or DHCP (nothing added to .conf)
    br2 = Use custom DNS and DHCP
    br3 = Don't use DNS but use DHCP **

    Example of configuration above specified in purposed GUI change:
    Bridge----- STP ----------IPAddress --------Netmask ----------Default DNS ---DNS Servers----------DHCP--------IP Range (first/last) -------Lease Time (mins)
    br0 -----------Disabled ---192.168.1.1 ------255.255.255.0 --Enabled --------192.168.1.1 -----------Disabled ----0.0.0.0 - 000 ----------------1440
    br1 -----------Disabled -- 10.0.0.1 ------------255.255.255.0 --Disabled --------0.0.0.0 -------------------Disabled ----0.0.0.0 - 000 ----------------1440
    br2 -----------Disabled -- 10.0.10.1 ----------255.255.255.0 --Disabled --------8.8.8.8,8.8.4.4 -------Enabled ----10.0.10.1 - 254 ------------1440
    br3 -----------Disabled -- 10.10.10.1 --------255.255.255.0 --Disabled --------0.0.0.0 -------------------Enabled ----10.10.10.1 - 254 ----------1440

    ** Note: Dnsmasq should not make any assumptions about DNS if the switch to set it is not in the .conf however, it currently does. So as dsnmasq stands in its current incarnation, option four will not work. The addition of this scenario in the GUI is to be a demonstration about how this could be accomplished using the new interface should Dnsmasq correct this issue in future releases. The only reason I can think of that someone would want to use DHCP and no DNS is if they wanted to create an interface where there was no DNS lookups on that network (would prevent web browsing, but an admin could still create host file entries or connect to workstations with IP addresses assigned by static leases). Granted this is rare setup, but when designing a UI it is important to consider all possible combinations that could occur and cover then with the flexibility of the purposed GUI.

    To use default DNS and DHCP it would look like this:
    Bridge----- STP ---------IPAddress ---------Netmask ----------Default DNS ---DNS Servers----------DHCP--------IP Range (first/last) -------Lease Time (mins)
    br0 -----------Disabled --192.168.1.1 -------255.255.255.0 --Enabled --------192.168.1.1 -----------Enabled ---192.168.1.2 - 254 ---------1440


    Another term for using default DNS could be "Global DNS" but I think "Default DNS" is more intuitive.
    I think this purposed solution would allow one to solve the custom DNS issue for any interface using the GUI and provide a means to specify ALL options for an interface by using only custom options. One would do this by disabling both DNS and DHCP and therefore no pre-exising configuration data for that interface would exist in the dnsmasq.conf file. This would effectively bypass the current race-condition and over-ride problem. Should some other scenario present itself in the future where a full custom options solution is the only way to accomplish the desired result, the problem would already be solved. Also this configuration would not break upgrades as by default it would set Default DNS enabled for all interfaces (which is the current value for all Tomato users right now anyway).

    All of this make since? I think that we are close here. We've certainly put the time in thinking about it.

    This posting took a lot of time to put together for the community, but I wanted it to be clean and easy to understand as I think it's a good step toward finalizing a fix for Tomato.
    (Show some love by clicking "Like" on the post over to the right --> )

    -David;)
     
  39. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    David,

    I like the post and appreciate the effort you've put into it, although at the moment I've only skimmed it due to work. Your suggestion is a radical change from how things are done at present. I've looked at the existing code behaviour and there are a couple of cases where it does some apparently odd things, namely where it's configured to not provide DNSMasq forwarded DNS service but pass on pre-configured/auto-provided servers from the ISP BUT they've not yet been obtained - it tweaks the lease time to 2 minutes and then presumably waits for 'magic to happen'. Bearing in mind the apparent chaos caused by a subtle change in dnsmasq's behaviour (though you're the only one to notice so far) the re-working of dnsmasq interface handling needs to be VERY carefully considered. I am particularly concerned about the 'providing dns servers when they've not yet arrived' scenario.

    There are other bugs in the dhcp config file; the tag descriptor syntax has been updated (though is backwards compatible) and I've fixed that. Also if using samba and 'use as a WINS server' is enabled then the code is supposed to provide the lan IP address for each interface as dhcp option 44 - currently it sets the address to 0.0.0.0 no matter what - I've fixed that too.

    I tried to add a simple flag 'use dmdns' to each interface in the gui, but my ASP programming skills don't exist & after 2 flashes of firmware managed to completely break the 'basic networking' page! My 'C' isn't that much better to be honest! This needs the attention of a developer who understands why the code in 'services.c' (which writes the config file) is written the way it is and can then deal with the gui & code changes.

    More when I have time but that's likely to be next week.

    Edit: Can you clarify exactly the config options for 'no DNS but DHCP is enabled' I don't see how to achieve this combination in the dnsmasq man page.

    Further edit: Suggest you get on the dnsmasq mailing list and ask Simon directly about how 'no-dhcp-interface' really works.
     
  40. RDHLLC

    RDHLLC Serious Server Member

    @Kevin

    I did go back and make some changes based on my testing results. Unfortunately Dnsmasq does make some assumptions it shouldn't. For example:
    • When DHCP is disabled using the -no-dhcp-interface=br[n] it appears as though Dnsmasq assumes the gateway is the DNS server. I tried to assign one with option 6, but couldn't verify that it worked.
    • Currently there is not a way to disable DNS on an interface without disabling ALL other services that Dnsmasq provides (TFTP, and DHCP). Many users have complained about this, and the offical answer so far is "run Dnsmasq's DNS service on a non-standard port using the -p command line switch". Nasty hack.
    I think that you might agree that the changes outlined in the proposed solution are not a "radical change" if we limit the scope to recreating the current functionality as outlined above with the addition of two GUI fields in the table, and the ability to specify custom DNS for option 6. All we are really doing is cleaning up Tomato's messy implementation of the dnsmasq.conf generation routines. As they are, they simply are not clean and do not conform to proper syntax.
     
  41. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    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.
     
  42. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    In the meantime I've gone back to the original problem and think there's a suitable short-term easy code fix. If the 'no-dhcp-interface' line is supressed then there's no harm done because we also do not define a dhcp range to serve anyway. So despite the fact we've no longer specifically excluded an interface from listening to dhcp requests, since we've nothing defined to serve on it anyway, things should be safe.
     
  43. RDHLLC

    RDHLLC Serious Server Member

    After giving it consideration. I agree with you. The most basic form of what is needed is simply, clean up the .conf file a bit so that conflicts don't occur and make it possible to specify what you really need in the custom config by removing all traces of .conf entries for a specific interface.

    The proposed solution was based what I consider to be the ideal solution to the problem; however, it is ambitious as it necessitates modification of the GUI and base binaries. I do want to point out that the Default DNS setting was simply to specify that it should behave as it does now. Not to change any code, only to make the results of that code visible by populating the table with the results. If Default DNS was enabled, then it would be the exact value it is now. The only change would be if you over-ride that and specified your own DNS, and if that value was 0.0.0.0 in conjunction with a disabled DHCP then remove all .conf entries. That's it,I thought that was pretty reasonable and would provide a GUI that was flexible enough to handle even more later down the road, but I can see how it may add more time to get results than what you propose. Anyway, let's proceed with the "shortest route to victory" approach. We have both spent enough time on this already ;)
     
  44. jerrm

    jerrm Network Guru Member

    Kevin - I see a fix for the dupe option problem in your tree. Assume you had something to do with getting this fixed. Thanks!
     
  45. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    Yes, but though it compiles I've not yet actually had a chance to test it. A firmware file is sat on my laptop waiting for me to return home & upload.

    But you may have have noticed one of the other commits which prevents 'no-dhcp-interface' being written out anyway, so in theory the problem you found has been 'fixed' twice :)
     
  46. jerrm

    jerrm Network Guru Member

    [quote="Kevin Darbyshire-Bryant, post: 225630, member: 45865]But you may have have noticed one of the other commits which prevents 'no-dhcp-interface' being written out anyway, so in theory the problem you found has been 'fixed' twice :)[/quote]

    The 'no-dhcp-interface' issue was RDHLLC's (and yes I saw both commits), but the general issue of manual entries overriding generated entries was just as important IMO. I do have some units where that is needed.
     
  47. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    Apologies for getting confused... I'm doing my 'day job' so I tend to lose focus on tomato conversations :)
     
    koitsu likes this.
  48. jerrm

    jerrm Network Guru Member

    None needed. Know how it is.
     

Share This Page