Re: [Dnsmasq-discuss] Multicast Netlink Crash on gVisor Kernel

[Nicolas Cavallari]

On 16/03/2024 10:09, shamrock_sesame214--- via Dnsmasq-discuss wrote:

Hello,

I am attempting to run dnsmasq DNS resolver in gVisor. gVisor is a hardened 
userspace kernel compatible with Kubernetes and Docker containers. At the 
moment, gVisor does not seem to support some routing features such as those 
found in linux/rtnetlink.h, including multicast related netlink subscriptions.

  When I run dnsmasq in gVisor, I get this crash on startup:

      cannot create netlink socket: Permission denied

Checking strace debugger, this was the attempted call made:

  dnsmasq X bind(0x3 socket:[1], 0x7ee5d298ca58 {Family: AF_NETLINK, 
PortID: 0, Groups: 1360}, 0xc) = 0 (0x0) errno=13 (permission denied) (19.017µs)

The next call writes an error message to the terminal and begins exiting the 
program. I believe this to be caused by multicast route subscription near this 
line 73 in src/netlink.c: 
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/netlink.c;h=ef4b5fec3197ec1a855fca3bcf8d86eaa29ca479;hb=HEAD#l73

I noticed the comment in the code:

  /* May not be able to have permission to set multicast groups don't die 
in that case */

I am unsure if line 79 will trigger this error anyway, and if this is intended 
behavior, as the program seems to crash anyway.


Line 79 basically retries the bind without subscribing to any 
route/ifaddr groups. There is no reason for it to fail. Actually, i 
think the second call is a no-op and it could just be omitted, the 
kernel will autobind on the first sendmsg(). I'm not the maintainer so i 
don't know why this call was added.


