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

Explanations welcome on a solved static dhcp conflict problem

Discussion in 'Tomato Firmware' started by hpsmartyz, Jul 7, 2012.

  1. hpsmartyz

    hpsmartyz LI Guru Member


    I have encountered a problem, which I "solved" and I would appreciate your enlightenments on this.
    I have 2 routers at home.
    a WRT320N, connected to the internet
    it has DHCP server activated, with a range of 13 clients 100-112
    wireless enabled (N only)
    the MACs of the 13 clients are all in the the static DHCP table
    it has max 5 wireless clients, the MACs of which are in the wireless filter table

    a WRT54GL
    one of its switched ports is cabled to one of the switched ports of the 320N
    it has the DHCP server dis-activated
    wireless enabled (G only) with an SSID different from the WRT320N
    knowing that this used to be my only router it still has entries in its static DHCP table. This is the point that concerns my question.

    The 54GL sDHCP table is exactly the same than of the 320N's except that it has a 14th entry (a device not anymore on my network).
    Today, I configured the 320N for a 14th device. I extended the DHCP range by one (100-113) and added the MAC of the new client in the static DHCP table giving it the x.x.x.113 address. But the client never managed to get an IP.

    I finally managed to have the client get an IP address and the configuration I now have is the following:
    range of 15 clients on the 320N (100-114), 14 entries in the 320N Static DHCP table with the x.x.x.113 assigned to the new client, *and* 15 entries in the static DHCP table of the 54GL with x.x.x.114 assigned to the new client.
    And the client gets x.x.x.114 for an IP address.

    If you still; follow me, I'd like to understand the conflict that seem to have happen between the two router each having different devices/MACs assigned to the same IP:x.x.x.x.113 in their static DHCP table.
    I can of course change the configuration on the 54GL and at least remove from the static dhcp table the 113 entry but I would really want to understand the underlying issue.
    Also if you want to tell me at the same time that my overall configuration is fundamentally wrong I'll welcome your advices as well on that.

    Thank you
  2. koitsu

    koitsu Network Guru Member

    There's conflicting information in your explanation of the situation; for example, you state the DHCP server is "dis-activated" on the WRT54GL, yet you then talk about how you have static DHCP entries in it. As such, I'm going to assume the DHCP server on your WRT54GL is actually enabled (otherwise static DHCP entries in the WRT54GL would do absolutely nothing).

    So to make this simple, here's the deal:

    You can only have one DHCP server on your network. Period. No ifs/ands/buts about it. Make sure only one of the two routers has its DHCP server enabled.

    Failure to ensure that there is only one active DHCP server on your network means that there will always be some degree of "DHCP chaos" that happens on your network; some clients will talk to the DHCP server on the WRT54GL, others will end up talking to the 320N. There is no way to guarantee which router a client talks to; this has to do with the nature of how broadcast addresses work and how BOOTP/DHCP works as a protocol. So again: one DHCP server on your network only.

    Furthermore, IP addresses allocated as static (via static DHCP) need to be outside the dynamic allocation range. It's possible that the DHCP server on TomatoUSB allows them to be within the range, but that violates DHCP RFCs. DHCP servers like isc-dhcpd are strictly compliant and will actually reject dhcpd.conf entries where a static IP allocation falls within the dynamic IP range.

    So in English:

    DHCP server range: to
    Static DHCP entry: 00:01:02:03:04:05 -->
    Static DHCP entry: ff:ee:dd:cc:bb:aa -->
    Client not in the static DHCP table will get an IP between and
    DHCP server range: to
    Static DHCP entry: 00:01:02:03:04:05 -->
    Static DHCP entry: ff:ee:dd:cc:bb:aa -->
    Client not in the static DHCP table will get an IP between and
  3. hpsmartyz

    hpsmartyz LI Guru Member


    many thanks for your feedbacks.
    I do *confirm* that DHCP server is dis-activated on the WRT54GL and that I do have static DHCP entries.
    As far as I can see, under tomato, disabling the DHCP server does not disable the static DHCP table.

    I agree on your point of having only one DHCP server on the network and this is why I had disabled the one of the 54GL (even if I did not remove the static DHCP entries).
    But it sort of looks like the static DHCP entries still "work" even if the DHCP server is disabled, and I kind of remember that I read something around this point here but could not bet on that.

    Thanks for your point on the compliance to RFC. What if I only want static DHCP allocation? I can not define a null range and based on the behaviour we are discussing I would tend to say that I could also disable the DHCP server on the 320N also ...
  4. BikeHelmet

    BikeHelmet Networkin' Nut Member

    Interesting. Most of the Modem/Router combo units provided by ISPs in Canada require static IPs to be within the DHCP range. I've always kept them out when working with Tomato routers, because it felt cleaner. Yet another thing that reaffirms my belief that those ISP combo units are crap.
  5. koitsu

    koitsu Network Guru Member

    Alright let's explain this a bit better, and this is going to get even more technical.

    First off: Tomato/TomatoUSB uses a daemon called dnsmasq which handles two things: 1) acts as a DNS proxy (LAN machines talk to for DNS lookups, which then siphons them off to whatever DNS servers got negotiated via DHCP with the ISP), and 2) acts as a DHCP server for the LAN. Do not confuse this with the DHCP client that talks to one's ISP across the WAN. That is a separate daemon called udhcpc.

    Back to dnsmasq. This daemon, in my opinion, does too much shit within a single daemon. Thus this makes troubleshooting/debugging this exact situation a real pain in the ass. Having separate daemons (one for DNS proxying, one for DHCP server) is really the proper way to do this under a UNIX OS.

    Looking through the dnsmasq docs, the option called --no-dhcp-interface supposedly disables DHCP functionality on a specific interface (meaning it shouldn't bind to port 67). This would be the no-dhcp-interface option in /etc/dnsmasq.conf.

    So the question then becomes what actually changes when DHCP server is disabled in the TomatoUSB GUI. So let's try to figure this out. Hopefully I can do this without screwing up all my existing network connections.

    Below is from my TomatoUSB router (and some configuration customisations are specific to my own stuff, so they will differ from everyone elses; too bad :) ), with the DHCP server functionality enabled. I'm looking at the dnsmasq process (for what flags it uses), its configuration file, and what its bound to network-wise:

    root@gw:/tmp/home/root# ps | grep dnsmasq
      829 nobody    1156 S    dnsmasq -c 1500 --log-async
    root@gw:/tmp/home/root# cat /etc/dnsmasq.conf
    root@gw:/tmp/home/root# netstat -nl | grep ':67'
    udp        0      0    *
    The netstat output indicates its bound to INADDR_ANY.

    So now let's toggle the DHCP server functionality in the GUI. Boy I hope this doesn't break all my existing TCP connections... and of course clicking "Save" causes all sorts of non-DHCP-related crap to go on so the router deadlocks for a little while. Christ I hate these things sometimes.

    Okay, server is off. Let's see what changed:

    root@gw:/tmp/home/root# ps | grep dnsmasq
    2929 nobody    1100 S    dnsmasq -c 1500 --log-async
    root@gw:/tmp/home/root# cat /etc/dnsmasq.conf
    root@gw:/tmp/home/root# netstat -nl | grep ':67'
    So here's what changed, and this is fact:

    1. dnsmasq.conf is modified to use the option no-dhcp-interface=br0. The br0 interface is the LAN interface.
    2. dnsmasq.conf is modified to remove the dhcp-range options.
    3. dnsmasq, because of the above two changes, is no longer listening on port 67, thus IT CANNOT be answering DHCP requests EVER.

    So those are the facts. Thus, your next claim:

    ...cannot be true. OR you're running a TomatoUSB firmware version that has a bug where DHCP isn't truly disabled (and may have since been fixed). I am running on an Asus RT-N16, using TomatoUSB Toastman RT-N build 1.28.0499.3. The specific build file I use:


    This is currently not supported in TomatoUSB from what I can tell. dnsmasq does support this functionality though. Taken from the documentation:

    -F, --dhcp-range=[interface:<interface>,][tag:<tag>[,tag:<tag>],][set:<tag],]<start-addr>[,<end-addr>][,<mode>][,<netmask>[,<broadcast>]][,<lease time>]
    -F, --dhcp-range=[interface:<interface>,][tag:<tag>[,tag:<tag>],][set:<tag],]<start-IPv6addr>[,<end-IPv6addr>][,<mode>][,<prefix-len>][,<lease time>]
    The optional <mode> keyword may be static which tells dnsmasq to enable DHCP for the network specified, but not to dynamically allocate IP addresses: only hosts which have static addresses given via dhcp-host or from /etc/ethers will be served.​

    This would have to be added as a feature. You could modify /etc/dnsmasq.conf yourself and restart the dnsmasq daemon to get what you want, but you would have to do this *every time* you reboot the router, or whenever the WAN connection goes up/down.

    So in English: as of this writing, there is no way to get only static DHCP allocation.
    Mercjoe likes this.
  6. koitsu

    koitsu Network Guru Member

    Doesn't surprise me. Here's the ISC dhcpd.conf man page. The section you'd want to refer to/read is called REFERENCE: DECLARATIONS.

    This topic comes up on the ISC mailing lists fairly often. Here's an example, where a user "believe static allocations can be within the dynamic range", followed by administrators stating why this is bad:

    https://lists.isc.org/pipermail/dhcp-users/2008-May/006369.html <-- definitely read

    Some more proof:

    http://osdir.com/ml/network.dhcp.isc.dhcp-server/2003-01/msg00159.html <-- definitely read

    And the ISC man page itself. The last paragraph (read, don't skim) explains it.

    The host statement

    host hostname {​
    [ parameters ]​
    [ declarations ]​

    The host declaration provides a scope in which to provide configuration​
    information about a specific client, and also provides a way to assign​
    a client a fixed address. The host declaration provides a way for the​
    DHCP server to identify a DHCP or BOOTP client, and also a way to​
    assign the client a static IP address.​

    If it is desirable to be able to boot a DHCP or BOOTP client on more​
    than one subnet with fixed addresses, more than one address may be​
    specified in the fixed-address declaration, or more than one host
    statement may be specified matching the same client.​

    If client-specific boot parameters must change based on the network to​
    which the client is attached, then multiple host declarations should be​
    used. The host declarations will only match a client if one of their​
    fixed-address statements is viable on the subnet (or shared network)​
    where the client is attached. Conversely, for a host declaration to​
    match a client being allocated a dynamic address, it must not have any​
    fixed-address statements. You may therefore need a mixture of host
    declarations for any given client...some having fixed-address state-​
    ments, others without.​

    So basically the way many places do it is flat out wrong and can lead to problems. It's pretty much that simple. Always keep your static IP allocations outside of the dynamic allocation pool. :)
    Mercjoe likes this.
  7. hpsmartyz

    hpsmartyz LI Guru Member

    Hi koitsu,

    thanks for following-up on this.

    First, I run Tomato v1.27.1798 on the 54GL.

    here are the outputs of the commands you typed, in the case the DHCP server is disabled from the GUI

    # ps | grep dnsmasq
    12156 nobody    872 S    dnsmasq
    # cat /etc/dnsmasq.conf
    # netstat -nl | grep ':67'
    So based on what you are saying, and especially seeing the result of the last command, I fail to understand what is happening at home :)

    But I also see that dnsmasq is still running and that it has "addn-hosts=/etc/hosts.dnsmasq" in its configuration which is in fact the static DHCP table. I also saw that dnsmasq uses also port 53 and netstat returns me something listening on port 53.
    So even if the DHCP server is disabled it might still be serving DHCP request for that static entries. No?
  8. koitsu

    koitsu Network Guru Member


    You just absolutely confirmed, with 100% certainty, no ifs/ands/buts about it, that the DHCP server on the WRT54GL is disabled. It cannot do answer any form of DHCP at this point. The netstat output for absolute certain proves it.

    Port 53 is for the DNS proxy (I explained this earlier; dnsmasq does two things: acts as a DNS proxy, and acts as a DHCP server. You've disabled the DHCP server part).

    The addn-hosts option obviously does not cause the DHCP server to be enabled -- again, the nestat output proves it.

    So, the DHCP server that your machines are talking to is absolutely the 320N. You can even confirm this on the clients themselves -- assuming they're windows, do ipconfig /all and look for the interface that does DHCP. It should show something like this:

    Ethernet adapter Local Area Connection:
            Connection-specific DNS Suffix  . : home.lan
            Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
            Physical Address. . . . . . . . . :
            Dhcp Enabled. . . . . . . . . . . : Yes
            Autoconfiguration Enabled . . . . : Yes
            IP Address. . . . . . . . . . . . :
            Subnet Mask . . . . . . . . . . . :
            Default Gateway . . . . . . . . . :
            DHCP Server . . . . . . . . . . . :
            DNS Servers . . . . . . . . . . . :
            Lease Obtained. . . . . . . . . . : Friday, July 06, 2012 21:38:55
            Lease Expires . . . . . . . . . . : Monday, January 18, 2038 20:14:07
    Note "DHCP Server" is (my Asus RT-N16 unit). So you can use that LAN IP address as a way to determine what DHCP server the client ended up talking to. If you want to test in real-time, you can issue ipconfig /release followed by ipconfig /renew to release a DHCP IP and get another. Then run ipconfig /all again.

    I really hope you don't have something silly going on like two routers with the same LAN IP address...

Share This Page