Re: [Dnsmasq-discuss] DHCP packet received on which has no address
Le Thu, 25 Aug 2016 18:45:09 +0200 Albert ARIBAUD 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. 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. Amicalement, -- Albert. pgpsvuNnlZf_Z.pgp Description: Signature digitale OpenPGP ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCP packet received on which has no address
Bonjour, Le Thu, 25 Aug 2016 13:32:56 +0300 Andrew Shadura a écrit: > On 25/08/16 13:26, Andrew Shadura wrote: > > 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 > > 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. pgppWQSwf6cAX.pgp Description: Signature digitale OpenPGP ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] Refresh cached socket fd if the interface index changed
The socket bound to a specific interface in the daemon->sfds cache is
reused also when the interface disappears and is created again,
causing resolution problems.
This problem can be seen when connecting to VPNs with NetworkManager:
when the VPN is connected NM pushes through D-Bus a configuration
containing the upstream server '1.2.3.4@tun0' and dnsmasq creates a
socket bound to tun0. Later, the VPN is reconnected and tun0 reappears
with a different ifindex; but even if the server list is updated again
(still containing an upstream server on tun0), dnsmasq tries to use
the old socket and any DNS request fails.
This patch adds a check on the ifindex in allocate_sfd() to prevent
the reuse of a stale socket, and ensures that unused sockets are
destroyed.
---
src/dnsmasq.h | 2 ++
src/network.c | 29 +++--
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 27385a9..462aaf5 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -487,8 +487,10 @@ union mysockaddr {
struct serverfd {
int fd;
union mysockaddr source_addr;
char interface[IF_NAMESIZE+1];
+ unsigned int ifindex;
+ unsigned int used;
struct serverfd *next;
};
struct randfd {
diff --git a/src/network.c b/src/network.c
index e7722fd..bcb4d1f 100644
--- a/src/network.c
+++ b/src/network.c
@@ -1203,8 +1203,9 @@ int local_bind(int fd, union mysockaddr *addr, char
*intname, int is_tcp)
static struct serverfd *allocate_sfd(union mysockaddr *addr, char *intname)
{
struct serverfd *sfd;
+ unsigned int ifindex = 0;
int errsave;
/* when using random ports, servers which would otherwise use
the INADDR_ANY/port0 socket have sfd set to NULL */
@@ -1223,14 +1224,19 @@ static struct serverfd *allocate_sfd(union mysockaddr
*addr, char *intname)
addr->in6.sin6_port == htons(0))
return NULL;
#endif
}
+
+ if (intname)
+ifindex = if_nametoindex(intname);
/* may have a suitable one already */
for (sfd = daemon->sfds; sfd; sfd = sfd->next )
if (sockaddr_isequal(&sfd->source_addr, addr) &&
- strcmp(intname, sfd->interface) == 0)
+ strcmp(intname, sfd->interface) == 0 &&
+ ifindex == sfd->ifindex) {
return sfd;
+}
/* need to make a new one. */
errno = ENOMEM; /* in case malloc fails. */
if (!(sfd = whine_malloc(sizeof(struct serverfd
@@ -1249,13 +1255,15 @@ static struct serverfd *allocate_sfd(union mysockaddr
*addr, char *intname)
free(sfd);
errno = errsave;
return NULL;
}
-
+
strcpy(sfd->interface, intname);
sfd->source_addr = *addr;
sfd->next = daemon->sfds;
+ sfd->ifindex = ifindex;
daemon->sfds = sfd;
+
return sfd;
}
/* create upstream sockets during startup, before root is dropped which may be
needed
@@ -1428,14 +1436,18 @@ void add_update_server(int flags,
void check_servers(void)
{
struct irec *iface;
struct server *serv;
+ struct serverfd *sfd, **ptr;
int port = 0, count;
/* interface may be new since startup */
if (!option_bool(OPT_NOWILD))
enumerate_interfaces(0);
+ for (sfd = daemon->sfds; sfd; sfd = sfd->next)
+sfd->used = 0;
+
#ifdef HAVE_DNSSEC
/* Disable DNSSEC validation when using server=/domain/ servers
unless there's a configured trust anchor. */
for (serv = daemon->servers; serv; serv = serv->next)
@@ -1504,8 +1516,10 @@ void check_servers(void)
daemon->namebuff, strerror(errno));
serv->flags |= SERV_MARK;
continue;
}
+
+ serv->sfd->used++;
}
if (!(serv->flags & SERV_NO_REBIND) && !(serv->flags &
SERV_LITERAL_ADDRESS))
{
@@ -1546,8 +1560,19 @@ void check_servers(void)
if (count - 1 > SERVERS_LOGGED)
my_syslog(LOG_INFO, _("using %d more nameservers"), count - SERVERS_LOGGED
- 1);
+ /* Remove unused sfds */
+ for (ptr = &daemon->sfds; *ptr; ) {
+sfd = *ptr;
+if (!sfd->used) {
+ *ptr = sfd->next;
+ close(sfd->fd);
+ free(sfd);
+} else
+ ptr = &sfd->next;
+ }
+
cleanup_servers();
}
/* Return zero if no servers found, in that case we keep polling.
--
2.5.5
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCP packet received on which has no address
On 25/08/16 13:26, Andrew Shadura wrote: > 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 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. > 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). -- Cheers, Andrew signature.asc Description: OpenPGP digital signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCP packet received on which has no address
On 25/08/16 12:55, Albert ARIBAUD wrote: > 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). -- Cheers, Andrew signature.asc Description: OpenPGP digital signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCP packet received on which has no address
On 25/08/16 12:55, Albert ARIBAUD wrote: > Hi, > > Le Thu, 25 Aug 2016 11:52:41 +0300 > Andrew Shadura a écrit: > >> 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. >> 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. > 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. >> 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. >> 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. > 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? -- Cheers, Andrew signature.asc Description: OpenPGP digital signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCP packet received on which has no address
Hi, Le Thu, 25 Aug 2016 11:52:41 +0300 Andrew Shadura a écrit: > 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. > 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. > 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. > 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? > Thanks. Amicalement, -- Albert. pgprCPNJ60dTD.pgp Description: Signature digitale OpenPGP ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Compile Error.
Or use 'make COPTS=-DNO_INOTIFY' to compile without the inotify handling, since early kernels (as used by many router manufacturers) don't have inotify support. On 24/08/16 17:14, Chris Novakovic wrote: On 24/08/16 16:31, Tony White wrote: inotify.c:92: error: ‘IN_NONBLOCK’ undeclared (first use in this function) inotify.c:92: error: (Each undeclared identifier is reported only once inotify.c:92: error: for each function it appears in.) inotify.c:92: error: ‘IN_CLOEXEC’ undeclared (first use in this function) make[1]: *** [inotify.o] Error 1 CentOS 5.11 x86_64 Your version of glibc (probably 2.5, on CentOS 5.11) is too old, and doesn't contain those flags --- the least painful route to fixing this is likely to be to upgrade to a newer CentOS release. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] DHCP packet received on which has no address
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. -- Cheers, Andrew signature.asc Description: OpenPGP digital signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