Anyway, as of 2024, both calls do not require any privileges (try "ip 
monitor" as a simple user, which requests even more rtnetlink groups).
Not being able to use rtnetlink multicast groups is a severe limitation, 
this should really be fixed in gVisor.


Out of curiosity, does dnsmasq's nfset support works inside gVisor ?

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

Re: [Dnsmasq-discuss] Is leasquery supported in Dnsmasq

[Nicolas Cavallari]

On 24/02/2023 10:13, Rashi Krishna wrote:

Hi all.

I just wanted to know if leasequery is supported in Dnsmasq. I tried
sending a leasequery to the server, but I couldn't get any response.


There does not seem to be any leasequery (RFC 4388) support in dnsmasq.

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

Re: [Dnsmasq-discuss] DHCP server not assigning IP to RTMU86

[Nicolas Cavallari]

On 23/05/2022 20:34, Kamil via Dnsmasq-discuss wrote:

Dear Nicolas,

I've tried isc-dhcp-server without "authoritative" and it still work fine


If anything else fails, use tcpdump/wireshark.



I've used tcpdump. I've attached full log in this message:
https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg16249.html 


please have a look.


There isn't enough information to debug things.  tcpdump only report a 
DHCP message of size 300 without reporting its content, which are 
important to see what's happening.


Ideally we would need a pcap file.  Censoring information in a pcap file 
is not easy but still possible with a hex editor.  Otherwise you can use 
"tshark -r capture.pcap -V" to output a text representation of the pcap, 
censor the output and give us the result.


Also, focus on the DHCP exchange with the RTMU86 that does not work. We 
already know how a successful DHCP exchange look like.


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

Re: [Dnsmasq-discuss] DHCP server not assigning IP to RTMU86

[Nicolas Cavallari]

On 11/05/2022 13:41, Kamil via Dnsmasq-discuss wrote:


But when I used isc-dhcp-server with following config:

subnet 192.168.6.0 netmask 255.255.255.0 {
         interface eth0;
         ddns-update-style none;
         default-lease-time 600;
         max-lease-time 3600;
         authorative;
         range 192.168.6.11 192.168.6.20;
         option subnet-mask 255.255.255.0;
         option routers 192.168.6.1;
         option domain-name-servers 8.8.8.8;
         get-lease-hostnames true;
         use-host-decl-names true; 


}


then isc-dhcp-server assigns correct IP to RTMU86.
Why doesn't Dnsmasq want to assign IP to RTMU86?


Your isc-dhcp-server config includes "authoritative" while your dnsmasq 
doesn't include "dhcp-autoritative".


There isn't enough information to determine what is going on here, but
I had problems with broken DHCP clients sending DHCPREQUEST without a 
server identifier option.
RFC-compliant DHCP servers ought to ignore them, but authoritative mode 
is here to override this behavior.


dnsmasq does not log anything in non-authoritative mode when it drops 
DHCP requests.


If anything else fails, use tcpdump/wireshark.

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

Re: [Dnsmasq-discuss] dnsmasq dhcp relay not relaying response from upstream to client

[Nicolas Cavallari]

Let's look at the reply from freeradius:


(14) Sent code 1026 Id 24307805 from 10.10.254.1:67 to 10.10.253.1:67
length 0
(14)   DHCP-Relay-IP-Address = 10.10.253.1
(14)   DHCP-Client-Identifier = 0xff2784511b000100012867cc8108002784511b
(14)   DHCP-IP-Address-Lease-Time = 7200
(14)   DHCP-Client-IP-Address = 255.255.255.255


This is suspicious. RFC 2131 Table 3 says ciaddr (Client IP Address) 
should be 0.0.0.0 in a DHCPOFFER, and should otherwise mirror the ciaddr 
sent by the client, which, in this case, was 0.0.0.0 too.



(14)   DHCP-Your-IP-Address = 10.10.253.3
(14)   DHCP-Subnet-Mask = 255.255.255.0
(14)   DHCP-Router-Address = 10.10.253.1
(14)   DHCP-Domain-Name-Server = 8.8.8.8
(14)   DHCP-Message-Type = DHCP-Offer
(14)   DHCP-Gateway-IP-Address = 10.10.253.1
(14)   DHCP-DHCP-Server-Identifier = 255.255.255.255


This is HIGHLY suspicious. This is supposed to be the address of the 
server. The rules are set in section 4.1 of the RFC, and most notably:


"a server MUST choose an address as a 'server identifier' that, to the 
best of the server's knowledge, is reachable from the client."


This is not going to work well in this case.


(14)   DHCP-Opcode = Server-Message
(14)   DHCP-Hardware-Type = Ethernet
(14)   DHCP-Hardware-Address-Length = 6
(14)   DHCP-Hop-Count = 1
(14)   DHCP-Transaction-Id = 24307805
(14)   DHCP-Flags = 0


The "broadcast" flag is not set. This means that the client supports 
unicast replies, so the relay should unicast the reply to yiaddr using 
chaddr...


So what would dnsmasq do with such a response ?

relay_reply4() would correctly detect that this is a server-to-relay 
response, so is_relay_reply = 1,


but ciaddr is not zero, and dnsmasq will trust ciaddr over yiaddr (this 
makes perfect sense for a DHCP server, a relay should not see anything 
with ciaddr != 0 anyway). so the destination is set to 
255.255.255.255:68, and we skip all the destination selection code (the 
one that looks at the broadcast flag), as well as the interface 
selection code.


dnsmasq would probably sends the packet to 255.255.255.255:68 without 
telling on which interface it should be sent or which source address 
should be used, because ciaddr is supposed to be a unicast address. What 
the kernel would do in this case is anyone's guess.


Even if such a message could be forwarded verbatim to the client, it 
would probably confuse it. When a client receives a lease from a DHCP 
server, it will renew it by sending unicast packets directly to the 
server's "server identifier" address, without involving the relay. But 
here, "server identifier" is set to 255.255.255.255...


On the other hand, the ISC DHCP server/relay/client have probably seen 
their share of nonsensical DHCP implementations, and can probably see 
through freeradius's nonsense packets.


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

Re: [Dnsmasq-discuss] Resolving .local names

[Nicolas Cavallari]

On 05/11/2020 11:33, Mukuntha rajaa wrote:

Hi,

I am working on a legacy application, which uses ".local" format 
names. I have setup dnsmasq in my system.


/usr/sbin/dnsmasq -k --bind-interfaces 
--listen-address=127.0.0.1,192.168.101.101 --dns-forward-max=1000 
--cache-size=1 --server 10.58.112.113


If I run my application, which does getaddrinfo on ".local" as first 
step,I get


"Name or service not known"

Does dnsmasq not resolve ".local" names too ? How to resolve ".local" 
names ?
All my resolutions are only within my machine. I am not entertaining any 
DNS resolution outside of my machine.


.local is reserved for mDNS usage and many (if not all) glibc-based 
linux distribution have basic support for mDNS, even if avahi is not 
installed.


As a result, dnsmasq is probably not even queried by your system's name 
resolver, so there is nothing dnsmasq can do.


The easiest solution is to stop using .local.
You can also hack your system to not use mDNS, by modifying 
/etc/nsswitch.conf or similar, but using .local in this way violates 
RFCs, so don't expect this to work everywhere except on your machine.


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

Re: [Dnsmasq-discuss] dnsmasq on an IPv4 /32 interface

[Nicolas Cavallari]

On 21/09/2020 21:32, Paul Gear wrote:
> Hi all,
> 
> I've been trying to solve the same problem described in this blog post:
> https://blog.fhrnet.eu/2020/03/07/dhcp-server-on-a-32-subnet/
> 
> In a nutshell, the situation is a VM host which performs routing and
> firewalling for all its guests, providing an isolated IPv4 /32 (and in
> my case an IPv6 /64 or /128 as well) to each VM guest, and using
> interface routes on the host to direct traffic to each guest, without
> wasting IPv4 addresses on /31 or /30 point-to-point links.
> 
> The post claims that the configuration noted (a single /32 allocated to
> the host which is configured on every client-facing interface) is only
> possible at present with ISC DHCP.  I've tested a number of different
> configurations of dnsmasq, and this seems to be correct.  I'm hoping
> someone experienced in the dnsmasq code base can confirm or deny this.
> 
> Assuming this is currently a limitation, I'd like to work on adding
> support to dnsmasq for this scenario.  I'm not experienced with the code
> base (although I've read some of the relevant portions and believe it
> should be possible), so I'm hoping also for some guidance on whether
> this functionality would be accepted into the code base, and if so, how
> it might appear in the configuration.
> 
> My initial thought was that there wouldn't need to be any explicit
> configuration; rather, if a DHCP request is received on an interface
> with a /32 mask (or perhaps on an interface with a non-unique address on
> the host), the usual restrictions around interface matching would be
> relaxed, and an address would be given out either from the
> statically-defined hosts, or from a pool which doesn't match any
> interface on the host.  When giving out IPv6 addresses, my thought was
> that things would mostly work the same if a DHCPv6 request was received
> on an interface with only link-local addressing configured.

This sounds like the use case for shared-network:

shared-network=virbr13,192.168.1.26

or

shared-network=172.16.0.1,192.168.1.26

Alternatively, i sent this patch a while ago to be able to ignore any
matching, but my use case is different. I can send an updated version if
people are interested.

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q1/012070.html

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

Re: [Dnsmasq-discuss] [PATCH] Add interface name, vendor class if present and lease expiration time to dbus signals

[Nicolas Cavallari]

On 04/12/2019 13:24, Victorien Molle wrote:
> For our usage, we need to have more informations sent over D-Bus such as the 
> interface
> name, the vendor class identifier and the lease expiration time.
> 
> Note: in order to get leases extradata be populated, we enabled this feature 
> if D-Bus
> is enabled in configuration file (this was enabled in the past only if a 
> script was
> ran on leases updates).

D-Bus has this disadvantage that the change you are proposing completely
breaks the existing D-Bus API that one may be relying on, and many D-Bus
handling libraries would be incapable of understanding both API at the time.

One solution would be to keep the old signal and also send a new signal
with the original info plus the extra, possibly in a way that allows to
add more over time (a dict ?).

(Also, this API should be documented in the file dbus/DBus-interface...)

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

Re: [Dnsmasq-discuss] Lease comes back after removing

[Nicolas Cavallari]

On 26/06/2019 22:32, Geert Stappers wrote:
> 
> My (educated??) guess is that lease data is stored in Dbus.
> 
> My only point to back that up, is `dnsmasq -v` showing  "DBus"

D-Bus does not store data, it's merely an old-style RPC.

dnsmasq does not send any D-Bus message when giving out leases, it merely
provides an API to add/remove them while it is running.

Without any lease file or lease script, dnsmasq has no way to have a memory of
the lease.

maybe it's just the client sending a DHCPREQUEST directly with the old lease,
and dnsmasq being to eager to give it out ?


___
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] FAQ? dhcp-script does not receive any action for Windows 10 dhcp client

