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

[Andrew Shadura]

Hello,

We've run into an issue: in our configuration, there are many
interfaces, some of them are being served by dnsmasq-dhcp, some of them
use run dhcp client themselves. Interfaces come and go, so it's not
always possible to use bind-interfaces. Sometimes dnsmasq-dhcp reacts to
the DHCP packets coming from the interfaces it's not supposed to work
with, and as they hasn't been configured yet dnsmasq complains.

Having looked at the code, I see the warning is issued when dnsmasq-dhcp
has detected the interface hasn't got an address, before it checks the
interface name or exclusion lists. That doesn't seem right to me, but I
haven't come up with a reasonable patch yet.

Could that please be fixed?

Thanks.

[Albert ARIBAUD]

Hi,

Le Thu, 25 Aug 2016 11:52:41 +0300

Post by Andrew Shadura
Hello,
We've run into an issue: in our configuration, there are many
interfaces, some of them are being served by dnsmasq-dhcp, some of
them use run dhcp client themselves.

Not sure I'm getting this right, but I assume you mean on some
interfaces the host running your dnsmasq is DHCP server, and on some it
is DHCP client.

Post by Andrew Shadura
Interfaces come and go, so it's
not always possible to use bind-interfaces.

This seems to imply that dnsmasq should serve (at least some) of these
dynamic interfaces. If all dynamic interfaces should be served, then
AFAIU bind-dynamic is what you need. Otherwise, you need some ad hoc
means discriminate beweeen 'client' and 'server' dynamic interfaces.

Also, you haven't said how these interfaces come and go. Are they
virtual interfaces? VLANs? taps? bridges? etc.

Post by Andrew Shadura
Sometimes dnsmasq-dhcp
reacts to the DHCP packets coming from the interfaces it's not
supposed to work with, and as they hasn't been configured yet dnsmasq
complains.

Again, I'm interpreting here, but I'll assume you mean that on some
(dynamic?) interfaces where the host is supposed to be a client,
its dnsmasq actually does answer DHCP requests. I would understand how
this happens if you already use bind-dynamic, otherwise I don't see how
this is possible.

Post by Andrew Shadura
Having looked at the code, I see the warning is issued when
dnsmasq-dhcp has detected the interface hasn't got an address, before
it checks the interface name or exclusion lists. That doesn't seem
right to me, but I haven't come up with a reasonable patch yet.
Could that please be fixed?

I beliveve it is perfectly right that dnsmasq can only serve IPs to a
network segment it knows the IP subnet of, and that knowledge comes
from the interface to that segment having an IP itself.

So the problem comes from dnsmasq listening on an up but unconfigured
interface.

So either dnsmasq should listen on this interface, and then it is wrong
that this interface has no IP, or dnsmasq should not listen on this
interface, and it was a mistake to let it.

Or dnsmasq is receiving requests on an interface which should not
present them but does because of your local (virtual, vlan, tap,
bridge...) interface setup.

Of course, without more info on your setup, I might be wrong, and
possible am. So can you please elaborate on your host's networking
setup?

Post by Andrew Shadura
Thanks.

Amicalement,

[Andrew Shadura]

Post by Albert ARIBAUD
Hi,
Le Thu, 25 Aug 2016 11:52:41 +0300

Post by Andrew Shadura
Hello,
We've run into an issue: in our configuration, there are many
interfaces, some of them are being served by dnsmasq-dhcp, some of
them use run dhcp client themselves.

Not sure I'm getting this right, but I assume you mean on some
interfaces the host running your dnsmasq is DHCP server, and on some it
is DHCP client.

Yes, that's correct.

Post by Albert ARIBAUD

Post by Andrew Shadura
Interfaces come and go, so it's
not always possible to use bind-interfaces.

This seems to imply that dnsmasq should serve (at least some) of these
dynamic interfaces. If all dynamic interfaces should be served, then
AFAIU bind-dynamic is what you need. Otherwise, you need some ad hoc
means discriminate beweeen 'client' and 'server' dynamic interfaces.

