[Dnsmasq-discuss] address=/#/192.168.0.1 - does not work!

[Albert ARIBAUD]

Le 09/12/2013 12:26, Nikita N. a écrit :
> Hi Albert :) I see you want a complete log/trace session for your
> debugging, isnt it? :)

*My* debugging? No. I don't intend to debu your issue, only have a look 
at it and see if, as a user of dnsmasq to another, I can help *you* 
debugging. :)

Also, I don't think a complete log/trace is needed. Only DHCP packets 
are useful, and only from the request or discovery packet to the ack 
packet (or clear lack thereof).

> Well I didnt think to prepare that, I was thinking you could give me
> some more easy answer..

Rule number one of problem solving: you cannot solve a problem if you do 
not know what the problem is. Since your problem is a missing packet in 
a DHCP exchange, the first thing I'd do is to have a look at the exact 
DHCP messages sent and received by the DHCP client and server, as seen 
by either machine. I would also suggest logging ARP packets.

> First of all I would like to know, is my config file correct?
> With such config file, am I supposed to get what I want?
> Because, if my usage is correct and the config file is correct, then its
> some kind of bug, and so I can prepare you some traces, if you really
> need..

Well, I did not look at the config file because you mentioned that your 
use scenario works in case the DHCP discover packet is sent first, which 
means the interfaces, the ranges, the leases are basically ok; and that, 
as far as I know, there is no way to configure dnsmasq so that it 
answers differently depending on there being a discover message or not.

> Honestly, since dnsmasq didnt work, in fact I dropped dnsmasq..
> I tested with "dhcpd" for the DHCP support, and with "dnsspoof" for the
> DNS, and all works great.
> But as you know, dhcpd is very heavy app, king of too exaggerate for my
> needs, and dnsspoof is a dirty hack tool..
> So was hoping in dnsmasq for a clean,small, all-in-one solution.. but
> maybe Im wrong..?

We can only know by investigating. Apart from logging the issues you 
meett, you could also perform some tests if you have another machine 
which can connect to the server through Ethernet. This would help 
discriminate between a server- or client-related issue and a network 
equipment-related issue.

Also: could you avoid top-posting?

Amicalement,
-- 
Albert.