[Nicolas Cavallari]

On 02/08/2018 08:40, Learn wrote:
> Hi
> 
> Not very sure if this is a bug, but I saw dnsmasq.log:
> 
> Aug  2 14:13:28 dnsmasq-dhcp[5748]: 4278662147 available DHCP range:
> 172.24.1.10 -- 172.24.1.249
> Aug  2 14:13:28 dnsmasq-dhcp[5748]: 4278662147 vendor class: MSFT 5.0
> Aug  2 14:13:28 dnsmasq-dhcp[5748]: 4278662147 client provides name: xxx
> 
> But my dhcp-script file does not capture anything.
> 
> Here is my simple dhcp-script:
> 
>> #!/bin/sh
>>  op="${1:-op}"
>>  mac="${2:-mac}"
>>  ip="${3:-ip}"
>>  hostname="${4}"
>>  tstamp="`date '+%Y-%m-%d %H:%M:%S'`"
>>  payload="${tstamp} ${op} ${ip} (${mac} - ${hostname})"
>>  ddd="`date +%Y_ww%W`"
>>  echo $payload >> /var/log/dhcp-$ddd.log
> 
> I am sure that I could capture actions from an iPhone iOS. And my
> Windows 10 client does lease a dhcp address.

maybe it is a DHCPINFORM ? Windows sure does funky stuff with DHCP.

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

Re: [Dnsmasq-discuss] [PATCH 1/3] Fix some mistakes in french translation of the manual

[Nicolas Cavallari]

On 07/07/2018 13:15, Olivier Gayot wrote:
> Various typos were present along with spelling mistakes and grammar
> errors. Some sentences were missing a few words to be easily
> understandable.
> 
> Many of them probably remain though.


> +.B --hostsdir=
> +Lire tous les fichiers d'hôtes contenus dans le répertoire spécifié. Les
> +fichiers ajoutés ou modifiés sont lus automatiquement.
> +.TP

