Re: [Dnsmasq-discuss] Cannot send dhcp option 12 hostname to clients

[Geert Stappers]

On Tue, May 14, 2019 at 06:21:58PM -0400, Kevin Flynn wrote:
> On 5/14/19 3:15 PM, john doe wrote:
> > On 5/14/2019 6:42 PM, Kevin Flynn wrote:
> > > 
> > > hostnames to clients. I've tried all the obvious methods, including
> > > /etc/ethers, dhcp-hostsfile entries, dhcp-ignore-names,
> > > dhcp-generate-names, tag sets, etc. with no luck.
> >> ...
> > > So in summary, is there any way to tell dnsmasq to send a dhcp option 12
> > > hostname to a client reliably, everytime, regardless of what the client
> > > is sending ?
> > > 
> > 
> > Why not using the MAC address of those devices in dnsmasq?
> > 
> > "--dhcp-host=[][,id:|*][,set:][,][,][,][,ignore"
> > 
> > http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
> > 
> > 
> 
> I have tried using dhcp-host lines,

Share that dhcp-host lines with your audience here.
Make it possible that they can verify how far they match
> > "--dhcp-host=[][,id:|*][,set:][,][,][,][,ignore"

> as well as using a dhcp-hostsfile. which
> according to the man page are equivalent. These are the methods I am using
> to assign an ip address to each ATA box via MAC address.
> 
> Dnsmasq successfully sends them a domain name, a network time service
> address, a pair of DNS server addresses, a netmask and gateway address, etc.
 
Put a netwerk capture in libpcap format on-line and provide the URL to wget it.
I would like to see what goes over the wire.


> I cannot get dnsmasq to send an "option 12 hostname." I need to send all of
> the above into in the dhcp offer and in addition, set the hostname of the
> client regardless of what hostname the client thinks it is, because I have 2
> clients who assign themselves the same hostname.

Yes, that is your problem^Wchallenge. I'm interrested in knowing
how far it a dnsmasq problem is.


Groeten
Geert Stappers
-- 
Leven en laten leven

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

Re: [Dnsmasq-discuss] Cannot send dhcp option 12 hostname to clients

[Kevin Flynn]

On 5/14/19 3:15 PM, john doe wrote:

On 5/14/2019 6:42 PM, Kevin Flynn wrote:


hostnames to clients. I've tried all the obvious methods, including
/etc/ethers, dhcp-hostsfile entries, dhcp-ignore-names,
dhcp-generate-names, tag sets, etc. with no luck.

>> ...

So in summary, is there any way to tell dnsmasq to send a dhcp option 12
hostname to a client reliably, everytime, regardless of what the client
is sending ?



Why not using the MAC address of those devices in dnsmasq?

"--dhcp-host=[][,id:|*][,set:][,][,][,][,ignore"

http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

--
John Doe

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



I have tried using dhcp-host lines, as well as using a dhcp-hostsfile. 
which according to the man page are equivalent. These are the methods I 
am using to assign an ip address to each ATA box via MAC address.


Dnsmasq successfully sends them a domain name, a network time service 
address, a pair of DNS server addresses, a netmask and gateway address, etc.


I cannot get dnsmasq to send an "option 12 hostname." I need to send all 
of the above into in the dhcp offer and in addition, set the hostname of 
the client regardless of what hostname the client thinks it is, because 
I have 2 clients who assign themselves the same hostname.


Kevin



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

Re: [Dnsmasq-discuss] Cannot send dhcp option 12 hostname to clients

[john doe]

On 5/14/2019 6:42 PM, Kevin Flynn wrote:
>
> Hello everyone.
>
> I'm currently working on a small home network voip system, and I cannot
> for the life of me figure out how to get dnsmasq to send dhcp option 12
> hostnames to clients. I've tried all the obvious methods, including
> /etc/ethers, dhcp-hostsfile entries, dhcp-ignore-names,
> dhcp-generate-names, tag sets, etc. with no luck.
>
> As I was searching the list archices, I noticed a comment from Simon
> mentioning that dnsmasq will not send a dhcp option 12 hostname to a
> client if the client sends a hostname to dnsmasq, and none of my
> configuration attempts seem to be able to override this behavior.
>
> The reason for attempting this, is that I have 2 voip ata adapters,
> which are Linksys/Cisco SPA3000 and they are configured by default to
> send the hostname "SipuraSPA." and I am attempting to configure and
> provision these devices automatically, as opposed to logging into each
> device individually everytime they need to be configured.
>
> So in summary, is there any way to tell dnsmasq to send a dhcp option 12
> hostname to a client reliably, everytime, regardless of what the client
> is sending ?
>

