ho to get rid of DHCPINFORM calls

[Gravityz]

Hello,

i have read this is a nknow issue(or functionality)
it seems that some devices keep on asking /informing the dhcp server, long after they got a valid ip adress.

i also noticed that when there is instability on the router(links going doing) i see these entries

is there a way to stop those devices from asking/informing?
not all clients do it, only a couple of them

Jan 9 12:02:11 dnsmasq-dhcp[382]: DHCPACK(br0) 192.168.1.94 MAC:ADRES NL-TAG-20021
Jan 9 12:03:33 dnsmasq-dhcp[382]: DHCPINFORM(br0) 192.168.1.94 MAC:ADRES
Jan 9 12:03:33 dnsmasq-dhcp[382]: DHCPACK(br0) 192.168.1.94 MAC:ADRES NL-TAG-20021
Jan 9 12:04:54 dnsmasq-dhcp[382]: DHCPINFORM(br0) 192.168.1.94 MAC:ADRES
Jan 9 12:04:54 dnsmasq-dhcp[382]: DHCPACK(br0) 192.168.1.94 MAC:ADRES NL-TAG-20021
Jan 9 12:06:15 dnsmasq-dhcp[382]: DHCPINFORM(br0) 192.168.1.94 MAC:ADRES
Jan 9 12:06:15 dnsmasq-dhcp[382]: DHCPACK(br0) 192.168.1.94 MAC:ADRES NL-TAG-20021
Jan 9 12:07:37 dnsmasq-dhcp[382]: DHCPINFORM(br0) 192.168.1.94 MAC:ADRES
Jan 9 12:07:37 dnsmasq-dhcp[382]: DHCPACK(br0) 192.168.1.94 MAC:ADRES NL-TAG-20021
Jan 9 12:08:58 dnsmasq-dhcp[382]: DHCPINFORM(br0) 192.168.1.94 MAC:ADRES
Jan 9 12:08:58 dnsmasq-dhcp[382]: DHCPACK(br0) 192.168.1.94 MAC:ADRES NL-TAG-20021
Jan 9 12:10:19 dnsmasq-dhcp[382]: DHCPINFORM(br0) 192.168.1.94 MAC:ADRES
Jan 9 12:10:19 dnsmasq-dhcp[382]: DHCPACK(br0) 192.168.1.94 MAC:ADRES NL-TAG-20021
Jan 9 12:11:40 dnsmasq-dhcp[382]: DHCPINFORM(br0) 192.168.1.94 MAC:ADRES
Jan 9 12:11:40 dnsmasq-dhcp[382]: DHCPACK(br0) 192.168.1.94 MAC:ADRES NL-TAG-20021
Jan 9 12:13:01 dnsmasq-dhcp[382]: DHCPINFORM(br0) 192.168.1.94 MAC:ADRES
Jan 9 12:13:01 dnsmasq-dhcp[382]: DHCPACK(br0) 192.168.1.94 MAC:ADRES NL-TAG-20021
Jan 9 12:14:22 dnsmasq-dhcp[382]: DHCPINFORM(br0) 192.168.1.94 MAC:ADRES
Jan 9 12:14:22 dnsmasq-dhcp[382]: DHCPACK(br0) 192.168.1.94 MAC:ADRES NL-TAG-20021

 

[jegesq]

If the client is a Windows 7 machine, this is a known issue with Windows 7 (not with Asus). It has been resolved in both official and Merlin FW, so you should update from whatever version you are using. See this thread in general and the specific post from Merlin: http://forums.smallnetbuilder.com/showpost.php?p=133522&postcount=4

 

[Gravityz]

thanks,
i am running 374 frork v6 so it should be covered

one device is has xp os
the other is an appletv3

If the client is a Windows 7 machine, this is a known issue with Windows 7 (not with Asus). It has been resolved in both official and Merlin FW, so you should update from whatever version you are using. See this thread in general and the specific post from Merlin: http://forums.smallnetbuilder.com/showpost.php?p=133522&postcount=4

 