Unrelated and probably incomplete change.

Once fixed, you can add my Reviewed-By for the whole series.

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

Re: [Dnsmasq-discuss] Implementation of DOH in dnsmasq

[Nicolas Cavallari]

On 14/06/2018 22:32, Kurt H Maier wrote:
> On Thu, Jun 14, 2018 at 09:38:42PM +0200, Mateusz Jończyk wrote:
>>
>> How difficult would it be to add support to DNS over HTTP/2.0 in dnsmasq, for
>> example in constrained environments like home routers?
>>
> 
> This should be handled with a wrapper program.  HTTP/2.0 is an enormous
> and ill-defined specification and it would not be appropriate to bolt it
> directly into dnsmasq.  A dedicated HTTP/2.0 daemon can talk to dnsmasq
> on the backend to provide this service.  Home routers are not
> particularly constrained in this regard, since they generally have web 
> services running to begin with.

It's much more than that. To be secure, TLS requires time, entropy and a CA
list. Many home routers fails at having all three, or require the DNS to get
time and CAs...

>> Please send any replies to the DoH mailing list at .
> 
> Why?

Because by doing so you will be subjected to the various IETF policies that
applies to anyone participating on the IETF mailing list, which includes
copyright grants, patents disclosure and other things that should be read by a
lawyer.

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

Re: [Dnsmasq-discuss] [PATCH] Add a metric-order option that is a mix between strict-order and Default schedulers

[Nicolas Cavallari]

On 15/03/2018 18:57, Kurt H Maier wrote:
> I dislike the extreme complexity introduced by this non-compliant
> behavior, but I also have a stronger dislike for the social effects:
> after growing used to the peculiarities of a specific Rube Goldberg
> machine, users begin to assume that standards-compliant implementations
> are 'wrong' and should be 'fixed.'  After a while, we wind up with
> de-facto expectations that are deviant from standardized behavior, and
> that's not a good situation for anyone.

The fact that there is no standardized solution to the problem does not mean
that the problem doesn't exist and does not need to be solved.  In fact, the
problem is already standardized in RFC641{8,9} and others.

So yes in theory DNS would be global, IP routing would just work and nobody
would snoop my traffic.  In the real world, DNS resolver lies, IP routing is
non-neutral/firewalled/censored/NAT-ed and your traffic is almost always being
mined for (meta)data. And i haven't mentioned failures yet.

So people may need these vpn/nat traversal/dns failover/isp failover things to
get a baseline service. And when they break, wanting degraded service over no
service is still a valid user choice.

Things that works only in an ideal network may be good enough for good enough
networks, but they are just broken for users with shitty networks.

I would have needed this feature years ago, when shitty networks where the only
things that i had.

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

[Dnsmasq-discuss] [PATCH] Allow specifying a 0.0.0.0 netmask in dhcp-range for relays.

[Nicolas Cavallari]

When using a DHCP relay, the netmask in dhcp-range is matched against
giaddr (or the link selection suboption) to determine on which range the
address should be allocated.

However, in some cases, you want to ignore this mechanism, because your
relay, clients and your DHCP server are not in the same subnet, the
relay do not have addresses on their client interfaces and/or you have
more complicated matching in place (e.g.  other relay agent information
suboptions).

The link selection suboption would be a good candidate but this requires
a duplicate policy/configuration in every relay that matches what the
DHCP server would select.

Specifying 0.0.0.0 as a netmask is accepted by the parser but is
rejected by a condition in rfc2131.c, that only checks if
netmask.s_addr = 0, which can happen if the guessing failed, but can
also happen if 0.0.0.0 was explicitly specified.

This fixes the condition so that netmask.s_addr = 0 is acceptable
if it was specified in the configuration.  i.e.  if the
dhcp context (the considered dhcp range) has the CONTEXT_NETMASK
flag.

The netmask to be sent to the client can be set with
dhcp-option=option:netmask,255.255.0.0 anyway.
---
Yuki Nisiwaki's message reminded me of this patch that I use but forgot
about.

 src/rfc2131.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/rfc2131.c b/src/rfc2131.c