Why not using the MAC address of those devices in dnsmasq?

"--dhcp-host=[][,id:|*][,set:][,][,][,][,ignore"

http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

--
John Doe

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

[Dnsmasq-discuss] Cannot send dhcp option 12 hostname to clients

[Kevin Flynn]

Hello everyone.

I'm currently working on a small home network voip system, and I cannot 
for the life of me figure out how to get dnsmasq to send dhcp option 12 
hostnames to clients. I've tried all the obvious methods, including 
/etc/ethers, dhcp-hostsfile entries, dhcp-ignore-names, 
dhcp-generate-names, tag sets, etc. with no luck.


As I was searching the list archices, I noticed a comment from Simon 
mentioning that dnsmasq will not send a dhcp option 12 hostname to a 
client if the client sends a hostname to dnsmasq, and none of my 
configuration attempts seem to be able to override this behavior.


The reason for attempting this, is that I have 2 voip ata adapters, 
which are Linksys/Cisco SPA3000 and they are configured by default to 
send the hostname "SipuraSPA." and I am attempting to configure and 
provision these devices automatically, as opposed to logging into each 
device individually everytime they need to be configured.


So in summary, is there any way to tell dnsmasq to send a dhcp option 12 
hostname to a client reliably, everytime, regardless of what the client 
is sending ?


Thanks in advance.
Kevin Flynn
kevflynn69 "at" gmail "period" com

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

Re: [Dnsmasq-discuss] [PATCH] DHCPv6: Honor assigning IPv6 address based on MAC address

[Oliver Freyermuth]

Am 14.05.19 um 17:52 schrieb Roy Marples:
> On 14/05/2019 14:29, Oliver Freyermuth wrote:
>> Same here. In an automated deployment situation, client changes DUID in each 
>> phase:
>> - PXE (if done via IPv6)
>> - Installation time (from ramdisk)
>> - Final OS after installation
>> This may improve if newer versions of dhcpcd get packaged in installer 
>> ramdisks and OS, and also for systemd-dhcp,
>> but I am still unaware of any implementation of machine-id as base for the 
>> client DUID in dhclient and of course the implementations are all not 
>> exactly the same.
>> And then there is still the UEFI doing the PXE part, systems with broken 
>> machine-id etc And of course, dual booting if not set up with identical 
>> cliend-DUID.
>>
>> In general, my belief is that the RFC was made without real life use cases 
>> in mind and hence did not think of these.
>> The patch is very helpful to overcome these issues and matches user 
>> expectation (when specifying a MAC address in the config file, I want it to 
>> be used).
> 
> Speaking for dhcpcd (as yay, I am the author) - if the OS presents a stable 
> UUID dhcpcd will use that for the DUID:
> 
> https://tools.ietf.org/html/rfc6355
> https://roy.marples.name/cgit/dhcpcd.git/tree/src/duid.c#n63
> 
> So a fully automated deployment using dhcpcd AND a kernel which reports a 
> stable UUID then all is good.

There's also still another step that may cause an issue: If the UEFI also PXE 
boots via IPv6, it may present even another client DUID. 
It should certainly use the same UUID dhcpcd is using, but if it does not, you 
might be screwed (at least if your environment is IPv6 only). 

> 
> But not everyone uses dhcpcd>=7.0.6 with the UUID code in, nor a kernel which 
> reports a stable UUID.
> 
> There is literally no reason to use dhclient anymore - and hasn't been for a 
> number of years.

