[Dnsmasq-discuss] [BUG] Bogus IP address in the syslog messages

Simon Kelley simon at thekelleys.org.uk
Sat Feb 20 15:58:36 GMT 2010


Sergei Zhirikov wrote:
> On 2010-02-20 14:19, Simon Kehlley wrote:
>> Sergei Zhirikov wrote:
>>> Hi,
>>> 
>>> On of the DHCP clients in my network believes that is has the
>>> same hostname as the machine where dnsmasq-2.52 is running. That
>>> by itself is a result of misconfiguration, but the reaction of
>>> dnsmasq seems a bit odd. I get the following messages in syslog
>>> when that client tries to renew its lease:
>>> 
>>> 
>>> The messages about not giving the host name are in principle
>>> correct. What is odd is that, as you can see, every other time
>>> dnsmasq mentions IP address 216.230.6.8, which is totally bogus.
>>> There is nothing in the whole network that even remotely
>>> resembles that IP address. The content of /etc/hosts is quite
>>> trivial:
>>> 
>>> # hosts 127.0.0.1 localhost 172.23.112.1 wafer.softlights.net
>>> wafer
>>> 
>>> The problem seems to be just cosmetic, but since it is unclear
>>> where the bogus IP address comes from, it is possible that there
>>> is a more severe problem (like memory corruption) is hiding
>>> behind it.
>>> 
>>> I'm wondering if anyone can reproduce this phenomenon.
>>> 
>>> 
>> What you are seeing is consistent with there being two address
>> entries for wafer.local.softlights.net in the DNS cache. You see
>> different addresses each time because the order gets swapped on
>> each lookup (to implement round-robin) and the DHCP code logs that
>> message and bails on the first entry it finds.
> 
> The thing is that wafer.local.softlights.net resolves to a single IP
> address, which is 172.23.112.1.
> 
>> That's not a complete explanation (where did the 216.230.6.8
>> address come from?) but it's a bit less scary than a memory
>> corruption.
>> 
>> Try a test query using dig for wafer.local.softlights.net, I
>> suspect you will see both addresses returned.
> 
> As I said, there is only one IP address. I have also used tcpdump to
> watch both DHCP and DNS communication. The address 216.230.6.8 does
> not show up anywhere. (As a sidenote: I found it a bit surprising
> that despite "not giving name wafer ..." dnsmasq returns that same
> host name in the DHCPACK message to the client)
> 
>> Now try restarting dnsmasq and repeating the dig query. If you get
>> the same result you must have some obscure configuration hidden
>> away somewhere (--addn-hosts?) If the problem has cleared then we
>> have a mystery to solve.
> 
> Here comes the funny part. I should have mentioned that in my first
> message. If I restart dnsmasq the bogus address remains the same most
> of the time, *but not always*. If I run another dnsmasq binary (I
> still have one of version 2.51, that I used before the last upgrade)
> then the bogus address is different from the one I get with 2.52.
> This makes me think it somehow depends on the memory layout of the
> running process. Those mysterious addresses are not completely
> random. All that I have seen so far have form xxx.xxx.6.8.
> 
> Of course, I can't be sure it's memory corruption, but it certainly
> looks very much like one.
> 
> By the way, dnsmasq is running on an LFS system, which I have built
> myself. Every single line in every single configuration file is
> written by me, that's why I'm quite sure it isn't some obscure
> configuration issue. Although, I did try "grep -rF '216.230.6.8'
> /etc", just in case, and it came up with nothing, as I expected.
> 
> I'm puzzled...

Well, you can reproduce the problem, so we're nearly there.......


Things to try:

1) Run dnsmasq with --log-queries, and then send it SIGUSR1. That will
dump the cache to the log. See anything odd?

2) Build dnsmasq without optimisation and with symbols. Still see the
problem? If so run under gdb and have a poke around.


Simon.

> 
> Regards, Sergei.
> 
> 
> _______________________________________________ Dnsmasq-discuss
> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 




More information about the Dnsmasq-discuss mailing list