index c08a8ab..6b2df35 100644
--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -319,7 +319,7 @@ size_t dhcp_reply(struct dhcp_context *context, char 
*iface_name, int int_index,

/* This section fills in context mainly when a client which is on a 
remote (relayed)
   network renews a lease without using the relay, after dnsmasq 
has restarted. */
-   if (netmask.s_addr != 0  && 
+   if ((netmask.s_addr != 0 || context_tmp->flags & CONTEXT_NETMASK) &&
is_same_net(addr, context_tmp->start, netmask) &&
is_same_net(addr, context_tmp->end, netmask))
  {
-- 
2.16.2


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

Re: [Dnsmasq-discuss] dnsmasq leases file format specification

[Nicolas Cavallari]

On 08/06/2016 21:56, Sergey Nechaev wrote:
> Hello, Simon  
> 
> Could you (or anyone) please provide description of leases file format?
> I’ve searched through this mail list, but failed to find full description.

The code that writes it is in lease_update_file() in src/lease.c.
The code that reads it is in lease_init().

A DHCPv4 lease entry consists of these fields separated by spaces:

- The expiration time (seconds since unix epoch) or duration
  (if dnsmasq is compiled with HAVE_BROKEN_RTC) of the lease.
  0 means infinite.

- The link address, in format XX-YY:YY:YY[...], where XX is the ARP
  hardware type.  "XX-" may be omitted for Ethernet.

- The IPv4 address

- The hostname (sent by the client or assigned by dnsmasq)
  or '*' for none.

- The client identifier (colon-separated hex bytes)
  or '*' for none.

A DHCPv6 lease entry has these fields:

- The expiration time or duration

- The IAID as a Big Endian decimal number, prefixed by T for
  IA_TAs (temporary addresses).

- The IPv6 address

- The hostname or '*'

- The client DUID (colon-separated hex bytes) or '*' if unknown.[1]

For DHCPv6, there must also be exactly one special entry indicating
the DUID of the server.  This line contains two fields:

- The string "duid".

- The DUID of the server.


[1] This field seems to be written but is never read back. A bug maybe ?

> We are preparing improvement to Openstack Neutron network subsystem,
> which enables releasing
> of unneeded DHCPv6 leases and description of leases file format is
> necessary for code review. 

Just pointing out that since dnsmasq 2.73, if you use dbus, you can
dynamically remove leases with just a D-Bus call:

dbus-send --system --print-reply \
  --dest=uk.org.thekelleys.dnsmasq \
  /uk/org/thekelleys/dnsmasq \
  uk.org.thekelleys.dnsmasq.DeleteDhcpLease \
  string:"$IPV4_OR_IPV6_ADDRESS"

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

Re: [Dnsmasq-discuss] prevent dnsmasq from releasing IPs

[Nicolas Cavallari]

On 26/01/2016 14:46, Simon Kelley wrote:
> 
> 
> On 26/01/16 13:42, Stefan Priebe - Profihost AG wrote:
> 
> 
> 
>> what about writing and sending kill 1 / HUP?
> 
> 
> 
> No. The only only way to make that work would be to
> 
> 1) Stop dnsmasq with SIGTERM
> 2) modify the leases file
> 3) restart dnsmasq
> 
> 
> in that order.

You forgot about my patches that adds a D-Bus method to add leases to
the internal copy, that you merged in June last year :)

It's documented in dbus/DBus-interface, as you requested :)

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

[Dnsmasq-discuss] [PATCH 2/2 v2] Add D-Bus methods to add or remove a lease from the internal database.

[Nicolas Cavallari]

AddDhcpLease can be used to add or update a lease in the internal
database, while DeleteDhcpLease deletes a lease.

These methods will still trigger the notifications via D-Bus or the
lease script.

Update the dbus/DBus-interface document accordingly.
---
 dbus/DBus-interface |  74 ++
 src/dbus.c  | 215 
 2 files changed, 289 insertions(+)

diff --git a/dbus/DBus-interface b/dbus/DBus-interface
index 9a895eb..2db5c30 100644
--- a/dbus/DBus-interface
+++ b/dbus/DBus-interface
@@ -169,6 +169,80 @@ Return an array of strings, each string is the IP address 
of an upstream
 server which has been found to loop queries back to this dnsmasq instance, and 
 it therefore not being used.
 