I fully agree (as a Gentoo user who has the freedom of choice). 
Somebody should teach those guys still shipping dhclient by default in their 
distro (e.g. Ubuntus network-manager package pulls in dhclient :-( ) or in 
their installer. 
And in our case, we are sadly not fully free in terms of choice of distro to 
use :-(. 

Cheers (and thanks again for the implementation in dhcpcd, and of course for 
dhcpcd itself!),
Oliver

> 
> Roy


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

Re: [Dnsmasq-discuss] [PATCH] DHCPv6: Honor assigning IPv6 address based on MAC address

[Roy Marples]

On 14/05/2019 14:29, Oliver Freyermuth wrote:

Same here. In an automated deployment situation, client changes DUID in each 
phase:
- PXE (if done via IPv6)
- Installation time (from ramdisk)
- Final OS after installation
This may improve if newer versions of dhcpcd get packaged in installer ramdisks 
and OS, and also for systemd-dhcp,
but I am still unaware of any implementation of machine-id as base for the 
client DUID in dhclient and of course the implementations are all not exactly 
the same.
And then there is still the UEFI doing the PXE part, systems with broken 
machine-id etc And of course, dual booting if not set up with identical 
cliend-DUID.

In general, my belief is that the RFC was made without real life use cases in 
mind and hence did not think of these.
The patch is very helpful to overcome these issues and matches user expectation 
(when specifying a MAC address in the config file, I want it to be used).


Speaking for dhcpcd (as yay, I am the author) - if the OS presents a 
stable UUID dhcpcd will use that for the DUID:


https://tools.ietf.org/html/rfc6355
https://roy.marples.name/cgit/dhcpcd.git/tree/src/duid.c#n63

So a fully automated deployment using dhcpcd AND a kernel which reports 
a stable UUID then all is good.


But not everyone uses dhcpcd>=7.0.6 with the UUID code in, nor a kernel 
which reports a stable UUID.


There is literally no reason to use dhclient anymore - and hasn't been 
for a number of years.


Roy

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

Re: [Dnsmasq-discuss] [PATCH] Change dhcp_release to use first address when no IP subnet matches

[Brian Haley]

On 5/14/19 3:52 AM, Nicolas Cavallari wrote:

On 26/04/2019 22:03, Brian Haley wrote:

Currently, dhcp_release will only send a 'fake' release
when the address given is in the same subnet as an IP
on the interface that was given.

This doesn't work in an environment where dnsmasq is
managing leases for remote subnets via a DHCP relay, as
running dhcp_release locally will just cause it to
silently exit without doing anything, leaving the lease
n the database.

Change it to save the first IP it finds on the interface,
and if no matching subnet IP is found, use it as a fall-back.
This fixes an issue we are seeing in certain Openstack
deployments where we are using dnsmasq to provision baremetal
systems in a datacenter.

While using Dbus might have seemed like an obvious solution,
because of our extensive use of network namespaces (which
Dbus doesn't support), this seemed like a better solution
than creating system.d policy files for each dnsmasq we
might spawn and using --enable-dbus=$id in order to isolate
messages to specific dnsmasq instances.


I use D-Bus accross network namespaces without any problem.


I found I could only use the system bus and not the session bus with 
namespaces.  But maybe part is I don't think my dnsmasq configuration is 
very Dbus-friendly.  For example, it is running inside a network 
namespace because there are most likely >1 tenant using the same private 
IP address space.  So if I send a message on the system bus I want it 
scoped so only a single dnsmasq instance will get it, but my testing 
with some scripts showed that wasn't the case by default, I needed the 
--enable-bus flag and a corresponding profile entry.



I also configured
D-Bus to look for additional policies in a tmpfs, and each time i need to start
a D-Bus enabled dnsmasq, i create an additonal policy for a new name and SIGHUP
dbus-daemon.

If you want to isolate D-Bus across network namespaces, it is also possible
to start another dbus-daemon on another unix socket, then set the
DBUS_SYSTEM_BUS_ADDRESS to the address chosen by dbus-daemon, so that dnsmasq
and your other programs can use it.
I cobbled this shell script some time ago to test things, it could probably be
cleaned/adjusted:

bus_path="/tmp/test_$netns"
bus_addr="unix:abstract=$bus_path"

dbus_fifo="${bus_path}.fifo"

mkfifo "$dbus_fifo"

dbus-daemon --fork --address="$bus_addr" --system --nopidfile \
 --print-address=8 --print-pid=9 8>"$dbus_fifo" 9>&8 &

while read dbus_line; do
 case "$dbus_line" in
 "$bus_addr"*)
  export DBUS_SYSTEM_BUS_ADDRESS="$dbus_line";;
 [0-9]*)
  dbus_pid="$dbus_line";;
 *)
  echo "Unknown D-Bus output: '$dbus_line'" ;;
 esac
done < "$dbus_fifo"
wait


Thanks for the info, I hadn't thought of running an additional Dbus 
daemon inside the namespace.  Unfortunately this will then start 
consuming even more resources (cpu, memory) as there could be hundreds 
or thousands of namespaces in our setup.  If we can fix this with a 
small change it seems much less painful.


