Changed the config in order for DHCP clients to use directly 8.8.8.8/8.8.4.4 as DNS server, in /etc/config/dhcp

config dhcp lan
    option interface    lan
    option start     100
    option limit    150
    option leasetime    12h
    list   dhcp_option 6,8.8.4.4,8.8.8.8

However the client (a Mac) still gets a local address (192.168.111.1 as nameserver) from DHCP.
That address being the main router's (the one connected to Internet) address (on the WLAN interface of OpenWRT router).

Forcing client, the Mac, resolution to be from 8.8.8.8 works, so direct NS resolutions are not blocked.

Is this the correct way to push DNS servers to clients?

note: tried previously to add "dhcp-option 6,8.8.4.4,8.8.8.8" to /etc/dnsmasq.conf, but that didn't work.

(Last edited by *++p on 11 Jan 2015, 10:33)

When I look at my config, I have
list server 'xxx.xxx.xxx.xx'
list server '8.8.8.8'
And that works for all clients.

I have two clients which need different dns and for them I have list dhcp_option....

Doesn't work. (rebooted openwrt router, removed WiFi entry on Mac, and even renewed the lease after)

The DNS server, client side, is still set to 192.168.111.1 (ie the non-wifi router address, doing the NAT, to which openwrt router is wired-connected).
That address, 192.168.111.1, is provided by openwrt via dhcp, so there's likely something missing in the config.

This is the config, /etc/config/dhcp. The bottom lines of dnsmasq: tried with/wo 'list server', with/wo 'option dhcp_option'...
(note that dnsmasq expects 'dhcp-option' but that syntax errors, so go with 'dhcp_option')

config dnsmasq
    option domainneeded    1
    option boguspriv    1
    option filterwin2k    0  # enable for dial on demand
    option localise_queries    1
    option rebind_protection 1  # disable if upstream must serve RFC1918 addresses
    option rebind_localhost 1  # enable for RBL checking and similar services
    #list rebind_domain example.lan  # whitelist RFC1918 responses for domains
    option local    '/lan/'
    option domain    'lan'
    option expandhosts    1
    option nonegcache    0
    option authoritative    1
    option readethers    1
    option leasefile    '/tmp/dhcp.leases'
    #list interface        br-lan
    #list notinterface    lo
    list server '8.8.4.4'
    list server '8.8.8.8'
    option   'dhcp_option' '6,8.8.4.4,8.8.8.8'

config dhcp lan
    option interface    lan
    option start     100
    option limit    150
    option leasetime    12h

config dhcp wan
    option interface    wan
    option ignore    1

No way to have DHCP clients set with DNS server addresses as 8.8.8.8, 4.4.4.4.
Drives me crazy...

(Last edited by *++p on 12 Jan 2015, 12:15)

What about:

    list 'dhcp_option' '6,8.8.4.4'

If that works, what about:

    list 'dhcp_option' '6,8.8.4.4'
    list 'dhcp_option' '6,8.8.8.8'

Unfortunately, that doesn't work either. Whatever the config is, OpenWRT gives DHCP clients the address of the main router (connected to Internet) as DNS server.

In the configuration provided above, is there a line that would force the router-as-DNS-server setting?

Or could someone indicate which source code deals with /etc/config/dhcp and take action?

(Last edited by *++p on 15 Jan 2015, 08:05)

May I ask why? In general, it is a good idea to use your router to cache DNS entries.

The generated config resides in /var/etc/dnsmasq.conf

I agree.
But it happens that in between the Internet router and the OpenWRT router, there is a Windows machine that I don't control.

Internet <=> Router <=WiFi-X=> Windows <=> OpenWRT <=WiFi-Y=> DHCP clients
            [  ROOM A  ]      [       ROOM B      ]          [   ROOM C   ]

The Windows machine acts as a WiFi relay in room B between the Internet router in room A wired-connected to openWRT serving WiFi clients in room C.
Clients in room C are too far from room A to catch the Internet router wifi signal, thus the Windows machine. And I cannot touch/get rid of that Windows setup.

It is a shop actually, WiFi clients are actual shop clients - there is some "human traffic" / doors in between rooms that seemingly affects DNS - could be some weird setup in Windows as well, but I don't want to "fix" that.
Sometimes the UDP packets requesting DNS resolution to the Windows machine (that appears as the router for OpenWRT) are lost or anyway not understood by Windows (while TCP traffic is undisturbed).
During the day, DNS resolution for clients is ~ok 30%, slow 40%, or not working 30%.

The thing is, forcing clients locally in the local setup to use the Google DNS servers - instead of the DNS server provided by DHCP [ie router] - fixes all issues. DNS resolution is almost instantaneous, and always works. But doing this on all Mac/Linux coming to the shop is not a solution.

dnsmasq runs on the openWRT router is 2.55.