+AddDhcpLease
+
+
+Returns nothing. Adds or updates a DHCP or DHCPv6 lease to the internal lease
+database, as if a client requested and obtained a lease.
+
+If a lease for the IPv4 or IPv6 address already exist, it is overwritten.
+
+Note that this function will trigger the DhcpLeaseAdded or DhcpLeaseUpdated
+D-Bus signal and will run the configured DHCP lease script accordingly.
+
+This function takes many arguments which are the lease parameters:
+- A string with the textual representation of the IPv4 or IPv6 address of the
+  client.
+
+  Examples:
+  192.168.1.115
+  1003:1234:abcd::1%eth0
+  2001:db8:abcd::1
+
+- A string representing the hardware address of the client, using the same
+  format as the one used in the lease database.
+
+  Examples:
+
+  00:23:45:67:89:ab
+  06-00:20:e0:3b:13:af (token ring)
+
+- The hostname of the client, as an array of bytes (so there is no problem
+  with non-ASCII character encoding). May be empty.
+
+  Example (for hostname.or.fqdn):
+  [104, 111, 115, 116, 110, 97, 109, 101, 46, 111, 114, 46, 102, 113, 100, 110]
+
+- The client identifier (IPv4) or DUID (IPv6) as an array of bytes. May be
+  empty.
+
+  Examples:
+
+  DHCPv6 DUID:
+  [0, 3, 0, 1, 0, 35, 69, 103, 137, 171]
+  DHCPv4 client identifier:
+  [255, 12, 34, 56, 78, 0, 1, 0, 1, 29, 9, 99, 190, 35, 69, 103, 137, 171]
+
+- The duration of the lease, in seconds. If the lease is updated, then
+  the duration replaces the previous duration.
+
+  Example:
+
+  7200
+
+- The IAID (Identity association identifier) of the DHCPv6 lease, as a network
+  byte-order unsigned integer. For DHCPv4 leases, this must be set to 0.
+
+  Example (for IPv6):
+
+  203569230
+
+- A boolean which, if true, indicates that the DHCPv6 lease is for a temporary
+  address (IA_TA). If false, the DHCPv6 lease is for a non-temporary address
+  (IA_NA). For DHCPv4 leases, this must be set to false.
+
+RemoveDhcpLease
+---
+
+Returns nothing. Removes a DHCP or DHCPv6 lease to the internal lease
+database, as if a client sent a release message to abandon a lease.
+
+This function takes only one parameter: the text representation of the
+IPv4 or IPv6 address of the lease to remove.
+
+Note that this function will trigger the DhcpLeaseRemoved signal and the
+configured DHCP lease script will be run with the del action.
+
 
 
 2. SIGNALS
diff --git a/src/dbus.c b/src/dbus.c
index 5b69de5..852351e 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -70,6 +70,21 @@ const char* introspection_xml_template =
   arg name=\hwaddr\ type=\s\/\n
   arg name=\hostname\ type=\s\/\n
 /signal\n
+#ifdef HAVE_DHCP
+method name=\AddDhcpLease\\n
+   arg name=\ipaddr\ type=\s\/\n
+   arg name=\hwaddr\ type=\s\/\n
+   arg name=\hostname\ type=\ay\/\n
+   arg name=\clid\ type=\ay\/\n
+   arg name=\lease_duration\ type=\u\/\n
+   arg name=\ia_id\ type=\u\/\n
+   arg name=\is_temporary\ type=\b\/\n
+/method\n
+method name=\DeleteDhcpLease\\n
+   arg name=\ipaddr\ type=\s\/\n
+   arg name=\success\ type=\b\ direction=\out\/\n
+/method\n
+#endif
   /interface\n
 /node\n;
 
@@ -433,6 +448,196 @@ static DBusMessage *dbus_set_bool(DBusMessage *message, 
int flag, char *name)
   return NULL;
 }
 
+#ifdef HAVE_DHCP
+static DBusMessage *dbus_add_lease(DBusMessage* message)
+{
+  struct dhcp_lease *lease;
+  const char *ipaddr, *hwaddr, *hostname, *tmp;
+  const unsigned char* clid;
+  int clid_len, hostname_len, hw_len, hw_type;
+  dbus_uint32_t expires, ia_id;
+  dbus_bool_t is_temporary;
+  struct all_addr addr;
+  time_t time_now;
+  unsigned char dhcp_chaddr[DHCP_CHADDR_MAX];
+
+  DBusMessageIter iter, array_iter;
+  if (!dbus_message_iter_init(message, iter))
+{
+  return dbus_message_new_error(message, DBUS_ERROR_INVALID_ARGS,
+Failed to initialize dbus message iter);
+}
+  if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_STRING)
+{
+  return dbus_message_new_error(message, DBUS_ERROR_INVALID_ARGS,
+Expected string as first argument);
+}
+  dbus_message_iter_get_basic(iter, ipaddr);
+  dbus_message_iter_next(iter);
+
+  if 

Re: [Dnsmasq-discuss] dhcp-script and concurrency/parallel execution

[Nicolas Cavallari]

On 08/06/2015 11:46, Bastian Bittorf wrote:
 i have seen a lot of running instances of dhcp-script
 on an embedded box (OpenWrt, 2.73rc8).
 this is a problem in 2 ways:
 
 1)
 memory consumption
 
 2)
 concurrency, because we read/write into files
 with the same filename
 
 at least there should be an explicit mention of that
 behaviour in the docs. also we should consider to have
 an option e.g. 'scriptwait' which wait till the script
 is terminated before the next call is started...

This is already the current behavior (helper.c:455).  If you see lots
of dhcp-script running, then you have another problem, probably bugs
in your dhcp-script.  Does it fork or run background commands ?

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

Re: [Dnsmasq-discuss] [PATCH 2/2] Add D-Bus methods to add or remove a lease from the internal database.

[Nicolas Cavallari]

On 04/06/2015 23:12, Simon Kelley wrote:
 Long delay, I've returned to this.
 
 The many parameters seem a bit ugly (I'm no Dbus expert, so I may be
 wrong), especially having to includes is_temporary and IAID in DHCPv4
 leases. One solution to this might be to have seperate AddDhcp4Lease and
  AddDhcp6Lease methods.