There are .conf snippets for those 'server' interfaces with interface=
keyword specifying the interface name.

Post by Albert ARIBAUD
Also, you haven't said how these interfaces come and go. Are they
virtual interfaces? VLANs? taps? bridges? etc.

They are VLANs on hotplugged Ethernet interfaces, we use ifplugd to
bring some of them up and down when the link state changes.

Post by Albert ARIBAUD

Post by Andrew Shadura
Sometimes dnsmasq-dhcp
reacts to the DHCP packets coming from the interfaces it's not
supposed to work with, and as they hasn't been configured yet dnsmasq
complains.

Again, I'm interpreting here, but I'll assume you mean that on some
(dynamic?) interfaces where the host is supposed to be a client,
its dnsmasq actually does answer DHCP requests. I would understand how
this happens if you already use bind-dynamic, otherwise I don't see how
this is possible.

We don't use bind-dynamic. From what I see, bind-dynamic may be useful
but what I don't like about it is that it also handles new unknown
interfaces — that may be not acceptable in our case.

Post by Albert ARIBAUD

Post by Andrew Shadura
Having looked at the code, I see the warning is issued when
dnsmasq-dhcp has detected the interface hasn't got an address, before
it checks the interface name or exclusion lists. That doesn't seem
right to me, but I haven't come up with a reasonable patch yet.
Could that please be fixed?

I beliveve it is perfectly right that dnsmasq can only serve IPs to a
network segment it knows the IP subnet of, and that knowledge comes
from the interface to that segment having an IP itself.
So the problem comes from dnsmasq listening on an up but unconfigured
interface.
So either dnsmasq should listen on this interface, and then it is wrong
that this interface has no IP, or dnsmasq should not listen on this
interface, and it was a mistake to let it.

Sure, obviously. The issue as I understand it is that this particular
option isn't implemented correctly, as the code first attempts to get
the address of the interface, and checks its name only if it succeeds,
so it issues warnings also for interfaces explicitly excluded by the user.

Post by Albert ARIBAUD
Or dnsmasq is receiving requests on an interface which should not
present them but does because of your local (virtual, vlan, tap,
bridge...) interface setup.
Of course, without more info on your setup, I might be wrong, and
possible am. So can you please elaborate on your host's networking
setup?

[Andrew Shadura]

Post by Albert ARIBAUD
Or dnsmasq is receiving requests on an interface which should not
present them but does because of your local (virtual, vlan, tap,
bridge...) interface setup.
Of course, without more info on your setup, I might be wrong, and
possible am. So can you please elaborate on your host's networking
setup?

Okay, let me give you a more specific example, with just one of the
interfaces.

Let's say we've got eth0 with vlans:
eth0.1, static config
eth0.2, static config + dhcp server
eth0.3, dhcp client