-Brian

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

Re: [Dnsmasq-discuss] [PATCH] DHCPv6: Honor assigning IPv6 address based on MAC address

[Oliver Freyermuth]

Am 11.05.19 um 19:42 schrieb Kevin Darbyshire-Bryant:
> 
> 
>> On 6 Apr 2019, at 12:01, Geert Stappers  wrote:
>>
>> On Mon, Apr 01, 2019 at 01:02:20AM +0200, Pali Rohár wrote:
>>> On Tuesday 12 February 2019 13:41:43 Geert Stappers wrote:
 On 06-02-2019 21:29, Pali Rohár wrote:
> On Friday 11 January 2019 17:52:43 Pali Rohár wrote:
>> On Monday 17 December 2018 18:41:09 Pali Rohár wrote:
>>> Currently IPv6 addresses are assigned to tuple (IAID, DUID). When system
>>> changes IAID/DUID then old assigned IPv6 address cannot be reused, even
>>> when in config file was DHCPv6 assignment based on MAC address (and not 
>>> on
>>> DUID).
>>
>>   ...
>>
>> Hello, can somebody look at this patch?
>>
>> I remember that more people asked for ability to assign IPv6 address
>> based on MAC address specified in config file, rather then IAID/DUID.
>>
> PING
>
 Another request for

 Hey, could this patch get reviewed?


>>> Hello, can somebody review this patch?
>>>
>>
>> FWIW
>>
>> * The (four months old) patch does get applied cleanly.
>> * My compiler is happy with it
>> * Executable remains running upon start ( no early crash )
>> * I'm unable to test the (new) IPv6 functionality
>>
>>
>> Where in the "patch pipeline" is Pali's patch?
>>
>>
>> Regards
>> Geert Stappers
> 
> I’ve been using this patch to tame qnap’s frustrating dhcpv6 assignment 
> limitations for many months.  It’s immensely useful.

Same here. In an automated deployment situation, client changes DUID in each 
phase: 
- PXE (if done via IPv6)
- Installation time (from ramdisk)
- Final OS after installation
This may improve if newer versions of dhcpcd get packaged in installer ramdisks 
and OS, and also for systemd-dhcp,
but I am still unaware of any implementation of machine-id as base for the 
client DUID in dhclient and of course the implementations are all not exactly 
the same. 
And then there is still the UEFI doing the PXE part, systems with broken 
machine-id etc And of course, dual booting if not set up with identical 
cliend-DUID. 

In general, my belief is that the RFC was made without real life use cases in 
mind and hence did not think of these. 
The patch is very helpful to overcome these issues and matches user expectation 
(when specifying a MAC address in the config file, I want it to be used). 

Cheers,
Oliver

> 
> 
> Cheers,
> 
> Kevin D-B
> 
> gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> ___
> 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] dnsmasq dies after about 20 minutes

[Roy Marples]

On 14/05/2019 04:54, Steve Lloyd wrote:
I am running dnsmasq on the lastest stretch on a rpi.  For some reason 
dnsmasq dies after about 20 minutes,  I can restart it and it will last 
another 20 minutes.  Any insight on how to fix this would be much 
appreciated.  Here is the status after it dies, followed by the 
resolvconf.conf


...

May 14 03:45:22 nifd.local systemd[1]: dnsmasq.service: Main process 
exited, code=killed, status=11/SEGV
May 14 03:45:22 nifd.local dnsmasq[4488]: /sbin/resolvconf: 7: 
/etc/resolvconf.conf: 208.67.222.123 : not found


...


*HERE IS MY resolvconf.conf file*
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details

resolv_conf=/etc/resolv.conf
# If you run a local name server, you should uncomment the below line and
# configure your subscribers configuration files below.
name_servers=10.0.1.81 208.67.222.123 208.67.220.123 185.228.168.10 
185.228.169.11


And there's the error. Let me quote resolvconf.conf(5)

DESCRIPTION
 resolvconf.conf is the configuration file for resolvconf(8).  The
 resolvconf.conf file is a shell script that is sourced by 
resolvconf(8),
 meaning that resolvconf.conf must contain valid shell commands. 
Listed
 below are the standard resolvconf.conf variables that may be set. 
If the
 values contain whitespace, wildcards or other special shell 
characters,
 ensure they are quoted and escaped correctly.  See the replace 