I considered this, but this will likely add more code.  Either the two
AddDhcp4Lease and AddDhcp6Lease are implemented separately, which
double the code size, or they are handled by the same code with more
conditionals.  I would prefer this solution over the others.

But since D-Bus is only an RPC, there are few simple solutions to pass
data in an extensible way...

 Another option may be to remove the is_temporary flag and only allow
 non-temporary leases to be created this way. Temporary leases are for
 random addresses (like privacy addresses in SLAAC) so there may be no
 need to be able to create them via this route.

This will only remove one argument ... and not much code.

 Final suggestion, which is more radical: just have one argument, which
 is a string, and looks like a line in the leases file. It would be easy
 to pass that to the parsing code in src/lease.c, saving much code.

I expect AddDhcpLease to also be able to extend or update an existing
lease.  The code in src/lease.c does not handle this case correctly
since it assumes the lease database is empty.

 Scripting may be easier too.

I don't see many cases where a lease script invocation calls
AddDhcpLease on the same server for the same lease.  The lease script
probably need to parse its input anyway.

To me, the most obstacle to simple scripting in the lease script is
that AddDhcpLease also triggers another lease script invocation.

I think that users which both uses the lease script and AddDhcpLease
are probably doing something a bit advanced and must implement some
not easily scriptable logic anyway.

 A request, would it be possible to have suitable updates to
 dbus/DBus-interface in the patch, whatever scheme is finally done?

What updates to the D-Bus interface are you thinking of ? Since D-Bus
messages are not extensible, it will be hard to update without
breaking it for existing users.

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

[Dnsmasq-discuss] [PATCH 2/2] Add D-Bus methods to add or remove a lease from the internal database.

[Nicolas Cavallari]

AddDhcpLease can be used to add or update a lease in the internal
database, while DeleteDhcpLease deletes a lease.

These methods will still trigger the notifications via D-Bus or the
lease script.
---
 src/dbus.c | 215 +
 1 file changed, 215 insertions(+)

diff --git a/src/dbus.c b/src/dbus.c
index 5b69de5..852351e 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -70,6 +70,21 @@ const char* introspection_xml_template =
   arg name=\hwaddr\ type=\s\/\n
   arg name=\hostname\ type=\s\/\n
 /signal\n
+#ifdef HAVE_DHCP
+method name=\AddDhcpLease\\n
+   arg name=\ipaddr\ type=\s\/\n
+   arg name=\hwaddr\ type=\s\/\n
+   arg name=\hostname\ type=\ay\/\n
+   arg name=\clid\ type=\ay\/\n
+   arg name=\lease_duration\ type=\u\/\n
+   arg name=\ia_id\ type=\u\/\n
+   arg name=\is_temporary\ type=\b\/\n
+/method\n
+method name=\DeleteDhcpLease\\n
+   arg name=\ipaddr\ type=\s\/\n
+   arg name=\success\ type=\b\ direction=\out\/\n
+/method\n
+#endif
   /interface\n
 /node\n;
 
@@ -433,6 +448,196 @@ static DBusMessage *dbus_set_bool(DBusMessage *message, 
int flag, char *name)
   return NULL;
 }
 