Interfaces may or may not be brought up on boot, or may be brought up on
demand by the user. Some of the machines have a different set of
interfaces, and we ship a universal set of configuration files with
configuation for all possible interfaces different machines have
(interface names don't overlap).

[Andrew Shadura]

Post by Andrew Shadura
Okay, let me give you a more specific example, with just one of the
interfaces.
eth0.1, static config
eth0.2, static config + dhcp server
eth0.3, dhcp client

So, let's say we've configured eth0.1 and eth0.2, then started dnsmasq.
It complains eth3.4 (an interface expected on a different machine)
doesn't exist, so it'll skip and ignore it, and then it starts listening
on eth0.2.

Next, we bring eth0.3 up. DHCP client starts, and then dnsmasq starts
complaining it's received a DHCP packet on eth0.3 it didn't expect.

As I can see in the code, the first thing dnsmasq does for a packet
received on some interface is that it attempts to determine the
interface address. If that fails, none of the checks, which are further
down in the code, are performed.

Post by Andrew Shadura
Interfaces may or may not be brought up on boot, or may be brought up on
demand by the user. Some of the machines have a different set of
interfaces, and we ship a universal set of configuration files with
configuation for all possible interfaces different machines have
(interface names don't overlap).

[Albert ARIBAUD]

Bonjour,

Le Thu, 25 Aug 2016 13:32:56 +0300

Post by Andrew Shadura

Post by Andrew Shadura
Okay, let me give you a more specific example, with just one of the
interfaces.
eth0.1, static config
eth0.2, static config + dhcp server
eth0.3, dhcp client

So, let's say we've configured eth0.1 and eth0.2, then started
dnsmasq. It complains eth3.4 (an interface expected on a different
machine) doesn't exist, so it'll skip and ignore it, and then it
starts listening on eth0.2.
Next, we bring eth0.3 up. DHCP client starts, and then dnsmasq starts
complaining it's received a DHCP packet on eth0.3 it didn't expect.
As I can see in the code, the first thing dnsmasq does for a packet
received on some interface is that it attempts to determine the
interface address. If that fails, none of the checks, which are
further down in the code, are performed.

I believe the following is correct behavior:

- if dnsmasq received a DHCP packet on some interface, it is because the
system considered that this packet should be sent to dnsmasq.

- if dnsmasq receives a DHCP packet on an interface, it can only be
because dnsmasq should serve DHCP requests on the segment to which
this interface belongs.

- but dnsmasq can only serve DHCP requests on a segment with IPs from
the subnet of this segment, and it can only tell which subnet this
segment is on if the interface has an IP and netmask.

Applied to your case, it seems like dnsmasq receives DHCP requests on
eth0.3 which does not have an IP and netmask, and therefore rightly
complain about that.

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
excluded from this list, and whether dnsmasq actually listens only to
the given list of interfaces.

Amicalement,

[Albert ARIBAUD]

Le Thu, 25 Aug 2016 18:45:09 +0200

Post by Albert ARIBAUD
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.

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...

Post by Albert ARIBAUD
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/

Post by Albert ARIBAUD
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.

Amicalement,

[r***@gmail.com]

Post by Albert ARIBAUD
Le Thu, 25 Aug 2016 18:45:09 +0200

Post by Albert ARIBAUD
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.

Post by Albert ARIBAUD
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...

Post by Albert ARIBAUD
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/

Post by Albert ARIBAUD
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.

[Simon Kelley]

Post by Andrew Shadura

Post by Andrew Shadura
Okay, let me give you a more specific example, with just one of the
interfaces.
eth0.1, static config
eth0.2, static config + dhcp server
eth0.3, dhcp client

So, let's say we've configured eth0.1 and eth0.2, then started dnsmasq.
It complains eth3.4 (an interface expected on a different machine)
doesn't exist, so it'll skip and ignore it, and then it starts listening
on eth0.2.
Next, we bring eth0.3 up. DHCP client starts, and then dnsmasq starts
complaining it's received a DHCP packet on eth0.3 it didn't expect.
As I can see in the code, the first thing dnsmasq does for a packet
received on some interface is that it attempts to determine the
interface address. If that fails, none of the checks, which are further
down in the code, are performed.

This is definitely a real bug. This patch should fix it, and apply
easily to earlier versions, if you so wish.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=e94ad0fa01ccc8d0c39e069ab29b008f9c811600


Cheers,

Simon.

[Andrew Shadura]

Post by Simon Kelley

Post by Andrew Shadura
As I can see in the code, the first thing dnsmasq does for a packet
received on some interface is that it attempts to determine the
interface address. If that fails, none of the checks, which are further
down in the code, are performed.

This is definitely a real bug. This patch should fix it, and apply
easily to earlier versions, if you so wish.
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=e94ad0fa01ccc8d0c39e069ab29b008f9c811600

Thanks, Simon, that’s about how I was going to fix it, but I wasn’t sure
it was the right thing to do.