DNSMasq custom Gateway doesn't work on Toastman VLAN?

Discussion in 'Tomato Firmware' started by gfunkdave, Jun 21, 2013.

  1. gfunkdave

    gfunkdave LI Guru Member

    I tried adding the following line to my DNSMasq custom conf file (in Advanced - DHCP) but it didn't change the default gateway. This used to work fine before I put a VLAN build of Tomato on my router.

    I'm running Toastman 1.28.0502 MIPSR2Toastman-RT-N K26 USB VLAN-VPN on a RT-N66.

    Any ideas? I can just switch back to a non-VLAN build (don't really use the VLAN stuff) but wanted to bring it to people's attention in case this is a problem that can be fixed. I also realize I'm a couple versions behind the current one. Thanks!
  2. koitsu

    koitsu Network Guru Member

    The problem probably has nothing to do with the option "not working", but that the VLAN configuration/setup/whatever you have causes some oddities.

    Otherwise, if the problem happens with non-VLAN builds as well, then what this means is that dnsmasq itself or the Tomato code has begun to "override" certain DHCP options. It would really help if you can verify that the problem is specific to the VLAN builds or not. (I keep trying to tell people to avoid the VLAN stuff altogether because of all the nuances/catches involved -- like this, if it turns out to be one)

    P.S. -- You don't have to use numeric options, you can say dhcp-option=router, It's a lot easier to read. For a list of strings/numerics, use dnsmasq --help dhcp from the CLI.
  3. gfunkdave

    gfunkdave LI Guru Member

    Yes, it's most likely a VLAN build issue. That's what I meant by "Doesn't work on Toastman VLAN". It worked fine on the non-VLAN builds I've used but not on this VLAN build (in the main VLAN - I only have one defined).
  4. koitsu

    koitsu Network Guru Member

    Is it possible to get a packet capture of all DHCP traffic from one of your LAN clients? You should be able to use tcpdump on the router itself to do this (particularly tcpdump -i {laninterface} -n -s 0 -w /tmp/capture.pcap "port 67 or port 68"), initiate a DHCP release from the client, wait a few seconds (mainly for delineation in the capture), then issue a renew. Provide /tmp/capture.pcap here and I can take a look at it.

    Also: {laninterface} might be a tricky one to discern with a VLAN setup. Normally this would be br0, I believe.
  5. gfunkdave

    gfunkdave LI Guru Member

    Hey koitsu - thanks for the continued help...oddly enough, it seems to be working now. I have no idea what might have changed.
  6. koitsu

    koitsu Network Guru Member

    Snakes have invaded your router. They are nesting, copulating, laying eggs for next time... j/k :)
  7. Toastman

    Toastman Super Moderator Staff Member Member

    I've just tried to assign an Android (Samsung Galaxy S2) device to a second gateway with dnsmasq (by MAC address) and it looks like it failed to work as it should. It seemed to be sending to the web on the first gateway but got no reply. It looked like replies came back on the second, (or vice-versa). I was doing this remotely, so it was a bit hard to be sure of what was going on, but this looked really weird. I used the IPTraffic real Time graph to check..

    Also, it looked like only the Android devices didn't do what they were told.
  8. gfunkdave

    gfunkdave LI Guru Member

    Interesting. I don't have any Android devices at home - when I noticed the problem before, it was with an iPad and a Win7 laptop.
  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