+#ifdef HAVE_DHCP
+static DBusMessage *dbus_add_lease(DBusMessage* message)
+{
+  struct dhcp_lease *lease;
+  const char *ipaddr, *hwaddr, *hostname, *tmp;
+  const unsigned char* clid;
+  int clid_len, hostname_len, hw_len, hw_type;
+  dbus_uint32_t expires, ia_id;
+  dbus_bool_t is_temporary;
+  struct all_addr addr;
+  time_t time_now;
+  unsigned char dhcp_chaddr[DHCP_CHADDR_MAX];
+
+  DBusMessageIter iter, array_iter;
+  if (!dbus_message_iter_init(message, iter))
+{
+  return dbus_message_new_error(message, DBUS_ERROR_INVALID_ARGS,
+Failed to initialize dbus message iter);
+}
+  if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_STRING)
+{
+  return dbus_message_new_error(message, DBUS_ERROR_INVALID_ARGS,
+Expected string as first argument);
+}
+  dbus_message_iter_get_basic(iter, ipaddr);
+  dbus_message_iter_next(iter);
+
+  if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_STRING)
+{
+  return dbus_message_new_error(message, DBUS_ERROR_INVALID_ARGS,
+Expected string as second argument);
+}
+  dbus_message_iter_get_basic(iter, hwaddr);
+  dbus_message_iter_next(iter);
+
+  if ((dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_ARRAY) ||
+  (dbus_message_iter_get_element_type(iter) != DBUS_TYPE_BYTE))
+{
+  return dbus_message_new_error(message, DBUS_ERROR_INVALID_ARGS,
+Expected byte array as third argument);
+}
+  dbus_message_iter_recurse(iter, array_iter);
+  dbus_message_iter_get_fixed_array(array_iter, hostname, hostname_len);
+  tmp = memchr(hostname, '\0', hostname_len);
+  if (tmp)
+{
+  if (tmp == hostname[hostname_len - 1])
+{
+  hostname_len--;
+}
+  else
+{
+  return dbus_message_new_error(message, DBUS_ERROR_INVALID_ARGS,
+Hostname contains an embedded NUL 
character);
+}
+}
+  dbus_message_iter_next(iter);
+
+  if ((dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_ARRAY) ||
+  (dbus_message_iter_get_element_type(iter) != DBUS_TYPE_BYTE))
+{
+  return dbus_message_new_error(message, DBUS_ERROR_INVALID_ARGS,
+Expected byte array as fourth argument);
+}
+  dbus_message_iter_recurse(iter, array_iter);
+  dbus_message_iter_get_fixed_array(array_iter, clid, clid_len);
+  dbus_message_iter_next(iter);
+
+  if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_UINT32)
+{
+  return dbus_message_new_error(message, DBUS_ERROR_INVALID_ARGS,
+Expected uint32 as fifth argument);
+}
+  dbus_message_iter_get_basic(iter, expires);
+  dbus_message_iter_next(iter);
+
+  if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_UINT32)
+{
+  return dbus_message_new_error(message, DBUS_ERROR_INVALID_ARGS,
+Expected uint32 as sixth argument);
+}
+  dbus_message_iter_get_basic(iter, ia_id);
+  dbus_message_iter_next(iter);
+
+  if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_BOOLEAN)
+{
+  return dbus_message_new_error(message, DBUS_ERROR_INVALID_ARGS,
+Expected uint32 as sixth argument);
+}
+  dbus_message_iter_get_basic(iter, is_temporary);
+
+  if (inet_pton(AF_INET, ipaddr, addr.addr.addr4))
+{
+  if (ia_id != 0 || is_temporary)
+   {
+ return dbus_message_new_error(message, DBUS_ERROR_INVALID_ARGS,
+   ia_id and is_temporary must be zero 
for IPv4 lease);
+   }
+  lease = lease_find_by_addr(addr.addr.addr4);
+  if (lease == NULL)
+   {

[Dnsmasq-discuss] [PATCH 1/2] Constify some DHCP lease management functions.

[Nicolas Cavallari]

---
 src/dnsmasq.h | 7 ---
 src/lease.c   | 8 
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 6fe4a41..824a860 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -1304,9 +1304,10 @@ void lease_update_slaac(time_t now);
 void lease_set_iaid(struct dhcp_lease *lease, int iaid);
 void lease_make_duid(time_t now);
 #endif
-void lease_set_hwaddr(struct dhcp_lease *lease, unsigned char *hwaddr,
- unsigned char *clid, int hw_len, int hw_type, int 
clid_len, time_t now, int force);
-void lease_set_hostname(struct dhcp_lease *lease, char *name, int auth, char 
*domain, char *config_domain);
+void lease_set_hwaddr(struct dhcp_lease *lease, const unsigned char *hwaddr,
+ const unsigned char *clid, int hw_len, int hw_type,
+ int clid_len, time_t now, int force);
+void lease_set_hostname(struct dhcp_lease *lease, const char *name, int auth, 
char *domain, char *config_domain);
 void lease_set_expires(struct dhcp_lease *lease, unsigned int len, time_t now);
 void lease_set_interface(struct dhcp_lease *lease, int interface, time_t now);
 struct dhcp_lease *lease_find_by_client(unsigned char *hwaddr, int hw_len, int 
hw_type,  
diff --git a/src/lease.c b/src/lease.c
index 545bbb7..8adb605 100644
--- a/src/lease.c
+++ b/src/lease.c
@@ -813,9 +813,9 @@ void lease_set_iaid(struct dhcp_lease *lease, int iaid)
 }
 #endif
 
-void lease_set_hwaddr(struct dhcp_lease *lease, unsigned char *hwaddr,
- unsigned char *clid, int hw_len, int hw_type, int 
clid_len, 
- time_t now, int force)
+void lease_set_hwaddr(struct dhcp_lease *lease, const unsigned char *hwaddr,
+ const unsigned char *clid, int hw_len, int hw_type,
+ int clid_len, time_t now, int force)
 {
 #ifdef HAVE_DHCP6
   int change = force;
@@ -897,7 +897,7 @@ static void kill_name(struct dhcp_lease *lease)
   lease-hostname = lease-fqdn = NULL;
 }
 
-void lease_set_hostname(struct dhcp_lease *lease, char *name, int auth, char 
*domain, char *config_domain)
+void lease_set_hostname(struct dhcp_lease *lease, const char *name, int auth, 
char *domain, char *config_domain)
 {
   struct dhcp_lease *lease_tmp;
   char *new_name = NULL, *new_fqdn = NULL;
-- 
2.1.4


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