variable

 for an example on quoting.

So your line needs to read
name_servers="10.0.1.81 208.67.222.123 208.67.220.123 185.228.168.10 
185.228.169.11"


Roy

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

Re: [Dnsmasq-discuss] Starting as non-root just works

[Kristoffel Pirard]

Hi Geert,

That is terribly helpful.  Thanks a lot!

Although 'the whole world is not Linux', your explanation "Dnsmasq listens
on ports 53, 67 and 69. That requires
root privilege; Avoiding to run dnsmasq as root can be done with net
capabilities" seems a terrific candidate to go in the man page :)  Would
you like me to prepare a pull request?

Regards
Kristoffel


On Mon, May 13, 2019 at 11:35 PM Geert Stappers 
wrote:

> On Mon, May 13, 2019 at 12:51:09PM +0200, Kristoffel Pirard wrote:
> > On Mon, 13 May 2019, 12:36 Geert Stappers wrote:
> > > On 13-05-2019 11:02, Roy Marples wrote:
> > > > On 13/05/2019 09:31, Kristoffel Pirard wrote:
> > > >> The dnsmasq man page for the --user parameter says that "Dnsmasq
> must
> > > >> _normally_ be started as root".  We tested starting as non-root
> user,
> > > >> but with capabilities cap_net_bind_service, cap_net_admin,
> > > >> cap_net_raw.  It currently seems to work, but I'm debating if we
> > > >> should actually use this 'hack'.
> > > >>
> > > >> So should the ambiguous adverb 'normally' be removed from the
> > > >> documentation?  If not, what are the circumstances in which it is
> > > >> allowed to not start as root?
> > > >
> > > > The whole world is not Linux. Most other OS's don't have these caps.
> > > >
> > > >
> > > In other words:The _normally_  in  'Dnsmasq must normally be
> started
> > > as root' is correct.
> > >
> > So I should interpret it as 'unless you have a really good reason and you
> > know what you're doing'?  (Which I answer 'no' to twice)
>
>
> ] 'Dnsmasq must normally be started as root'
>
>
> Read that as "Dnsmasq listens on ports 53, 67 and 69. That requires
> root privilege."  Running a process as root does get that privilege.
> Yes we did that all the time in days before the fear.
>
> Avoiding to run Dnsmasq as root can be done with "net capabilities"
>
> > > >> We tested starting as non-root user, but with capabilities
> > > >> cap_net_bind_service, cap_net_admin, cap_net_raw.
>
> :-)
>
> > > >> It currently seems to work,
>
> I do read that as "Confirming that cap_net_*** works"
>
>
> > > >> but I'm debating if we should actually use this 'hack'.
>
>
>
>
> Groeten
> Geert Stappers
> --
> Leven en laten leven
>
> ___
> 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] Change dhcp_release to use first address when no IP subnet matches

[Nicolas Cavallari]

On 26/04/2019 22:03, Brian Haley wrote:
> Currently, dhcp_release will only send a 'fake' release
> when the address given is in the same subnet as an IP
> on the interface that was given.
> 
> This doesn't work in an environment where dnsmasq is
> managing leases for remote subnets via a DHCP relay, as
> running dhcp_release locally will just cause it to
> silently exit without doing anything, leaving the lease
> n the database.
> 
> Change it to save the first IP it finds on the interface,
> and if no matching subnet IP is found, use it as a fall-back.
> This fixes an issue we are seeing in certain Openstack
> deployments where we are using dnsmasq to provision baremetal
> systems in a datacenter.
> 
> While using Dbus might have seemed like an obvious solution,
> because of our extensive use of network namespaces (which
> Dbus doesn't support), this seemed like a better solution
> than creating system.d policy files for each dnsmasq we
> might spawn and using --enable-dbus=$id in order to isolate
> messages to specific dnsmasq instances.

I use D-Bus accross network namespaces without any problem. I also configured
D-Bus to look for additional policies in a tmpfs, and each time i need to start
a D-Bus enabled dnsmasq, i create an additonal policy for a new name and SIGHUP
dbus-daemon.

If you want to isolate D-Bus across network namespaces, it is also possible
to start another dbus-daemon on another unix socket, then set the
DBUS_SYSTEM_BUS_ADDRESS to the address chosen by dbus-daemon, so that dnsmasq
and your other programs can use it.
I cobbled this shell script some time ago to test things, it could probably be
cleaned/adjusted:

bus_path="/tmp/test_$netns"
bus_addr="unix:abstract=$bus_path"

dbus_fifo="${bus_path}.fifo"

mkfifo "$dbus_fifo"

dbus-daemon --fork --address="$bus_addr" --system --nopidfile \
--print-address=8 --print-pid=9 8>"$dbus_fifo" 9>&8 &

while read dbus_line; do
case "$dbus_line" in
"$bus_addr"*)
 export DBUS_SYSTEM_BUS_ADDRESS="$dbus_line";;