Tried to modify /etc/init.d/dnsmasq to force the 'dhcp-option' with '6,8.8.8.8,8.8.4.4' directly on the command line, from

        /usr/sbin/dnsmasq $args && {...

to

        /usr/sbin/dnsmasq --dhcp-option=6,8.8.8.8,4.4.4.4 $args && {...

but that does not provide the intended result.

This is the output dump from 'ipconfig getpacket' on a Mac

root# ipconfig getpacket en0
op = BOOTREPLY
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 1896474031
secs = 0
ciaddr = 192.168.111.141
yiaddr = 192.168.111.141
siaddr = 0.0.0.0
giaddr = 0.0.0.0
chaddr = 71:37:de:ad:be:ef
sname = 
file = 
options:
Options count is 11
dhcp_message_type (uint8): ACK 0x5
server_identifier (ip): 192.168.111.1
subnet_mask (ip): 255.255.255.0
router (ip_mult): {192.168.111.1}
domain_name_server (ip_mult): {192.168.111.1}
renewal_t1_time_value (uint32): 0x12c
rebinding_t2_time_value (uint32): 0x6ebe0
lease_time (uint32): 0x93a80
nb_over_tcpip_node_type (uint8): 0x4
domain_name (string): mshome.net
end (none): 

That shows the dns-server being the router address.

--

Reply to @jow

It's in /overlay/etc on that device, and there, dnsmasq.conf shows only one non-comment line

dhcp-option=6,8.8.4.4,8.8.8.8

(Last edited by *++p on 15 Jan 2015, 11:36)

If I understood correctly, problems arise when you use the router as a DNS, and your OpenWRT uses the router as a DNS because it is configured as a DHCP client, right? I guess your OpenWRT box has problems when resolving domain names, too.

Have you tried to just force your OpenWRT box to use Google's DNSs for itself, despite whatever the router says? You keep your OpenWRT box as a caching nameserver for your clients, and you also solve the issue for the OpenWRT box.

(I know I am diverting from your original question, hope you do not mind)

Edited after rereading previous post.

(Last edited by eduperez on 15 Jan 2015, 16:11)

No, unfortunately.

--

So if anybody has an idea why the dhcp_option "6,8.8.8.8,8.8.4.4" seems to be ignored by dnsmasq...

Please read my previous post for more information about the problem.

Have you checked under Advanced-> DNS under the WiFi on the Mac to make sure the DNS is not hard coded in there?

(Last edited by iamalittlepepper on 17 Jan 2015, 07:57)

Yes. There is no DNS when no wifi connection is established.
There is one line (the router address) when OpenWrt is wifi-connected.

And on other devices, the same DNS server is set via DHCP.

In addition, as per the post above, the "ipconfig getpacket" Mac command shows that openWRT sets the DNS server to be the router address.

If you want all your clients to use Google DNSs just set OpenWrt to use those DNSs and leave OpenWrt to act as DNS proxy for your clients.
I have a similar scenario and it works just fine (I use OpenDNS).

root@OpenWrt2:/# cat /etc/resolv.conf
nameserver 208.67.222.222
nameserver 208.67.220.220

I see no point in pushing DNSs to every single client using DHCP.

That makes one hop less (two words :-)

Also the openWRT runs on a very low-spec device, and having clients doing the resolving work by themselves will save the owrt router some precious CPU cycles (and no caching on owrt).

Finally, for the sake of mental sanity after trying 10s of solutions, I'd really like to have that line working! Or at least know why it doesn't. Had a look at dnsmasq 2.55 source code and the dhcp-option should work.

Maybe your DHCP clients are caching the information somehow? Maybe you need to release and explicitly acquire a new lease?

Tbh, I never heard of a problem like yours and I cannot recall any ticket with similar described symptoms. Also your configuration has been correct from the first time you posted here and I used the same one to assign other NS servers to windows and Linux clients.

As a last resort you can try using "dhcp-option-force" in dnsmasq.conf and see if it changes anything.

Thanks jow.
The reason was maybe that this option was not supported - as I installed a small BIN at the time.

Anyway, tried to flash a newer/bigger version, compiled by myself, ensuring the option is available (3.5 MB / 4)
After releasing as much RAM as possible before doing the sysupgrade (~5.5 MB / 16), the process hung near the end... It seems the last part of the process needed more RAM than available.
This was my first attempt to do a sysupgrade, and it seems I had to be more careful, memory wise!
Maybe there was a "init X" that allows to boot without all the services and caches... didn't find that :-(

So the kernel was Ok, but the packages were not - like dropbear etc... so no way to connect to the wla2-g54c...

Tried to short some PINs (5-6, 15-6 ...) on the flash to TFTP (192.168.10.100), but after a few unsuccessful tries, the shorting process resulted in a full bricked device, for good this time!

Note:
since I'm here, want to tell how the whole dev environment is well made/organized and convenient.
Compilation is amazingly clean. A very fine OSS imo.
Was really fun to build the BIN and check the code inside - very easy to make changes.
Too bad the installation process is (seemingly) very risky - but was my first time...

--

Anyway the device was from 2003.
Just purchased a Buffalo WMR-300, very cheap and lot of memory (Flash 8MB, RAM 64 MB).
It seems somebody was able to flash it ( http://wiki.openwrt.org/toh/buffalo/wmr-300 ) without giving up any information on how to do it :-(

Just started ... According to Wireshark, pressing AOSS before sw ON the router makes it searching (ARP) for 192.168.11.168 from 192.168.11.1 ....

Still work to do!

(Last edited by *++p on 21 Jan 2015, 10:27)

I know, it's an old issue, but is there a solution?

I try to push for some hosts a different dns-server on old wrt54gl with 10.03.1:

config tag 'kids'
    list dhcp_option '6,208.67.222.222,208.67.220.220'

config host
    option name 'pluto'
    option mac 'CC:E4:EE:56:W3:E5'
    option ip '192.168.2.3'
    option tag 'kids'

nslookup give me the router ip. If I push the dns-server from client-site all works like a charm...

Has anybody a hint for me? Some patch?

Thanks!

Maart, don't resurrect old threads just because they seem to describe similar symptoms to what you're experiencing. The symptoms are not everything; the network layout matters, as well as the hardware used to construct the network.

Open a new thread for your problem.

OK, Thanks.