[jegesq]

Hmmm. This may be a bigger problem than I thought at first. At least it appears to be an issue that is in need of attention. And it may be one that Merlin needs to take another look at again from a security perspective (see the quote below).

After doing some further research on this, and re-reading that thread with Merlin's response (cited in the link above), and then even checking my own AC66U system log (and like you, I'm running a 374.xx variant, specifically 374.38_2 a that the moment), I see that every few minutes, my wife's Windows 7 laptop is querying and flooding the log with "DHCPInform" requests. She's connected wirelessly on 5ghz using an Asus AC600 USB dongle. I have another Windows 7 computer, used as an HTPC that is using a wired LAN connection attached to my remote AC66U repeater, and that doesn't seem to exhibit the same behavior in the repeater's logs--the repeater is using Merlin 374.41).

This appears to be an issue with not only some Win 7 clients, but also with XP as well (I don't have any running any longer, but this article at this link (scroll down to message #6 at this link on the LinuxQuestions.org message forum) by "Slack66" suggests it can be a problem with a number of different kinds of devices and OSes:

WPAD, or Web Proxy AutoDetection, is a protocol that was designed to convey Netscape's PAC format (Proxy Auto Config file) to web browsers automatically - without the user ever having to type a button. It never became an RFC proposed standard, but rather died as an Internet-Draft. I can only wonder what politics led to its demise...but it's full of wonderful hints of terrible flamewars, including the admission that the option code, 252, was 'assigned by the DHC WG chair.' Maybe I need to point out: option codes are never assigned by WG chairs...they are assigned only by IANA after standards action. Meanwhile, 252 is in the "site-local" space - it is not available for allocation! Not by a WG chair, not even by IANA. The site-local options were intended for site administrators (your network's sysadmin) to allocate - not manufacturers.

But its failure to reach RFC did not stop it from becoming the Internet's de facto standard in configuring web proxies. Consequently, whenever your Windows box boots, it tries WPAD to find proxies in order to get Windows Updates...Automatic Updates does this a few minutes after a box reboots. The first thing to do in WPAD is to try DHCP, so you might see Windows boxes try DHCPINFORMs first requesting option 252. They'll try several times until they get 252, and if they never get it, they move on to DNS. They'll query 'wpad.foo.example.com' if foo.example.com were the configured domain name, then 'wpad.example.com', then they give up. They're looking for A records, although the WPAD standard also describes TXT and SRV records (it never tries these). WPAD also describes using SLP after DNS, but I sincerely doubt anyone bothers.

The DNS method is essentially garbage being flooded out on the global Internet. Some older implementations seem to seek right down to 'wpad.'. It seems this is tried in others if no domain name were specified. Your ISP has to deal with wpad.ispname.com being queried all the time, and the rest of the Internet has to cope if the system has some garbled domain name...the query gets passed all the way down to the roots and up.

Edit 2008-08-13: It's also a security problem! Dan Kaminsky has reminded us that it is still, even with all our protections (short of DNSSEC), quite possible to manipulate DNS data. A ne'er do well that creates a cache entry for 'wpad.etc' in front of a horde of WPAD-capable clients can become the man in the middle for all their web content. You can filter for WPAD DNS queries, but it's easier to just make them stop querying for it.

The way to stop all of these clients that implement WPAD from querying DNS at all is to give them a poison pill at DHCP time; or heck configure WPAD at DHCP time and start providing a caching proxy service. I'll show you how to do both below the cut.

Slack66 then goes on to describe how to get these queries to stop, but the description appears to be aimed at Apache servers, and not with Asus routers in mind. Perhaps the same would work, but it's over my head.

Merlin? Anyone else?

I'm now concerned that this could really pose a security issue. I'm also concerned because DNSmasq apparently doesn't fix the issue (at least according to those who are using later versions of 376.xx firmware that have supposedly corrected the issue.

So again, Merlin or anyone else have any ideas about how to get these DHCPInform queries to stop?

 

[jegesq]

One more thing....yes, I know that in Merlin's FW one can turn off the DHCP logging.

But that's not the point. If the device is going to keep flooding the router, and potentially these DHCPInform's pose a security threat, turning off the logging of the DHCPInform queries is only hiding the problem, not resolving it or getting it to stop.

Again, I've read almost every thread where Merlin and others here have written about the issue, and no one seems to really address the issue or outline a real solution.

Merlin? Anyone?

 

[john9527]

Can you double check that the dnsmasq.conf is correct? Telnet/ssh in and

cat /etc/dnsmasq.conf | grep dhcp-option

There should be an entry in the output

dhcp-option=252,"\n"

which causes dnsmasq to give a null response to the wpad query, basically saying stop asking.

 

[jegesq]

Following someone else's suggestion in a message posted about a year ago on SNB (don't have the link any longer) I set the Win 7 laptop that is doing the DHCPInform queries to a static IP address (setting both the MAC and IP address in the LAN, "DHCP Server" options for static address setting. Hit "apply" and then checked the log. No query for about 10 minutes, but then another one.

I guess it's not as simple as setting static IP's either. Back to the drawing board.

 

[coldwizard]

If the client is a Windows 7 machine, this is a known issue with Windows 7 (not with Asus). It has been resolved in both official and Merlin FW, so you should update from whatever version you are using. See this thread in general and the specific post from Merlin: http://forums.smallnetbuilder.com/showpost.php?p=133522&postcount=4

You need to take your own advice to update.
If you check the change log in README-merlin.txt. at

https://github.com/RMerl/asuswrt-merlin/blob/master/README-merlin.txt

You will find this issue was not resolved until 374.43 and there have been many security patches since the version your running.

... and then even checking my own AC66U system log (and like you, I'm running a 374.xx variant, specifically 374.38_2 a that the moment), I see that every few minutes, my wife's Windows 7 laptop is querying and flooding the log with "DHCPInform" requests ....

 

[jegesq]

You need to take your own advice to update.
.

Doh!!! [sound of hand slapping forehead].

No more DHCPInform queries.

Sheesh. That was easy.

 

[Gravityz]

i have 374.43 fork v6 and the problem is still there

 

[john9527]

i have 374.43 fork v6 and the problem is still there

What type of clients are they (your first post indicates not all clients are doing it)? I'm sure it's fixed on the fork for Win 7...

 

[jegesq]

I would suggest that Gravityz do a re-flash of the firmware and then perform factory reset as well (re-entering settings by hand), as well as deleting the existing old wireless profile on the client device that is sending the DHCPInforms. After I did that (re-flashed, factory reset and re-creating wireless profile), I now only get one such DHCPInform request following the initial boot of the router from the Win7 laptop, and then it never repeats again. So I guess the Merlin 374.43 firmware (which would also include the 374.43 fork) does in fact fix the issue, telling the laptop to stop asking once it has an IP address assigned.

 

[Gravityz]

my pc has windows 7 and has no problems

my apple-tv3 is the one causing these DHCPINFORM queries.

now the strange part.
The apple-tv3 is hardwired, not connected through wifi

the mac address showing up isd the mac address of the hard wired network port.

 

[john9527]

Are you using the iTunes server on the router? If not, telnet/SSH to the router and enter

service stop_mdns

and see if that changes things

 

[Gravityz]

tried it.
i thought it was gone but noticed the DHCPINFORM requests are only repeatetly send when the appletv is in standby mode.

no problem when it is on but in standby mode it keeps asking.
this might be apple's way of checking if thre network is still alive since it is used for airplay as well.

my windows xp notebook however keeps on asking when it is on.

so for now i will put the appletv on an static address and turn off dhcp logging.

Are you using the iTunes server on the router? If not, telnet/SSH to the router and enter

service stop_mdns

and see if that changes things

 

[RMerlin]

Oh, Apple...