[0-9]*)
 dbus_pid="$dbus_line";;
*)
 echo "Unknown D-Bus output: '$dbus_line'" ;;
esac
done < "$dbus_fifo"
wait

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

Re: [Dnsmasq-discuss] dnsmasq dies after about 20 minutes

[Geert Stappers]

On Mon, May 13, 2019 at 09:54:27PM -0600, Steve Lloyd wrote:
> I am running dnsmasq on the lastest stretch on a rpi.  For some reason
> dnsmasq dies after about 20 minutes,  I can restart it and it will last
> another 20 minutes.
> Any insight on how to fix this would be much appreciated.

Seen that request.

What not can be seen, because not shown be original poster.

* Power supply of the RPi
* Power connector of the RPi
* How many devices (USB and "shields") are connected to the RPi
* The reason for FIVE name servers
* The reason for THREE resolvers

> Here is the status after it dies, followed by the resolvconf.conf
> 
> *systemctl status dnsmasq*
> â dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
>Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor 
> preset: enabled)
>Active: failed (Result: signal) since Tue 2019-05-14 03:45:22 UTC; 1min 0s 
> ago
>   Process: 4488 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf 
> (code=exited, status=0/SUCCESS)
>   Process: 2448 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf 
> (code=exited, status=0/SUCCESS)
>   Process: 2439 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, 
> status=0/SUCCESS)
>   Process: 2436 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, 
> status=0/SUCCESS)
>  Main PID: 2447 (code=killed, signal=SEGV)
> 
> May 14 03:45:22 nifd.local systemd[1]: dnsmasq.service: Main process exited, 
> code=killed, status=11/SEGV
> May 14 03:45:22 nifd.local dnsmasq[4488]: /sbin/resolvconf: 7: 
> /etc/resolvconf.conf: 208.67.222.123: not found
> May 14 03:45:22 nifd.local dnsmasq[4488]: /sbin/resolvconf: 7: 
> /etc/resolvconf.conf: 208.67.222.123: not found
> May 14 03:45:22 nifd.local dnsmasq[4488]: /sbin/resolvconf: 7: 
> /etc/resolvconf.conf: 208.67.222.123: not found
> May 14 03:45:22 nifd.local dnsmasq[4488]: Too few arguments.
> May 14 03:45:22 nifd.local dnsmasq[4488]: /sbin/resolvconf: 7: 
> /etc/resolvconf.conf: 208.67.222.123: not found
> May 14 03:45:22 nifd.local dnsmasq[4488]: /sbin/resolvconf: 7: 
> /etc/resolvconf.conf: 208.67.222.123: not found
> May 14 03:45:22 nifd.local dnsmasq[4488]: /sbin/resolvconf: 7: 
> /etc/resolvconf.conf: 208.67.222.123: not found
> May 14 03:45:22 nifd.local systemd[1]: dnsmasq.service: Unit entered failed 
> state.
> May 14 03:45:22 nifd.local systemd[1]: dnsmasq.service: Failed with result 
> 'signal'.
> 
> 
> *HERE IS MY resolvconf.conf file*
> # Configuration for resolvconf(8)
> # See resolvconf.conf(5) for details
> 
> resolv_conf=/etc/resolv.conf
> # If you run a local name server, you should uncomment the below line and
> # configure your subscribers configuration files below.
> name_servers=10.0.1.81 208.67.222.123 208.67.220.123 185.228.168.10 
> 185.228.169.11
> 
> # Mirror the Debian package defaults for the below resolvers
> # so that resolvconf integrates seemlessly.
> dnsmasq_resolv=/var/run/dnsmasq/resolv.conf
> pdnsd_conf=/etc/pdnsd.conf
> unbound_conf=/var/cache/unbound/resolvconf_resolvers.conf



Groeten
Geert Stappers
-- 
Leven en laten leven

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