Tomato/Shibby - DHCP Problems

Discussion in 'Tomato Firmware' started by Sentinel62, May 8, 2016.

  1. Sentinel62

    Sentinel62 Network Newbie Member

    I just upgraded to an Asus RT-N66U and installed Shibby's v136 release (tomato-RT-N66U_RT-AC6x--136-AIO-64K). Everything is mostly working great, except DHCP. I have always used a Windows DHCP server and it works fine. Previously I had an Asus RT-N12 with v121 release (tomato-K26-1.28.RT-N5x-MIPSR2-121-Max).

    DHCP is disabled on the router and all wired clients work fine. The wireless clients are no longer able to renew the DHCP lease after the upgrade in routers/firmware. If I enable DHCP on the router (in addition to the Windows DHCP server - but with a different range) all the wireless devices seem to work fine. Though they mostly get their DHCP address from the original Windows server, presumably just depending on which server replies first.

    I have not tried to trace packets on the lan but it certainly appears that the DHCP requests from the wireless lans are not propagating to the wired lan in able to obtain an address. Enabling the internal router DHCP then allows this, in addition to also providing addresses.

    Has anyone else experienced anything like this? Any suggestions on what to try or how to debug it farther? I plan to try installing v121 on this router to see if it solves the problem. At the new location for the RT-N12 I am using the internal DHCP, so it has no problems with v136.

  2. koitsu

    koitsu Network Guru Member

    I can't reproduce this on my own network, where I've reliably used dnsmasq on Tomato (which is the DHCP server) as my network's DHCP server, or using ISC's DHCP server (on a FreeBSD box on my LAN). The important thing that you need to understand about DHCP is that you can only reliably have one DHCP server on a network segment. If you intermix two, even briefly, it can cause chaos for quite some time (in most cases, all machines need to be powered off, followed by all DHCP servers being shut down (ensure they are not listening!), followed by ONE DHCP server being brought up/online, followed by the machines being powered back on. I can't stress this order of operation enough).

    "Depending on which one replies first" already indicates massive amounts of confusion being introduced to the network; DHCP is actually a fairly "chatty" protocol in the sense that it isn't just a client saying "gimme" and a server saying "here you go" and that's the end of the transaction -- this isn't how the protocol works. There's a lot more that goes on that just that, it's usually 3 or 4 back-and-forth transactions before everything's negotiated. You cannot run two DHCP servers on the same network even if both delegate separate IP ranges -- DHCP doesn't work like this. You should read about the protocol and learn the importance of and "how" this type of broadcast works on an IP network segment.

    I can assure you that disabling the DHCP functionality in Tomato (Basic -> Network -> make sure under "DHCP" the column is labelled "Disabled") does in fact work correctly. There isn't anything "lingering" that could cause a problem DHCP-wise, and I cannot think of anything that would cause the behaviour in question. If it did, I wouldn't be able to use ISC's DHCP server on my FreeBSD box on my LAN and have everything work flawlessly.

    If you are using VLANs or have other bridged network configurations (especially the latter), this could explain some of the problem. People who make things like two bridged networks for wireless LAN segregation ("guest" wifi vs. "i-wear-big-boy-pants" wifi) can run into this complexity. TL;DR -- The simpler your network setup is, the less problems you'll have.

    I run tomato-RT-N66U_0509.2Toastman-RT-AC-VPN.trx on my RT-N66U (haven't upgraded to 0509.3 yet).
  3. Sortec

    Sortec Serious Server Member

    check to make sure you dont have AP isolation turned on. That will stop the wireless devices from accessing the wired devices. Which in turn, will not allow your wireless devices to reach your DHCP server on your wired lan to be able to respond to requests.
  4. Sentinel62

    Sentinel62 Network Newbie Member


    I never had two DHCP servers, until things didn't work. When setting up the new router the first thing I did was disable DHCP because I have my own DHCP server. Everything was fine for about a 3-7 days (given the week lease time I had on my DHCP server). As soon as devices started trying to renew they just sat there trying to "obtain IP address". I couldn't figure out why. So I manually assigned a few addresses and things worked ok. Then more devices started failing.

    Note that this worked fine for probably 10+ years, through various versions of Routers and Tomato. My Windows DHCP server is running on Windows 2003 Server, and hasn't changed (other than any updates Microsoft might have made, but 2003 is way past any maintenance from the mothership, and I do need to upgrade). Regardless, it was the new router & new version of Tomato that started the problems.

    I do believe that disabling DHCP in Tomato disables it. Tomato never handed out an address, my devices just sat there unable to get one at all. In desperation I tried turning on the DHCP server in Tomato, and instantly the devices started working. Even though they didn't get an address from the Tomato server, they got the address from the Windows server they had previously used. Eventually now a few have actually obtained an address from the Tomato server (as I now have both running). However bad that is, it does seem to be the only way things work currently.

    I certainly admit I don't understand the details of the DHCP process, and I really don't want to have to learn them ;-( I do not have any vlans, or anything else complicated setup. Though, if I understand it partly, it appears that each wireless access point is a vlan of it's own. It's pretty simple, router, one network, dhcp server on that network. Everything wired and wireless used to work fine. Now the wired devices work fine, but the wireless devices are unable to obtain an address, unless I enable the DHCP server in Tomato. I have never touched the original DHCP server (other than rebooting about everything trying to get things to work).

    I'm glad it works for you, but I'm stuck feeling something about the DHCP requests is not making it's way from the wireless side to the wired side.

    Sortec - I do not have AP isolation turned on (just double checked), thanks for the try.

    All other traffic does work fine, if I either statically assign the address (with the Tomato DHCP disabled), or enable the Tomato DHCP - which then allows the device to get an address either from the Windows or the Tomato DHCP server - most then are able to get the Windows server address.

    I used to run v121 on the old router, so in addition to upgrading the router I did update the firmware version to v136 as well. I am going to try going to v121 to see if it changes anything. Aside from a new router, this router of course has two access points (2.4 and 5 GHz). I don't think that matters, but I did try disabling 5 GHz AP, no change. One other feature I did enable, and had been wanting for a long time - just never noticed it, was Route Modem IP. I'm going to try removing that as well, given it certainly has to add routing as well.
  5. koitsu

    koitsu Network Guru Member

    To troubleshoot this, I'm sorry to say odds are you're going to have to learn how DHCP works and do packet captures. DHCP really isn't that bad (compared to some other protocols). It would also benefit you to learn a little bit about the different interfaces on Tomato (ex. ethX vs. br0X vs. vlanX) and "how" they all interface/interact. It varies per model of router. I'm happy to explain the configuration for an RT-N66U:

    Router interface br0 = software bridge of vlan1, eth1, eth2 (what people commonly call "LAN")
    Router interface eth0 = All Ethernet ports on router (5 ports (ports 0-4))
    Router interface eth1 = 2.4GHz wifi
    Router interface eth2 = 5.4GHz wifi
    Router interface vlan1 = Wired LAN ports on router (a.k.a. ports 0-3)
    Router interface vlan2 = Wired WAN port on router (a.k.a. port 4)

    You're incorrect in your conclusion that "each wireless access point is a vlan of its own". (Respectfully, that doesn't even make any sense, so I'm just going to ignore it). It's good you have a simple network configuration though: makes this a lot easier :)

    Wireless clients' traffic (both broadcast as well as directly to a DHCP server) will in fact flow via br0 by default. (See my above post, re: how I use ISC's DHCP server on a FreeBSD box on my wired network as a DHCP server and it works just fine for wireles and wired clients). There is really no difference on the Tomato side between wireless traffic and wired traffic as far as DHCP goes (for technically advanced readers: I'm intentionally keeping this simple for sake of conversation): the dnsmasq DHCP server listens on interface br0 (proof it's working fine is when you enable the DHCP server in dnsmasq that things function fine), and if you're not using that, then whatever DHCP server you have on your LAN (wired or wireless!) will act as such.

    You're going to have to do packet captures on both the Windows server (Wireshark is a likely choice; a capture filter of "port 67" should be fine -- I strongly recommend using the Wireshark Legacy program, as the current non-legacy one behaves very differently (in my experience) with capture filters) as well as on the router (using something like tcpdump -i br0 -l -n -s 8192 "port 67" -- you'll need to install Entware-ng on a USB stick and install the tcpdump package (opkg update ; opkg install tcpdump) or find a MIPSR2 tcpdump binary and get it on the router using wget or other means), at the same time, and correlate what's what. Know what MAC address of the DHCP client is in advance too, since that's going to be helpful for identifying broadcast ( traffic.

    It honestly to me sounds like the problem is with your Windows DHCP server ignoring certain kinds of traffic or misbehaving (ex. just because the service is running doesn't mean it's working). Verifying that it's seeing broadcast traffic and the initial DHCPDISCOVER packet, and that the client can see the DHCPOFFER response packet, is a good start). Have you actually tried power-cycling the Windows box? I hate recommending things like that blindly, but uh, Windows really does not make a good server product and things "stop working for no reason" all the time (protip: I'm a professional UNIX SA/NA since early 90s).

    If you really think the issue is with Tomato, then run several copies of tcpdump separately on each interface (one using -i br0, one using -i eth1 (2.4GHz), one using -i vlan1) and see what traffic is seen where. If you find that certain traffic arrives on one interface but isn't arriving on another (ex. you see DHCP traffic on eth1 that isn't seen on br0), then that would be a problem, and would be the first I've ever heard of this happening in almost 10 years of me using Tomato across several device types (WRT54G, 54GL, SL54GS, RT-N16, RT-N66U, etc.)).
  6. koitsu

    koitsu Network Guru Member

    Three more things:

    1) When you moved from an RT-N12 to an RT-N66U, and chose to upgrade firmwares in the process, how exactly did you "migrate" your settings (from the RT-N12 to the RT-N66U)? More specifically: did you re-configure the RT-N66U using the GUI (setting each thing manually), or did you use the Administration -> Configuration feature? (This matters!)

    2) Are you using any part of the Advanced -> MAC Address cloning/spoofing feature?

    3) Are you using the Port Forwarding -> DMZ feature?
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice