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
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@list
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
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 |
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
---
m
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
tch 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
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 th
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
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_
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, w
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 repr
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 aft
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)
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
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
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
17 matches
Mail list logo
