[Dnsmasq-discuss] [PATCH] Add support for binding to both interface and IP

2016-09-18 Thread Kristian Evensen 
The current --server syntax allows for binding to interface or address. However,
in some (admittedly special) cases it is useful to be able to specify both. This
commit introduces the following syntax to support binding to both interface and
address:

--server X.X.X.X@IP@interface#port

Based on my tests, the syntax is backwards compatible with the current
@IP/interface#port. The code will fail if two interface names are given.

Signed-off-by: Kristian Evensen 
---
 src/option.c | 36 
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/src/option.c b/src/option.c
index d0d9509..bcb19a9 100644
--- a/src/option.c
+++ b/src/option.c
@@ -757,6 +757,7 @@ char *parse_server(char *arg, union mysockaddr *addr, union 
mysockaddr *source_a
 {
   int source_port = 0, serv_port = NAMESERVER_PORT;
   char *portno, *source;
+  char *interface_opt = NULL;
 #ifdef HAVE_IPV6
   int scope_index = 0;
   char *scope_id;
@@ -782,6 +783,19 @@ char *parse_server(char *arg, union mysockaddr *addr, 
union mysockaddr *source_a
   scope_id = split_chr(arg, '%');
 #endif
   
+  if (source) {
+interface_opt = split_chr(source, '@');
+
+if (interface_opt)
+  {
+#if defined(SO_BINDTODEVICE)
+   strncpy(interface, interface_opt, IF_NAMESIZE - 1);
+#else
+   return _("interface binding not supported");
+#endif
+  }
+  }
+
   if (inet_pton(AF_INET, arg, &addr->in.sin_addr) > 0)
 {
   addr->in.sin_port = htons(serv_port);
@@ -800,8 +814,15 @@ char *parse_server(char *arg, union mysockaddr *addr, 
union mysockaddr *source_a
  if (!(inet_pton(AF_INET, source, &source_addr->in.sin_addr) > 0))
{
 #if defined(SO_BINDTODEVICE)
- source_addr->in.sin_addr.s_addr = INADDR_ANY;
- strncpy(interface, source, IF_NAMESIZE - 1);
+ if (interface_opt)
+   {
+ return _("interface can only be specified once");
+   }
+ else 
+   {
+ source_addr->in.sin_addr.s_addr = INADDR_ANY;
+ strncpy(interface, source, IF_NAMESIZE - 1);
+   }
 #else
  return _("interface binding not supported");
 #endif
@@ -832,8 +853,15 @@ char *parse_server(char *arg, union mysockaddr *addr, 
union mysockaddr *source_a
  if (inet_pton(AF_INET6, source, &source_addr->in6.sin6_addr) == 0)
{
 #if defined(SO_BINDTODEVICE)
- source_addr->in6.sin6_addr = in6addr_any; 
- strncpy(interface, source, IF_NAMESIZE - 1);
+ if (interface_opt)
+   {
+ return _("interface can only be specified once");
+   }
+ else
+   {
+ source_addr->in6.sin6_addr = in6addr_any;
+ strncpy(interface, source, IF_NAMESIZE - 1);
+   }
 #else
  return _("interface binding not supported");
 #endif
-- 
2.5.0


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Add support for binding to both interface and IP

2017-03-17 Thread Kristian Evensen 
A gentle ping on this patch :)

I tried to look, but couldn't find out the correct way of submitting
patches to dnsmasq, so I don't know if there is somewhere else it
should be sent?

Thanks,
Kristian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Add support for binding to both interface and IP

2017-03-17 Thread Kristian Evensen 
On Fri, Mar 17, 2017 at 10:52 PM, Simon Kelley  wrote:
> This slipped through, apologies. You're doing everything right, _except_
> that a patch which includes the relevant changes to the man page would
> make my life easier.

Thanks for letting me know. Will submit a v2 with the matching man-page update.

Have a nice weekend!

-Kristian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [PATCH v2] Add support for binding to both interface and IP

2017-03-20 Thread Kristian Evensen 
The current --server syntax allows for binding to interface or address. However,
in some (admittedly special) cases it is useful to be able to specify both. This
commit introduces the following syntax to support binding to both interface and
address:

--server X.X.X.X@IP@interface#port

Based on my tests, the syntax is backwards compatible with the current
@IP/interface#port. The code will fail if two interface names are given.

v1->v2:
* Add man page description of the extended server syntax (thanks Simon Kelley)

Signed-off-by: Kristian Evensen 
---
 man/dnsmasq.8 | 16 
 src/option.c  | 36 
 2 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 059eafc..2e5ef21 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -467,14 +467,14 @@ to make configuration files clearer in this case.
 IPv6 addresses may include a %interface scope-id, eg
 fe80::202:a412:4512:7bbf%eth0.
 
-The optional string after the @ character tells
-dnsmasq how to set the source of the queries to this
-nameserver. It should be an ip-address, which should belong to the machine on 
which
-dnsmasq is running otherwise this server line will be logged and then
-ignored, or an interface name. If an interface name is given, then
-queries to the server will be forced via that interface; if an
-ip-address is given then the source address of the queries will be set
-to that address.
+The optional string after the @ character tells dnsmasq how to set the source 
of
+the queries to this nameserver. It can either be an ip-address, an interface
+name or both. The ip-address should belong to the machine on which dnsmasq is
+running, otherwise this server line will be logged and then ignored. If an
+interface name is given, then queries to the server will be forced via that
+interface; if an ip-address is given then the source address of the queries 
will
+be set to that address; and if both are given then a combination of ip-address
+and interface name will be used to steer requests to the server.
 The query-port flag is ignored for any servers which have a
 source address specified but the port may be specified directly as
 part of the source address. Forcing queries to an interface is not
diff --git a/src/option.c b/src/option.c
index 31c8cb9..45bd34d 100644
--- a/src/option.c
+++ b/src/option.c
@@ -757,6 +757,7 @@ char *parse_server(char *arg, union mysockaddr *addr, union 
mysockaddr *source_a
 {
   int source_port = 0, serv_port = NAMESERVER_PORT;
   char *portno, *source;
+  char *interface_opt = NULL;
 #ifdef HAVE_IPV6
   int scope_index = 0;
   char *scope_id;
@@ -782,6 +783,19 @@ char *parse_server(char *arg, union mysockaddr *addr, 
union mysockaddr *source_a
   scope_id = split_chr(arg, '%');
 #endif
   
+  if (source) {
+interface_opt = split_chr(source, '@');
+
+if (interface_opt)
+  {
+#if defined(SO_BINDTODEVICE)
+   strncpy(interface, interface_opt, IF_NAMESIZE - 1);
+#else
+   return _("interface binding not supported");
+#endif
+  }
+  }
+
   if (inet_pton(AF_INET, arg, &addr->in.sin_addr) > 0)
 {
   addr->in.sin_port = htons(serv_port);
@@ -800,8 +814,15 @@ char *parse_server(char *arg, union mysockaddr *addr, 
union mysockaddr *source_a
  if (!(inet_pton(AF_INET, source, &source_addr->in.sin_addr) > 0))
{
 #if defined(SO_BINDTODEVICE)
- source_addr->in.sin_addr.s_addr = INADDR_ANY;
- strncpy(interface, source, IF_NAMESIZE - 1);
+ if (interface_opt)
+   {
+ return _("interface can only be specified once");
+   }
+ else
+   {
+ source_addr->in.sin_addr.s_addr = INADDR_ANY;
+ strncpy(interface, source, IF_NAMESIZE - 1);
+   }
 #else
  return _("interface binding not supported");
 #endif
@@ -832,8 +853,15 @@ char *parse_server(char *arg, union mysockaddr *addr, 
union mysockaddr *source_a
  if (inet_pton(AF_INET6, source, &source_addr->in6.sin6_addr) == 0)
{
 #if defined(SO_BINDTODEVICE)
- source_addr->in6.sin6_addr = in6addr_any; 
- strncpy(interface, source, IF_NAMESIZE - 1);
+ if (interface_opt)
+   {
+ return _("interface can only be specified once");
+   }
+ else
+   {
+ source_addr->in6.sin6_addr = in6addr_any;
+ strncpy(interface, source, IF_NAMESIZE - 1);
+   }
 #else
  return _("interface binding not supported");
 #endif
-- 
2.9.3


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [PATCH] Support --server syntax in resolv-file

2017-03-23 Thread Kristian Evensen 
Automatically specifying which source address and interface to be used for
communicating with a given DNS server is very convenient on multihomed hosts.
Two use-cases I have had for this feature are:

* Several mobile broadband providers hand out private IP-addresses, but the DNS
servers are global. Unless special routing rules are added, then the default
route will be used for resolving domains. This is not ideal, as it might lead to
higher latencies for replies, or an additional cost to the user if DNS requests
to the "local" servers are free.

* Several mobile broadband devices act as small routers, and some of the most
popular types only hand out the same IP, DNS server, etc. To make matters worse,
if these devices loose connectivity, they will highjack any DNS request and
reply with its own IP. If you have multiple of these devices, you risk being
stuck without working DNS as all requests might be forwarded to the disconnected
device. Adding support for binding to interface and IP will make sure that
requests are sent to the correct device. Some external tool will still be
required to check that DNS is working fine and updating the resolv-file
accordingly.

Dnsmasq already supports reading and binding to an ip-adress/interface through
the --server option. This patch adds support for specifying which source address
and/or interface to use for a server in the resolv-file, using the same syntax
as for --server. For example, in order to specify that source ip 100.76.125.47
and interface wwan1 should be used to communicate with server 213.158.199.1, the
following line would have to be added to the resolv-file:

nameserver 213.158.199.1@100.76.125.47@wwan1

Since the syntax is not standard, the --multihomed-resolver command line option
must be enabled. Please note that lines with and without source
address/interface can be mixed.

Since we now have two places where the interface-part of --server is parsed, I
have factored out this parsing into a separate function. parse_server() is
converted to use this function.

Signed-off-by: Kristian Evensen 
---
 man/dnsmasq.8 | 10 +++
 src/dnsmasq.h |  3 +-
 src/network.c | 96 +++
 src/option.c  | 68 --
 4 files changed, 141 insertions(+), 36 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 2e5ef21..05a8db1 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -1884,6 +1884,16 @@ A special case of
 which differs in two respects. Firstly, only --server and --rev-server are 
allowed 
 in the configuration file included. Secondly, the file is re-read and the 
configuration
 therein is updated when dnsmasq receives SIGHUP.
+.TP
+.B --multihomed-resolver
+Enable support for binding nameservers read from resolv-conf to an ip-address
+and interface, using the same syntax as for --server. In order to use a given
+ip-address/interface for a given nameserver, the nameserver line must follow 
the
+following format:
+.B nameserver @@
+Note that specifying only an ip-address or interface name is supported, and
+nameserver lines with and without ip-adress/interface can be mixed.
+
 .SH CONFIG FILE
 At startup, dnsmasq reads
 .I /etc/dnsmasq.conf,
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 6b44e53..f65de13 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -238,7 +238,8 @@ struct event_desc {
 #define OPT_SCRIPT_ARP 53
 #define OPT_MAC_B6454
 #define OPT_MAC_HEX55
-#define OPT_LAST   56
+#define OPT_MULTIH_RESOLV  56
+#define OPT_LAST   57
 
 /* extra flags for my_syslog, we use a couple of facilities since they are 
known 
not to occupy the same bits as priorities, no matter how syslog.h is set 
up. */
diff --git a/src/network.c b/src/network.c
index e5ceb76..65ae50c 100644
--- a/src/network.c
+++ b/src/network.c
@@ -16,6 +16,9 @@
 
 #include "dnsmasq.h"
 
+char *split_server(char *arg, char **source, char **scope_id,
+  char **interface_opt, int *source_port, int *serv_port);
+
 #ifdef HAVE_LINUX_NETWORK
 
 int indextoname(int fd, int index, char *name)
@@ -1437,7 +1440,7 @@ void add_update_server(int flags,
serv->flags |= SERV_HAS_DOMAIN;
   
   if (interface)
-   strcpy(serv->interface, interface);  
+   strncpy(serv->interface, interface, IF_NAMESIZE - 1);
   if (addr)
serv->addr = *addr;
   if (source_addr)
@@ -1618,8 +1621,16 @@ int reload_servers(char *fname)
   while ((line = fgets(daemon->namebuff, MAXDNAME, f)))
 {
   union mysockaddr addr, source_addr;
+  int source_port = daemon->query_port, serv_port = NAMESERVER_PORT;
+  char *split_server_error;
+  char *source = NULL, *interface_opt = NULL;
+#ifdef HAVE_IPV6
+  int scope_index = 0;
+  char *scope_id = NULL;
+#endif
+
   char *token = strtok(line, " \t\n\r");
-  
+
   if (!token)
continue;
   if (strcmp(to

Re: [Dnsmasq-discuss] [PATCH] Support --server syntax in resolv-file

2017-04-06 Thread Kristian Evensen 
Hi,

A gentle ping for this patch, in case it got lost when moving house, etc. :)

Best regards,
Kristian
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Support --server syntax in resolv-file

2017-04-07 Thread Kristian Evensen 
Hi Simon,

On Sat, 8 Apr 2017 at 00:21, Simon Kelley  wrote:

> I understand the desire to be able to specify resolvers dynamically with
> the full set of source-address and routing options; that's actually
> already available, and has been for a long time, using the DBus
> interface to dnsmasq, which includes the "SetDomainServers" method,
> which takes strings identical to argument to --server. I've not looked
> at the code, but your previous patch to allow binding both IP and
> interface should have automatically added that feature to
> SetDomainServers. (if it didn't then I'd certainly take a patch to
> correct that.)


Thanks for pointing me to the DBus-interface, that does indeed sound like
the correct approach. I will test if SetDomaimServers automatically support
the server/interface/adress syntax, and provide a patch if not.

Have a nice weekend,
Kristian


>
>
> Cheers,
>
> Simon.
>
>
>
> On 23/03/17 18:16, Kristian Evensen wrote:
> > Automatically specifying which source address and interface to be used
> for
> > communicating with a given DNS server is very convenient on multihomed
> hosts.
> > Two use-cases I have had for this feature are:
> >
> > * Several mobile broadband providers hand out private IP-addresses, but
> the DNS
> > servers are global. Unless special routing rules are added, then the
> default
> > route will be used for resolving domains. This is not ideal, as it might
> lead to
> > higher latencies for replies, or an additional cost to the user if DNS
> requests
> > to the "local" servers are free.
> >
> > * Several mobile broadband devices act as small routers, and some of the
> most
> > popular types only hand out the same IP, DNS server, etc. To make
> matters worse,
> > if these devices loose connectivity, they will highjack any DNS request
> and
> > reply with its own IP. If you have multiple of these devices, you risk
> being
> > stuck without working DNS as all requests might be forwarded to the
> disconnected
> > device. Adding support for binding to interface and IP will make sure
> that
> > requests are sent to the correct device. Some external tool will still be
> > required to check that DNS is working fine and updating the resolv-file
> > accordingly.
> >
> > Dnsmasq already supports reading and binding to an ip-adress/interface
> through
> > the --server option. This patch adds support for specifying which source
> address
> > and/or interface to use for a server in the resolv-file, using the same
> syntax
> > as for --server. For example, in order to specify that source ip
> 100.76.125.47
> > and interface wwan1 should be used to communicate with server
> 213.158.199.1, the
> > following line would have to be added to the resolv-file:
> >
> > nameserver 213.158.199.1@100.76.125.47@wwan1
> >
> > Since the syntax is not standard, the --multihomed-resolver command line
> option
> > must be enabled. Please note that lines with and without source
> > address/interface can be mixed.
> >
> > Since we now have two places where the interface-part of --server is
> parsed, I
> > have factored out this parsing into a separate function. parse_server()
> is
> > converted to use this function.
> >
>
>
> ___
> 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

Re: [Dnsmasq-discuss] [PATCH] Support --server syntax in resolv-file

2017-04-10 Thread Kristian Evensen 
Hi Simon,

On Fri, Apr 7, 2017 at 11:27 PM, Simon Kelley  wrote:
> The overriding objection to this is that it adds to the syntax and
> semantics of the resolv-file format, but dnsmasq doesn't "own" that
> format: it's actually a libc configuration file, and dnsmasq takes
> advantage of the fact that the format is "well known" to extract useful
> information from it. If you start adding extra fields to
> /etc/resolv.conf then the c-library will get upset.

I have been thinking some more about this. The reason for locking the
support for server-strings in the resolv behind a command line option,
was to avoid what you are describing here - compatibility issues with
the existing resolv-file format. I assume that if anyone enables the
option, they know what they are doing and what implications it might
have. I should maybe have explained this better in either the commit
or the addition to the man-page.

> I understand the desire to be able to specify resolvers dynamically with
> the full set of source-address and routing options; that's actually
> already available, and has been for a long time, using the DBus
> interface to dnsmasq, which includes the "SetDomainServers" method,
> which takes strings identical to argument to --server. I've not looked
> at the code, but your previous patch to allow binding both IP and
> interface should have automatically added that feature to
> SetDomainServers. (if it didn't then I'd certainly take a patch to
> correct that.)

I did a quick test and it seems that specifying servers (with the
additional interface/ip-information) using the DBus-interface works
fine. However, this does not help on systems not using DBus (like
OpenWRT/LEDE). Do you have any suggestions for an acceptable way to
implement this feature, without requiring the use DBus?

Thanks in advance for the help,
Kristian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Support --server syntax in resolv-file

2017-04-10 Thread Kristian Evensen 
Hi,

On Mon, Apr 10, 2017 at 1:53 PM, Vladislav Grishenko
 wrote:
> FYI, changing resolv.conf format could lead libc resolver to fail, so it's 
> quite dangerous change.
> As I understand, you want dynamic DNS servers update with additional info 
> (interface/src ip binding).
> With no DBUS, can't it be done with --servers-file option (available since 
> 2.69)?
> This files allow full format of --server & --rev-server and are reread on 
> SIGHUP, polling is not supported at the moment.

Thanks a lot for the pointer to this command line option. It looks
like the perfect solution to my problem :)

-Kristian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] Seg. fault in cache.c after commt b6f926fb

2018-09-18 Thread Kristian Evensen 
Hello,

I recently updated one of my x86-based OpenWRT-routers to the latest
nightly, which bumped dnsmasq to 2.80test6. After the update, I see
that dnsmasq sometimes enters a crash loop. The crash occurs right
startup (SIGSEV), and the backtrace, looks as follows:

0x00406a78 in make_non_terminals
(source=source@entry=0x77ffefa0) at cache.c:1437
1437 cache.c: No such file or directory.
(gdb) bt
#0  0x00406a78 in make_non_terminals
(source=source@entry=0x77ffefa0) at cache.c:1437
#1  0x00407192 in add_hosts_entry (cache=0x77ffefa0,
addr=0x7fffea28, addrlen=4, index=2, rhash=,
hashsz=) at cache.c:911
#2  0x004074e1 in read_hostsfile
(filename=filename@entry=0x425a8a "/etc/hosts", index=index@entry=2,
cache_size=cache_size@entry=150, rhash=0x635020,
hashsz=hashsz@entry=641) at cache.c:1040
#3  0x00407810 in cache_reload () at cache.c:1185
#4  0x00418037 in clear_cache_and_reload
(now=now@entry=1537265437) at dnsmasq.c:1547
#5  0x00405ec3 in async_event (now=1537265437, pipe=15) at
dnsmasq.c:1310
#6  main (argc=, argv=) at dnsmasq.c:1077

My current work-around is to check if crecp is NULL and then return
from make_non_terminals(). However, I don't know the code well enough
to know if this change will break anything else (though everything
seems to work fine).

There is nothing special with my hosts file, it looks as follows:

127.0.0.1 localhost

::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
192.168.5.1 myrouter.lan

If checking for NULL is acceptable, I will be more than happy to send
my patch. If not, I wonder if anyone has any hints on how to proceed
to solve this issue?

BR,
Kristian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Seg. fault in cache.c after commt b6f926fb

2018-09-19 Thread Kristian Evensen 
Hi Simon,

Thanks for a quick reply.

On Wed, Sep 19, 2018 at 12:23 AM Simon Kelley  wrote:
> Thanks for the report. The obvious explanation is that whine_malloc() is
> returning NULL, and the code should handle that. whine_malloc only
> returns NULL if the system cannot allocate any more memory, which is
> possible, but unlikely. Is your router very short on memory?

No, the router has plenty of memory (2GB) and I don't see the "failed
to allocate"-message, so I guess whine_malloc() can't be the culprit.
Since I am using OpenWRT, there could be some defines affecting the
line numbers. I tried to read up on how ifdefs affects line numbers in
gdb backtraces to see if the error could be somewhere else than the
"default" line 1437, but I unfortunately couldn't find anything.
Probably my google-foo is a bit rusty.

When looking over my notes, I see that I have made the following
observations related to this bug:

* Crash happens quite rarely.
* I have only seen the bug right after boot.
* When the bug strikes, dnsmasq will enter a crash loop and never
recover. I.e., I can restart dnsmasq as many times as I like, crash
always happens.
* If I start dnsmasq manually and run it in the foreground after a
crash, I also see the error.

So there seems to be something in the system causing this error, but I
can't figure out what.

> I think the best solution is to wrap all of
>
>   *crecp = *source;
>   crecp->flags &= ~(F_IPV4 | F_IPV6 | F_CNAME | F_DNSKEY | F_DS |
> F_REVERSE);
>   crecp->flags |= F_NAMEP;
>   crecp->name.namep = name;
>
>   cache_hash(crecp);
>
> with
>
> if (crecp)
> {
> }

Thanks, this is basically the same as my current fix, so I can already
report that it is good :)

BR,
Kristian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Seg. fault in cache.c after commt b6f926fb

2018-09-19 Thread Kristian Evensen 
On Wed, Sep 19, 2018 at 1:44 PM Simon Kelley  wrote:
> This all makes me slightly uneasy. I think the "out of memory"
> explanation for the crashes you are seeing is not a good one.

No, I agree. I have compiled an OpenWRT image without the fix and
installed it on my device, and I am trying to reproduce the issue.
Will let you know when or if I figure out something.

BR,
Kristian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] dnsmasq stops receiving packets after network restart

2018-09-24 Thread Kristian Evensen 
Hello,

I have some routers running OpenWRT (latest nightly) and that I have
to access remotely (using reverse SSH). When I restart networking
(/etc/init.d/network restart), clients on the LAN can no longer obtain
an IP address using DHCP. If I restart networking locally, DHCP works
as expected after the network is back up.

In order to try and figure out what is going on, I have checked/tried
the following:

* I started out by checking if dnsmasq has been restarted and if the
DHCP socket has been created. I can always see the socket in netstat.
* I then took a look at the firewall. I can see the DHCP packets in
the INPUT chain in filter, which according to my understanding of
Netfilter-internals is the last stop before a packet is delivered to a
socket.
* I then instrumented dnsmasq and added some logging in dhcp_packet()
in dhcp.c. This function is never called, as none of my log-messages
are written to syslog. I checked that the logging works by checking
for my messages when DHCP is working.
* Restarting dnsmasq makes DHCP work again. I can't see any difference
in for example netstat-output.

Does anyone have any idea on what to try or where to look next? After
having spent a couple of days on this issue, I am quickly starting to
run out of ideas.

Thanks in advance for any help,
Kristian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq stops receiving packets after network restart

2018-09-27 Thread Kristian Evensen 
Hi Simon,

On Wed, Sep 26, 2018 at 7:30 PM Simon Kelley  wrote:
> Simplest test is to make whichdevice always return NULL, and see if that
> helps.

Making whichdevice() always return NULL makes the issue go away.
Without the change, DHCP after a network restart (which triggers
recreating devices) only works after I manually restart dnsmasq. With
the change, DHCP works fine. Chainging dnsmasq to use two interfaces
also makes the issue disappear. I unfortunately do not know what has
suddenly triggered this error. I see that the code in whichdevice() is
from 2012/2013, so it must be something in a different component.

Carrying a local patch is no problem for me, but I guess a generic
solution is desirable. Would a patch adding a configuration option be
acceptable?

BR,
Kristian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq stops receiving packets after network restart

2018-09-27 Thread Kristian Evensen 
Hi,

On Thu, Sep 27, 2018 at 9:53 PM Simon Kelley  wrote:
> Progress. AFAIK, the dnsmasq behaviour around this has not changed at al
> in that time period. I think it's likely that the change is in the
> OpenWRT network infrastructure, maybe hotplug/coldplug stuff that now
> destroys and re-creates the kernel-level network device, rather than
> just reloading its configuration.
>
> I run the bleeding edge dnsmasq code (we suffer so you don't have too!)
> on an old, stable Chaos-calmer OpenWRT install, and I'm not seeing this
> effect, which adds weight to the theory that the change is elsewhere.

Yes, I agree. I also haven't seen this error up until recently, so
there is something else that has broken. I will try to dig a bit when
or if I have time, and see if I can discover something.

> Dnsmasq is quite clever at handling changes in kernel network level
> devices under its feet, maybe there's a way to re-bind when that
> happens? I'll have a look. A configuration option  would be the last
> resort here: adding "pull this lever to make it work" options is
> something I try and avoid.

I agree here as well. I checked if there was a socket event we were
missing, but at least no event was received on my boxes. I guess the
most elegant approach would be to monitor RTNLGRP_LINK for DELLINK,
and close the socket when DELLINK arrives. The socket could then be
recreated on NEWLINK, or, proably even better, NEWADDR.

BR,
Kristian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] dnsmasq and option 78

2020-03-09 Thread Kristian Evensen 
Hello,

I am trying to configure dnsmasq to export DHCP option 78 (rfc2610) to
the clients on my network, but I am struggling to make it work. My
problems seems to be caused by the "Mandatory" byte that has to be
part of the option.

My initial attempt was to add the following to dnsmasq.conf:
dhcp-option-force=78,1,192.168.5.14

However, this caused dnsmasq to fail with the following error message:
Mon Mar  9 11:55:55 2020 daemon.crit dnsmasq[3232]: bad IPv4 address
at line 38 of /etc/dnsmasq.conf

I then tried to replace "1" with 0x01 and 1b, but in my packet capture
I see that the values are sent as strings (so "0x01" and "1b"). I then
tried to just add 1 (so dhcp-option-force=78,1), which worked in the
sense that dnsmasq did not fail to start and an integer was sent to my
client.

Has anyone managed to configure dnsmasq to export option 78 or know
how to combine an integer with an address list? My router is running
dnsmasq verson 2.80.

Thanks in advance for any help,
Kristian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq and option 78

2020-03-11 Thread Kristian Evensen 
Hi Simon & Geert,

Thanks a lot for your replies!

On Tue, Mar 10, 2020 at 11:46 PM Simon Kelley  wrote:
> dhcp-option-force=78,01:c0:a8:05:0e

I just tried this and it works great, thanks a lot for pointing me in
this direction. As a temporary work-around, I patched dnsmasq to treat
the first part of the DHCP option (so the 1) in a special way if the
option equals 78 + insert the value at the head of the DHCP request
(as for the SIP server option). I can prepare and submit a patch, but
I guess you have a more generic solution in mind?

BR,
Kristian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss