[Dnsmasq-discuss] DHCP packet received on <interface> which has no address

richardvoigt at gmail.com richardvoigt at gmail.com
Sun Aug 28 21:29:54 BST 2016

On Thu, Aug 25, 2016 at 11:57 AM, Albert ARIBAUD <albert.aribaud at free.fr>

> Le Thu, 25 Aug 2016 18:45:09 +0200
> Albert ARIBAUD <albert.aribaud at free.fr> a écrit:
> > eth0.3 which does not have an IP and netmask, and therefore rightly
> > complain about that.
> (developing slightly)
> I do understand that most probably -- even though it was not
> stated explicitly -- dnsmasq is receiving its how hosts' DHCP request
> sent by the client running on eth0.3.

I suggest a more problematic possibility: the real DHCPOFFER packet coming
from the actual DHCP server to which eth0.3 is connected is being passed to
the dnsmasq process instead of the dhcp client.

> This does not really change my reading of the situation: if dnsmasq
> receives this request, it is because eth0.3 is in the list of
> interfaces which dnsmasq is actually listening to, even though it is
> not in the list of interfaces it *should* be listening to. Hence my
> question...
> > I don't think, therefore, that what you describe as a bug is [the] one
> > [you are considering]. Rather, I would ask how exactly the list of
> > interfaces dnsmasq should listen on is efined, how exactly eth0.3 is
> /s/efined/defined/
> > excluded from this list, and whether dnsmasq actually listens only to
> > the given list of interfaces.
> ... because obviously dnsmasq is listening on eth0.3 but should not.

This (listen only to the given list of interfaces) is what bind-interfaces
is for.  If you are running additional DHCP client or server software on
the same machine as dnsmasq, you MUST use bind-interfaces, otherwise
incoming packets needed by those other processes may be delivered to
dnsmasq instead.

Without bind-interfaces, dnsmasq will filter incoming packets based on the
interface they were received on, but non-matching packets will be
discarded, not redelivered to some other process.

Arguably, the dhcp client process should be binding to an interface itself,
so that it becomes a better match for incoming DHCPOFFER traffic.  But the
fact you're seeing this dnsmasq log message indicates that this has not
been done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20160828/1f8e417f/attachment.html>

More information about the Dnsmasq-discuss mailing list