Re: [Dnsmasq-discuss] [PATCH] Remove NULL check for intname.

[Roy Marples]

On 05/10/2017 03:23, Rosen Penev wrote:

@@ -1239,7 +1238,7 @@ static struct serverfd *allocate_sfd(union mysockaddr 
*addr, char *intname)
  #endif
  }
  
-  if (intname && strlen(intname) != 0)

+  if (!strlen(intname))
  ifindex = if_nametoindex(intname); /* index == 0 when not binding to an 
interface */
  
/* may have a suitable one already */




I have no comment on the functionality of the patch (it if intname needs 
to be NULL checked or not), but this is not a good use of strlen.


This could be re-written as

if (*intname != '\0')

Which saves a function call because the actual length of the string is 
not used.


Roy

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

Re: [Dnsmasq-discuss] [PATCH] Remove NULL check for intname.

[Roy Marples]

On 05/10/2017 23:14, Kevin Lyda wrote:
> That's not actually correct in practice.

And top posting is?


> If you'd like to see that I'm
> correct take the following two programs:
> 
> foo.c:
> #include 
> #include 
> 
> int main(int argc, char *argv[]) {
>   if (strlen(argv[0]) == 0) {
> printf("Command empty");
>   } else {
> printf("Command not empty");
>   }
> }
> bar.c:
> #include 
> #include 
> 
> int main(int argc, char *argv[]) {
>   if (*argv[0] == '\0') {
> printf("Command empty");
>   } else {
> printf("Command not empty");
>   }
> }
> 
> Next compile them to assembly like so:
> 
> for f in {foo,bar}.c; do gcc -O2 -S $f; done

Interesting that you assume I use bash and gcc.
This is more portable.
for f in foo bar; do cc -S $f.c; done

> And then compare them:
> 
> diff {foo,bar}.s
>
> They should be the same (possibly different by a ".file" line). And if
> you inspect the resulting code, there won't be a call to strlen or to
> any function at all (well, except printf).

netbsd$ diff foo.s bar.s
2c2
<   .file   "foo.c"
---
>   .file   "bar.c"
22,24c22,24
<   movq(%rsi), %rdi
<   callq   strlen
<   cmpq$0, %rax
---
>   movq(%rsi), %rsi
>   movsbl  (%rsi), %edi
>   cmpl$0, %edi

Now, if I do apply -O2 then clang (my system compiler) does indeed
optimise it away.
What is worring is that even with -O0 or no -O gcc *always* optimises it
away. What if I want to call the function to be called regardless?

> The reason is that gcc, like most C compilers since the 90s, optimises a
> number of common functions in the standard C library. Which means that
> developers can stick with writing code that will be well-optimised *and*
> highly readable.

Spoken like a man who has never dealt with compiler issues!

if (strlen(foo) != 0)
if the function to calculate the length of the string is not zero

if (*foo != '\0')
if the first character of the string is not NUL

I'm having a hard time beliving that the former is more readable AND
just as performant.
It has more text for the brain to digest and a man page to read per
platform.

Or are you going to assume that gcc is the only compiler ever used anywhere?

Roy

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

Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

[Roy Marples]

On 03/06/2018 22:20, Simon Kelley wrote:

I agree that this is an annoying problem. In DHCPv6 even determining the
MAC address of a client is a slightly dodgy operation - there are
circumstances where it's not possible. That notwithstanding, dnsmasq
does it's best, and allows you to configure an address to allocated by
MAC address.

The problem here is that the client changes DUID - the desired address
gets allocated by MAC address once, but when the DUID changes, the
address is already in use by a first DUID/IAID combination, so it can't
be allocated, even if the MAC address is the same.


The problem is how the DUID is generated, not the DUID itself.
DUID-LL is not the default (and shouldn't be either).
DUID-LLT is a good default, but comes with the aforementioned problems.

These problems are very nicely solved with RFC 6355 which adds DUID-UUID 
where UUID is taken from the hosts firmware. The UUID can then be 
displayed on the node alongside the MAC address for provisioning.

https://tools.ietf.org/html/rfc6355

The downside is that no client I know of supports this and I keep 
meaning to add support to dhcpcd for it.
The other downside is that not all hosts have a retrievable UUID as it 
depends on both the OS and host itself - for example some OS's present a 
UUID based on the CPUID. Of course this only works if all OS's generate 
the same UUID from the base data.


TL;DR - this isn't a dnsmasq issue and I agree with Simon that it should 
not allow nor encourage RFC violations.


Roy

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

Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

[Roy Marples]

On 25/05/2018 13:07, Oliver Freyermuth wrote:

I fear the following is a design issue of DHCPv6, but I wonder if there's a way 
to overcome it with dnsmasq...

When automatically deploying machines via PXE / network installer, there's 
usually first a DHCPv6 client running in the installer,
and afterwards (when the machine is installed) the "real" DHCPv6 client running 
on the machine.
Naturally, both will usually have different client DUIDs...


The partial solution to this, without any dnsmasq hackery OR DHCPv6 
client fixes, would be to seed the installed image with the duid from 
the installer.
The only issue is if you re-run the installer it will create a new duid 
- unless it performs a disk scan, finds the installation and then uses 
it. This is an issue because there could be more than one installed 
target found, and which to use?


NetBSD installer has been doing this with great success for some time 
now, no reason why others cannot.


Roy

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

Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

[Roy Marples]

On 04/06/2018 11:49, Roy Marples wrote:
These problems are very nicely solved with RFC 6355 which adds DUID-UUID 
where UUID is taken from the hosts firmware. The UUID can then be 
displayed on the node alongside the MAC address for provisioning.

https://tools.ietf.org/html/rfc6355

The downside is that no client I know of supports this and I keep 
meaning to add support to dhcpcd for it.
The other downside is that not all hosts have a retrievable UUID as it 
depends on both the OS and host itself - for example some OS's present a 
UUID based on the CPUID. Of course this only works if all OS's generate 
the same UUID from the base data.


I've just implemented DUID-UUID for dhcpcd.
Patch here:
https://roy.marples.name/git/dhcpcd.git/commit/?id=71981cab0e41ea2833489bc51307611727276aff

Tested on NetBSD, OpenBSD, FreeBSD and Linux.
Unsure how to get system-uuid for Solaris or QNX at this time, which are 
the only other platforms dhcpcd works on (but isn't as well supported).


Roy

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

Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

[Roy Marples]

On 06/06/2018 09:14, Oliver Freyermuth wrote:

I finally managed to test this in my testing setup - it works perfectly fine!


Awesome :D


Could you let me know once it's integrated upstream?


I *am* the upstream for dhcpcd :)
It will be in the next dhcpcd release for sure.


I plan to open issues for dhclient, systemd-networkd etc. then and could 
reference that RFC6355 is already handled fine
in a very portable way on a wide range of OS by dhcpcd.

In a later step, I'll then ping the debian-installer and kickstart developers, 
since they should also adopt this (I think they use dhclient, but I may be 
wrong).

It's nice to see that dhcpcd is first on this :-).


Generally, dhcpcd is the first to support new stuff.
Thanks for testing and taking it to other upstreams.

Roy

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

Re: [Dnsmasq-discuss] [PATCH] allow multiple Classless Route Options

[Roy Marples]

On 19/07/2018 21:34, Simon Kelley wrote:

This generates multiple instance of the DHCP option 121 in the DHCP
reply packet, which isn't strictly legal.


What makes you think it's not legal?
RFC3442 makes no mention of it not being legal and RFC3396 describes how 
multiple instances of options should be concatenated when an options 
data exceeds 255 bytes.


dhcpcd of course supports this :)

Roy

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

[Dnsmasq-discuss] duplicate dhcp-host IP address

[Roy Marples]

Hi List

dnsmasq has this lovely piece of code
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/option.c;h=462796996ef208bd013eece70fce51e7dc1a45ad;hb=HEAD#l3240

This effectively stops me using dnsmasq to give the same IP address to 
wired and wireless interfaces (which are on the same network) of my laptop.
The laptop in question runs NetBSD + dhcpcd can is more than capable of 
having the same address UP on >1 interface.


Can this be removed, or an option added to disable the check please?
I want to enjoy a persitent ssh shell from/to it while swapping between 
wired/wireless without it droping due to changing the IP address.


Thanks

Roy

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

Re: [Dnsmasq-discuss] duplicate dhcp-host IP address

[Roy Marples]

On 12/11/2018 16:11, Donald Muller wrote:

You could put a reservation in dnsmasq for the wired and wireless MAC addresses 
and give them the same IP address.


How?

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

Re: [Dnsmasq-discuss] duplicate dhcp-host IP address

[Roy Marples]

On 12/11/2018 19:09, Jan Psota wrote:

On 12/11/2018 16:11, Donald Muller wrote:

You could put a reservation in dnsmasq for the wired and wireless
MAC addresses and give them the same IP address.


How?


In /etc/dnsmask.hosts I have:
ee:33:99:99:cc:dd,88:33:99:88:ee:00,192.168.1.10,hostname
 ethernet ^^^, wifi ^^^

but it _does not work for some laptops_! I don't understand, how, but
it does not. And for some it works like expected. Both on Windows 7!


Wow, that works and proves I missed that part of the man page!

It also shows there is a bug with dhcpcd (maybe on NetBSD) where it's 
not changing the subnet route to the correct interface, but I'll get 
that fixed.


Maybe the warning could be improved slightly though.

Roy

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

Re: [Dnsmasq-discuss] test DHCP clients

[Roy Marples]

On 29/12/2018 18:49, Geert Stappers wrote:

What is your favorite / good enough  DHCP test client?


dhcpcd - if there's a relevant DHCP RFC it doesn't support, it's a bug.
https://roy.marples.name/projects/dhcpcd

# dhcpcd -dBT4 xennet0
dhcpcd-7.0.8 starting
DUID 00:01:00:01:20:12:08:0c:fa:73:78:00:00:02
xennet0: IAID 78:00:00:02
xennet0: IA type 25 IAID 00:00:00:01
xennet0: delaying IPv4 for 0.2 seconds
xennet0: reading lease `/var/db/dhcpcd/xennet0.lease'
xennet0: rebinding lease of 10.73.1.62
xennet0: sending REQUEST (xid 0x1aaf4ef1), next in 4.0 seconds
xennet0: no authentication from 10.73.0.1
xennet0: acknowledged 10.73.1.62 from 10.73.0.1
xennet0: leased 10.73.1.62 for 3600 seconds
xennet0: executing `/libexec/dhcpcd-run-hooks' TEST
interface=xennet0
pid=9670
protocol=dhcp
reason=TEST
ifcarrier=up
ifflags=4294936675
ifmtu=1500
ifwireless=0
new_broadcast_address=10.73.255.255
new_classless_static_routes='1.2.3.4/32 10.73.2.13 0.0.0.0/0 10.73.2.1'
new_dhcp_lease_time=3600
new_dhcp_message_type=5
new_dhcp_rebinding_time=3150
new_dhcp_renewal_time=1800
new_dhcp_server_identifier=10.73.0.1
new_domain_name=marples.name
new_domain_name_servers=10.73.0.1
new_host_name=netbsd
new_ip_address=10.73.1.62
new_network_number=10.73.0.0
new_routers=10.73.0.1
new_subnet_cidr=16
new_subnet_mask=255.255.0.0
old_broadcast_address=10.73.255.255
old_classless_static_routes='1.2.3.4/32 10.73.2.13 0.0.0.0/0 10.73.2.1'
old_dhcp_lease_time=3600
old_dhcp_message_type=5
old_dhcp_rebinding_time=2925
old_dhcp_renewal_time=1575
old_dhcp_server_identifier=10.73.0.1
old_domain_name=marples.name
old_domain_name_servers=10.73.0.1
old_host_name=netbsd
old_ip_address=10.73.1.62
old_network_number=10.73.0.0
old_routers=10.73.0.1
old_subnet_cidr=16
old_subnet_mask=255.255.0.0
dhcpcd exited
#

___
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 11/01/2019 16:52, Pali Rohár wrote:

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.


...


Also this patch adds support for allowing IPv6 address to be associated
with multiple hardware addresses, and gives dnsmasq permission to abandon a
lease. This is similar functionality as already supported for IPv4 address.


Can we get this by itself first? We should have this ability with DUID 
at least to match ISC dhcpd behaviour - and to be pinickity, IAID + type 
as well (IAID of 1 for example is different for IA_NA and IA_PD).


Then we can look at MAC address assignment as a smaller and later patch.

Roy

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

Re: [Dnsmasq-discuss] 3 secs dhcp delay

[Roy Marples]

On 17/01/2019 22:58, Simon Kelley wrote:

The delay is while dnsmasq tests the address it's about to allocate in
case some host is already using it. It sends a ICMP echo request
(essentially a ping) and if it gets a reply, the test fails. After a 3
second timeout the test succeeds and the address is allocated. If you're
happy that there are no machines using IP addresses without leasing
them, or that the similar test that DHCP clients do will find this, then
you can disable the check in dnsmasq using the --no-oing config flag.


NetBSD and Solaris do IPv4 DaD checks using ARP in the kernel, so the 
DHCP client doesn't strictly have to do anything other than listen to 
the kernel notifying the DaD result.


Roy

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

Re: [Dnsmasq-discuss] 3 secs dhcp delay

[Roy Marples]

On 21/01/2019 08:59, Harald Dunkel wrote:

But AFAICS strongswan's dhcp plugin doesn't, and
surely it is not alone.


Use another DHCP client that does then?
There's no reason why dhcpcd can't work with StrongSwan. You even get a 
DHCPv6 client for free which StrongSwan doesn't support.



Will dnsmasq offer another IP address in case it receives a decline?


It does with my testing, unless I hardcode the hardware address to a 
fixed IP. This results in an infinite loop, but there's no real way 
around that.


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

[Roy Marples]

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.

Roy

___
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] [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] DHCPv6: Honor assigning IPv6 address based on MAC address

[Roy Marples]

On 26/06/2019 21:16, Oliver Freyermuth wrote:

Am 26.06.19 um 21:49 schrieb Pali Rohár:

So, could somebody review and comment my patch?


Just to add on this:
I'm also using this patch in production since over a month now and it works 
very well for me (with dnsmasq 2.80).
Would really love to see this upstream.


Based on mailing list activity, Simon isn't involved much for reasons 
unknown. I suggest we pester him when he returns :)


Just to chime in, I'm using this in production as well with good success 
as well, even though it does go against some DHCP6 designs.


Roy

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

Re: [Dnsmasq-discuss] localise-queries and IPv6, rtod

[Roy Marples]

On 23/08/2019 06:31, For What It Worth wrote:

Routing Tables of Death - rtod - a kernel, routing protocol, and routing
daemon stress testing tool


See the README for how it works.


https://github.com/dtaht/rtod/blob/master/README.md starts with

rtod: Routing Tables of Death

rtod allows for the rapid injection and removal of large numbers of
distinct routes per host, as a means to test the capabilities of
kernels, routing protocols, and routing daemons.

Do NOT run this on a production network. DO read this documentation.

The rtod script was developed to stress test kernel routing features,
daemons, and protocols as a means to measure their behavior and make
them better.


Someone tested dhcpcd with a similar tool - 
http://docs.frrouting.org/en/latest/sharp.html.


The end result was moving the routing table from a linked list to a RB Tree.
https://roy.marples.name/blog/red-black-tree
Improved dhcpcd's performance from minutes to seconds with over a 
million routes!


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 IAID should be of unsigned type

[Roy Marples]

On 22/10/2019 17:17, Normen Kowalewski wrote:
FAIW - i was curious to see if RFC 8415 of November 2018, the update of 
the now officially obsoleted RFC 3315, uses some other wording, but it 
also just speaks about 4 octets that jointly are an unsigned integer

https://tools.ietf.org/html/rfc8415#section-21.21


https://tools.ietf.org/html/rfc8415#section-8

   All values in the message header and in options are in network byte
   order.

Pretty clear in my view.

The RFC obviously expects an implementor to know which data type in his 
specific environment and implementation would match this requirement - 
obviously for example it would be good if the on the wire format would 
not change by big endian/little endian diversions and so on...


No, the RFC (unless otherwise noted) expects all unsigned integers to be 
used in ntohl(3) and htonl(3) (or equivalents thereof depending on 
platform and integer size) to ensure endian does not affect on wire format.


Roy

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

Re: [Dnsmasq-discuss] dnsmasq sending truncated DHCPv6 packets

[Roy Marples]

On 02/12/2019 17:50, Geert Stappers wrote:

Please enlighten me or us, this mailinglist, why  I / we see ' > 
33:33:00:01:00:02 '
where I would expect to see ' > ff:ff:ff:ff:ff:ff '  (ethernet broadcast)


Observe the Destination and Source fields. The destination should be the 
DHCPv6 multicast MAC address 33:33:00:01:00:02 and the source should be 
your MAC address.

https://en.wikiversity.org/wiki/Wireshark/DHCPv6

Roy

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

Re: [Dnsmasq-discuss] NETLINK_NO_ENOBUFS not defined on old platforms

[Roy Marples]

On 19/03/2020 22:01, Simon Kelley wrote:

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0506a5ed4e56863627c54aedad30ad61221292ef


should handle both old kernel header files and old kernels, in any
combination.


I really dislike this approach because it makes the assumption that no other 
symbol will take No 5.


Whilst this might be true for generic linux, is it true for customised linux?
Or to put it another way I can point to many examples cross BSD where the ioctls 
differ in number but not name.


You might take the view "So what? We just support generic linux.".

I have started to take the hard stance with Arch Linux which shipped latest 
kernel headers and support that on an old LTS kernel. It's not maintainable 
because I've had 3 instances where dhcpcd used to do this and then promptly 
crashed on newer kernels because they had customised headers.


Modern software should not need this hack. Either #ifdef around it or require 
userland headers to define it. Don't hardcode it as it's not userlands 
responsibility to do it.


See the similar case where OpenBSD removed a ioctl but let it in the header - 
even worse!!


Roy

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

Re: [Dnsmasq-discuss] Length of the classless static routes dhcp-option

[Roy Marples]

On 08/07/2020 10:24, Slawek Kaplonski wrote:

I found out that dhcp-option is only 8 bits so it can be only 255 chars long.
I also found old email 
https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg06719.html
 with advice to use multiple dhcp-option=… fields to workaround this issue. So 
I did that and now my opts file looks like:

tag:tag0,option:classless-static-route,172.16.2.1/32,172.16.1.254
tag:tag0,249,172.16.2.1/32,172.16.1.254
tag:tag0,option:classless-static-route,172.16.2.10/32,172.16.1.254
tag:tag0,249,172.16.2.10/32,172.16.1.254
tag:tag0,option:classless-static-route,172.16.2.11/32,172.16.1.254
tag:tag0,249,172.16.2.11/32,172.16.1.254
tag:tag0,option:classless-static-route,172.16.2.12/32,172.16.1.254
tag:tag0,249,172.16.2.12/32,172.16.1.254
tag:tag0,option:classless-static-route,172.16.2.13/32,172.16.1.254
tag:tag0,249,172.16.2.13/32,172.16.1.254
tag:tag0,option:classless-static-route,172.16.2.14/32,172.16.1.254
tag:tag0,249,172.16.2.14/32,172.16.1.254
tag:tag0,option:classless-static-route,172.16.2.15/32,172.16.1.254
tag:tag0,249,172.16.2.15/32,172.16.1.254
….

But is seems for me that VM always only get last value set in the file. Is 
there any way to workaround this somehow and allow more static routes to be 
passed to the instance?


This also depends on the DHCP client in your VM.

AFAIK only two open source DHCP clients support RFC 3396 - dhcpcd and OpenBSD's 
dhclient.


Roy

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

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

[Roy Marples]

On 22/07/2020 13:42, Petr Menšík wrote:

You can use SLAAC for MAC generated addresses and they would be the same
regardless running OS.


This hasn't been true for a number of years because a few OS (and of course 
dhcpcd) have grown support for RFC 7217.


Now if they all used the same algorithm and secret key then they would have the 
same address. This is currenty only possible using dhcpcd (because it's not OS 
specific) but not OS vendors want to use dhcpcd by default.


Roy

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

Re: [Dnsmasq-discuss] Disabling IPv6 at compile time no longer working

[Roy Marples]

On 30/10/2020 15:30, Petr Menšík wrote:

It is year 2020, IPv6 is far too long with us to be optional.

Has it?

https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption

Looks to me like most of the world doesn't even have IPv6.
And thanks to Netflix blocking if you use an IPv6 tunnel that's out of the 
question as well.


> IPv4 support is not optional either.

This isn't entirely true either. IPv6 only networks *can* access IPv4 networks.
See RFC 6586 for details and pitfalls.

Roy

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

Re: [Dnsmasq-discuss] Cannot setup DHCP

[Roy Marples]

On Wed, 2004-12-01 at 16:39 +, Simon Kelley wrote:
> Илья Евсеев wrote:
> >Hi, folks!
> > I have dnsmasq-2.18 on my linux box with 2 network intefaces:
> > eth0 = 192.168.0.10/24 and eth1 = public IP.
> > /etc/dnsmasq.conf is like following
> > (I skip comments, blank lines and default values):
> > bind-interfaces
> > interface lo
> > interface eth0
> > expand-hosts
> > dhcp-range=192.168.0.50,192.168.0.150,12h
> > read-ethers  # really exists and accepted by dnsmasq
> > dhcp-option=42,0.0.0.0  # NTP server = dnsmasq host
> > 
> > Dnsmasq starts and acts as DNS-service successfully,
> > also listens on UDP port 67, _but_! does nothing
> > as DHCP-service: "dhcpcd -T eth0" sleeps until timeout.
> > Periodically dnsmasq puts to syslog following message:
> > "dnsmasq: no address range available for DHCP request via eth0".
> > 
> > I don't understand this error, because 192.168.0.50-150
> > is completely owned by 192.168.0.10/24.
> > Well, can somebody explain me: what's wrong here?
> > 
> > WBR, Ilya
> > 
> 
> Carefully check the configuration of eth0, both the netmask and 
> broadcast address. Dnsmasq uses that information when looking for a 
> valid DHCP range, and if (for instance) you had set the netmask to 
> 255.255.255.128, then you would see the behaviour you are describing.
> 
> It's possible to override the netmask and broadcast addresses by 
> including them in the dhcp-range, like so:
> 
> dhcp-range=192.168.0.50,192.168.0.150,255.255.255.0,192.168.0.255,12h
> 
> Are you using a DHCP relay? If so then including the netmask in the 
> dhcp-range is mandatory for networks connected via the DHCP relay.
> 
> Cheers,
> 
> Simon.
> 

I've seen this behaviour too with dhcpcd, but cannot get to the bottom
of it. I think it's dhcpcd's fault

If an entry exists for the host in dnsmasq.leases, then dhcpcd gets it's
address just fine and everything is dandy. If there is not an entry,
then dhcpcd times out - but still gets its information and an entry
appears in dnsmasq.leases

Other dhcp clients (dhclient, pump, udhcpc) do not have this problem
with dnsmasq. I was hoping to test dhcpcd against another dhcp server
before reporting this myself though.

HTH

-- 
Roy Marples 
Gentoo Linux Developer


signature.asc
Description: This is a digitally signed message part

[Dnsmasq-discuss] PATCH: Address some FQDN issues

[Roy Marples]

Hi

I've been working on some FQDN issues with dnsmasq. This patch addresses 
the following:

 * FQDN with just a hostname is NOT terminated (rfc4702 2.3)
 * Allow a blank FQDN message to request the hostname (rfc4702 2.3) 
(assuming no normal hostname option asked for)

 * if expand_hosts is set, send the domain_suffix if no domain supplied

Example config for the last item

expand-hosts
domain=marples.name
dhcp-host=ff:ff:ff:ff:ff:ff,10.1.2.3,foo
dhcp-host=,id:ff:ff:ff,foo

So for both DHCPv4 and DHCPv6 (the example is for INFORM, but also works 
for other types) the returned FQDN is foo.marples.name


Thanks

Roy--- rfc2131.c.orig	2013-07-21 08:41:27.0 +0100
+++ rfc2131.c	2013-07-22 17:49:26.0 +0100
@@ -387,6 +387,8 @@
 	{
 	  hostname = config->hostname;
 	  domain = config->domain;
+	  if (hostname && !domain && option_bool(OPT_EXPAND))
+	domain = daemon->domain_suffix;
 	}
 
   if (config)
@@ -504,7 +506,7 @@
   return message ? 0 : dhcp_packet_size(mess, agent_id, real_end);
 }
   
-  if ((opt = option_find(mess, sz, OPTION_CLIENT_FQDN, 4)))
+  if ((opt = option_find(mess, sz, OPTION_CLIENT_FQDN, 3)))
 {
   /* http://tools.ietf.org/wg/dhc/draft-ietf-dhc-fqdn-option/draft-ietf-dhc-fqdn-option-10.txt */
   int len = option_len(opt);
@@ -534,7 +536,7 @@
 	}
   
   if (fqdn_flags & 0x04)
-	while (*op != 0 && ((op + (*op) + 1) - pp) < len)
+	while (*op != 0 && ((op + (*op)) - pp) < len)
 	  {
 	memcpy(pq, op+1, *op);
 	pq += *op;
@@ -579,6 +581,8 @@
 {
   hostname = config->hostname;
   domain = config->domain;
+  if (hostname && !domain && option_bool(OPT_EXPAND))
+domain = daemon->domain_suffix;
   hostname_auth = 1;
   /* be careful not to send an OFFER with a hostname not matching the DISCOVER. */
   if (fqdn_flags != 0 || !client_hostname || hostname_isequal(hostname, client_hostname))
@@ -2267,7 +2271,7 @@
   if (fqdn_flags != 0)
 	{
 	  len = strlen(hostname) + 3;
-	  
+  
 	  if (fqdn_flags & 0x04)
 	len += 2;
 	  else if (null_term)
@@ -2275,6 +2279,8 @@
 
 	  if (domain)
 	len += strlen(domain) + 1;
+	  else if (fqdn_flags & 0x04)
+	len--;
 	  
 	  if ((p = free_space(mess, end, OPTION_CLIENT_FQDN, len)))
 	{
@@ -2286,8 +2292,10 @@
 		{
 		  p = do_rfc1035_name(p, hostname);
 		  if (domain)
-		p = do_rfc1035_name(p, domain);
-		  *p++ = 0;
+		{
+		  p = do_rfc1035_name(p, domain);
+		  *p++ = 0;
+		}
 		}
 	  else
 		{
--- rfc3315.c.orig	2013-07-21 08:38:14.0 +0100
+++ rfc3315.c	2013-07-22 17:32:11.0 +0100
@@ -459,6 +459,9 @@
 		}
 	}
 	}
+
+  if (state.hostname && !state.domain && option_bool(OPT_EXPAND))
+state.domain = daemon->domain_suffix;
 }
 
   if (config)
@@ -1299,16 +1302,25 @@
   size_t len = strlen(state->hostname);
   
   if (state->send_domain)
-	len += strlen(state->send_domain) + 1;
+	len += strlen(state->send_domain) + 2;
+  else if (state->domain)
+len += strlen(state->domain) + 2;
 
   o = new_opt6(OPTION6_FQDN);
-  if ((p = expand(len + 3)))
+  if ((p = expand(len + 2)))
 	{
 	  *(p++) = state->fqdn_flags;
 	  p = do_rfc1035_name(p, state->hostname);
 	  if (state->send_domain)
-	p = do_rfc1035_name(p, state->send_domain);
-	  *p = 0;
+	{  
+	  p = do_rfc1035_name(p, state->send_domain);
+	  *p = 0;
+	}
+	  else if (state->domain)
+	{
+	  p = do_rfc1035_name(p, state->domain);
+	  *p = 0;
+	}
 	}
   end_opt6(o);
 }
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] PATCH: Address some FQDN issues

[Roy Marples]

On 24/07/2013 14:29, Simon Kelley wrote:

I think this should happen already: for IPv4 calls to do_options have
the domain argument which is set to the result of  get_domain(address)
which will be domain-suffix unless there's a more specific example.


This is for INFOREQ where there is no address, but is assigned DHCP 
values via matching clientid/hwadddr.

Thus get_domain(address) is never called.

Thanks

Roy

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

Re: [Dnsmasq-discuss] Serving multiple addresses via DHCPv6

[Roy Marples]

On 07/09/2013 19:37, Simon Kelley wrote:

Best of luck. The DHCPv6 protocol allows this, in theory, but how it
should work in practice is not really settled, in my experience. Do
you have a DHCPv6 client that will do the work? All the clients I've
tested seem to only request or expect a single address.


dhcpcd-6 allows the requesting of >1 DHCPv6 address and should handle 
this correctly.
dhcpcd-6.0.5 may have issues and the latest git has a patch to fix this 
(didn't test earlier 6.0.x versions to be fair, should work but YMMV)

http://roy.marples.name/projects/dhcpcd/wiki/DhcpcdDownload

Example dhcpcd.conf

# Request two addresses with an IAID of 1 and 2
interface eth0
ia_na 1
ia_na 2


dnsmasq-2.66 includes a serious rewrite of the DHCPv6 code which
allows it to offer multiple addresses. You should use that, or
preferably the 2.67test releases, to have any chance of success.

Certainly don't expect it to "just work", but do report back on the
results of your efforts: we may be able to help further, and improve
dnsmasq in the process.


The above was tested against dnsmasq-2.66, works fine for me :)

Thanks

Roy

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

Re: [Dnsmasq-discuss] No IPv6 router advertisements for subnets other than /64?

[Roy Marples]

On 16/09/2013 10:44, Simon Kelley wrote:

SLAAC works by generating addresses by composing the prefix and the
so-called Interface Identifier.

RFC-4291 says: "For all unicast addresses, except those that start
with the binary value 000, Interface IDs are required to be 64 bits
long and to be constructed in Modified EUI-64 format."

and RFC-4862 says: "If the sum of the prefix length and interface
identifier length does not equal 128 bits, the Prefix Information
option MUST be ignored."

from which I deduce that the prefix length MUST be 64 when using SLAAC.


An advertised prefix does not mandate the use of SLAAC.

See a related discussion about DHCPv6 and prefix length here:
https://lists.isc.org/pipermail/dhcp-hackers/2013-September/002019.html

That has links elsewhere to use case's where the prefix is most 
definitely not /64.


Thanks

Roy

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

Re: [Dnsmasq-discuss] No IPv6 router advertisements for subnets other than /64?

[Roy Marples]

On 16/09/2013 11:44, Simon Kelley wrote:

That links seems to refer entirely to DHCPv6. Dnsmasq will allow
non-64 prefix lengths for DHCPv6. What we're talking about here is
rfc4861 router advertisements and I'm not sure how the discussion you
reference applies there.


It shows a case where a RA prefix is (from memory) /112 and the address 
is assigned by DHCPv6 and not SLAAC.

DHCPv6 has no prefix notion (thus each address would be /128).

Thanks

Roy

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

[Dnsmasq-discuss] Record FQDN on DHCPv6 INFORM

[Roy Marples]

Hi List

The majority of my IPv6 capable hardware doesn't grok DHCPv6.
This is fine and dandy, because it understands RS/RA just fine and some 
even work with the RDNSS and DNSSL RA options.
The way that I see it is that the RA can set the O bit so that a well 
formed client can then request extra information by DHCPv6.
This is in-fact needed as the Windows machines on the network don't grok 
RDNSS or DNSSL in the RA.


As such I handle all IPv6 address assignment using SLAAC entirely to 
avoid interfaces getting dual addresses and then scratching it's head 
over which one it should use.


The only problem with this is DNS - currently dnsmasq does not record 
the FQDN sent in a DHCPv6 INFORMATION REQUEST message.
Does anyone see a problem with recording this information? Useful for 
DHCPv4 as well?

Could this be recorded in the leases file safely?

Thanks

Roy

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

Re: [Dnsmasq-discuss] DhcpV6 how to send prefixlen and default route

[Roy Marples]

On 23/11/2013 14:06, dnsmasq.bertra...@dfgh.net wrote:

Hello,

Alwas some problems with my /97 prefix ...

on the client side dhclient say the prefix is /64
the router advertissement is ok with ridsc6 i see that i have /97 
prefix

in dhcp no option for prefixlen seems possible

Is a trick exists ?


DHCPv6 has no prefix or routing notation.

As such any address not derived from a Prefix Delegation has to use /128 
for a prefix.
dhcpcd does this and NetworkManager just dis-regards any dhclient 
returning information, also forcing a /128 prefix for the address.


If you require your hosts to be on the same IPv6 subnet then you'll need 
to advertise the /64 (or whatever) prefix in the RA and turn off the
ND_OPT_PI_FLAG_AUTO option. In rtadvd.conf(5) you can set 
pinfoflags="l", or rtadv I think the config option is AdvAutonomous off.

I don't know the dnsmasq config option for this :/

Thanks

Roy

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

[Dnsmasq-discuss] (no subject)

[Roy Marples]

Hi List

I've been adding RFC3925 Vendor-Identifying Vendor Options to dhcpcd(8) 
and testing against dnsmasq-2.67


I added this to dnsmasq.conf:
dhcp-option=vi-encap:12345, 1, "It is pitch black. You are likely to be 
eaten by a grue."

dhcp-option=vi-encap:12345, 2, 100

I added this to dhcpcd.conf (only works from my GIT head if anyone plays 
with it)

vendopt 12345 encap frobozzco
encap 1 string maze_location
encap 2 byte grue_probability

Firstly, dnsmasq says my 2nd config line is incorrect. How can I add a 
2nd option?
Secondly, this works via DHCPv4, but doesn't work for DHCPv6. How can I 
debug this? Wireshark shows a correct trace with the same enterprise 
number as the DHCPv4 trace.

By work dhcpcd sets:
new_frobozzco_maze_location='It is pitch black. You are likely to be 
eaten by a grue.'


Thanks

Roy

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

Re: [Dnsmasq-discuss] (no subject)

[Roy Marples]

On 06/12/2013 21:37, Simon Kelley wrote:

It fails at startup? I can't reproduce that. What's the exact message?


Ahem. A buggy config. my bad!

Secondly, this works via DHCPv4, but doesn't work for DHCPv6. How can 
I

debug this? Wireshark shows a correct trace with the same enterprise
number as the DHCPv4 trace.
By work dhcpcd sets:
new_frobozzco_maze_location='It is pitch black. You are likely to be
eaten by a grue.'


The relevant code for DHCPv6 has likely never been used in anger, so
it's not inconceivable that it's buggy.

Are you simply missing the OPTION_VENDOR_OPTS option in the reply?
Looking at the code, if there's an OPTION_ORO, then OPTION_VENDOR_OPTS
must appear in it, unless you use dhcp-option-force.


Yes, that's essentially it. The option is missing in the reply.
Here's a DHCPv4 and DHCPv6 trace.

I've not had time to peruse the dnsmasq source to try and fix and 
probably won't for a little while so hopefully it's an easy fix or you 
can tell me what I did wrong :)


Thanks

Roy

dhcpcd-vivo.pcapng
Description: Binary data
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] (no subject)

[Roy Marples]

On 07/12/2013 17:05, Simon Kelley wrote:

It took a scarily long time for the obvious to penetrate my brain.

The set of DHCPv4 and DHCP6 options don't overlap, so you have to
specify the options again for DHCPv6

# DHCPv4
dhcp-option=vi-encap:12345, 1, "It is pitch black. You are likely to
be eaten by a grue."
dhcp-option=vi-encap:12345, 2, 100

# DHCPv6
dhcp-option=vi-encap:12345, option6:1, "It is pitch black. You are
likely to be eaten by a grue."
dhcp-option=vi-encap:12345, option6:2, 100


Worked like a champ!
Thanks

Roy

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

[Dnsmasq-discuss] DHCPv6 same host different subnets

[Roy Marples]

Hi

According to this:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q3/007464.html

This should work
dhcp-host=id:00:01:00:01:XXX,[2a01:348:31:2::2],fred
dhcp-host=id:00:01:00:01:XXX,[2a01:348:31:3::2],fred

But it fails. I get the last address assigned to the 2a01:348:31:2 
subnet request.
This is running 2.68 on NetBSD, not tested the above config with earlier 
versions.


Thanks

Roy

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

Re: [Dnsmasq-discuss] DHCPv6 same host different subnets

[Roy Marples]

Different physical networks.
If it matters both networks are plugged into the router via USB dongles. One 
goes into a wireless AP and the other into an Ethernet Over Power point. For 
the curious the box itself only has one physical ethernet port which is plugged 
into a PPPoE modem.

For reference,  ISC dhcpd manages to do this fine provided you create dummy 
host entries for the same ClientID but with different fixed ips on each.

Roy


Sent from Samsung Mobile

 Original message 
From: Simon Kelley  
Date:  
To: dnsmasq-discuss@lists.thekelleys.org.uk 
Subject: Re: [Dnsmasq-discuss] DHCPv6 same host different subnets 
 
On 12/12/13 14:57, Roy Marples wrote:
> Hi
>
> According to this:
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q3/007464.html
>
> This should work
> dhcp-host=id:00:01:00:01:XXX,[2a01:348:31:2::2],fred
> dhcp-host=id:00:01:00:01:XXX,[2a01:348:31:3::2],fred
>
> But it fails. I get the last address assigned to the 2a01:348:31:2
> subnet request.
> This is running 2.68 on NetBSD, not tested the above config with earlier
> versions.
>

What's the server configuration? Are 2a01:348:31:2::
and 2a01:348:31:3:: on different networks, or the same physical network.

Cheers,

Simon.


___
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] Setting dns domain name through dhcpv6

[Roy Marples]

On 08/03/2014 8:36, Simon Kelley wrote:

On 07/03/14 21:42, Tom Hendrikx wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I'm using dnsmasq 2.66 to provide my local network with ipv4 dhcp, and
ipv6 information requests (ip addressing is handled by my router).

I'm able to to provide clients with a dns-server and such through
dhcpv6, but I'm failing to find the dhcp option that sets 'domain
lan.example.org' in /etc/resolv.conf, i.e. the v6 equivalent of
dhcp-option=option:domain-name,lan.example.org

Can anyone enlighten me? I've searching through
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml
but I'm failing to find something useful...


What you want is option 39, OPTION_CLIENT_FQDN


domain in resolv.conf(5) isn't normally used. I wouldn't expect any DHCP 
clients to put it there based on the FQDN.

dhcpcd(8) does :)

What you probably want is option 24, OPTION_DOMAIN_LIST which I would 
expect every DHCP client to fill out the search entry instead of the 
domain entry.
If you read resolv.conf(5) you'll find that both pretty much do the same 
thing, but search allows >1 entry.


Roy

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

Re: [Dnsmasq-discuss] Setting dns domain name through dhcpv6

[Roy Marples]

On 08/03/2014 12:07, Tom Hendrikx wrote:

I was already using the search option, but it was giving me some
headaches, mainly because what I actually was trying to get to work
was that 'hostname --fqdn' on the client would actually return the
correct fqdn from the dhcp network.


AFAIK that has nothing todo with either search or domain options in 
resolv.conf.
hostname --fqdn queries the nameservers to work out what the FQDN is 
based on your IP address.

This is also quite erroneous. Here's the Linux man page section:

==

the Fqdn
You can't change the FQDN (as returned by hostname --fqdn) or the DNS 
domain name (as returned by dnsdomainname) with this command. The FQDN 
of the system is the name that the resolver(3) returns for the host 
name.


Technically: The FQDN is the name gethostbyname(2) returns for the host 
name returned by gethostname(2). The DNS domain name is the part after 
the first dot.


Therefore it depends on the configuration (usually in /etc/host.conf) 
how you can change it. Usually (if the hosts file is parsed before DNS 
or NIS) you can change it in /etc/hosts.


If a machine has multiple network interfaces/addresses or is used in a 
mobile environment, then it may either have multiple FQDNs/domain names 
or none at all. Therefore avoid using hostname --fqdn, hostname --domain 
and dnsdomainname. hostname --ip-address is subject to the same 
limitations so it should be avoided as well.


==

As such, hostname should either be a single name (foo) or a FQDN 
(foo.bar.com) and the hostname program shouldn't do any DNS lookups at 
all.

That is what we have tools such as host(1) and dig(1) for.

Roy

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

Re: [Dnsmasq-discuss] Setting dns domain name through dhcpv6

[Roy Marples]

On 08/03/2014 11:30, Dave Taht wrote:

I'd like to note that we are trying to get away from resolve.conf.auto
in a couple cases, notably when you have multiple upstreams and you
want reverse queries to go to the right place.

A search list doesn't cut it in that case.

BUT supplying a search list makes sense to clients.


This is why we have resolvconf [1] which makes sense of many upstreams 
and ensures the queries goto the correct nameserver.
Of course, you need a more powerful resolver than libc along with 
resolvconf for this to work.


Thanks

Roy

[1] http://roy.marples.name/projects/openresolv

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

Re: [Dnsmasq-discuss] DHCPv6 and prefix length on clients

[Roy Marples]

On 2014-07-19 15:53, Niels Penneman wrote:
... but it has a prefix length of 128. Hence, the VMs cannot see each 
other.


My configuration explicitly specifies a prefix length of 64; what could
cause the prefix length to be set to 128 on the DHCPv6 client side?


DHCPv6 addresses have no prefix length, they are just an address, so 
always a /128.
What you need to do is advertise a /64 prefix, but with the M bit set 
and the AUTOCONF bit disabled.


That way the hosts you want off the IPv6 network will be aware of the 
prefix, but won't have a global address on it.


Roy

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

Re: [Dnsmasq-discuss] 6in4, dhcp srv still offers IPv4. is lan still needed?

[Roy Marples]

On 2014-09-22 19:48, glphvgacs wrote:

hello,
i posted a earlier version fo this on openwrt-users list with some
interesting responds. here is the tip of the thread just in case:
https://lists.openwrt.org/pipermail/openwrt-users/2014-September/003139.html



--/etc/dnsmasq.conf:
-BEGINS-
log-queries
log-dhcp
#cache-size=512
cache-size=1024
# i have used ,static here which resulted in no IPv6 being offered at 
all

# i tested earlier with (note 'static')
# dhcp-range=2001:470:1f07:12d::,static
# which resulted in no IPv6 being offered at all
dhcp-range=2001:470:1f07:12d::,ra-names
enable-ra
--/etc/dnsmasq.conf:
-ENDS---

client side log of DHCP negotiations for ethernet on my_machine:

dhcpcd[29585]: enp3s0: carrier acquired
dhcpcd[29585]: enp3s0: IAID 41:38:18:b0
dhcpcd[29585]: enp3s0: soliciting an IPv6 router
dhcpcd[29585]: enp3s0: Router Advertisement from fe80:::
dhcpcd[29585]: enp3s0: adding address 
2001:***:***7:***::::/64

dhcpcd[29585]: enp3s0: adding route to 2001:***:***:***::/64
dhcpcd[29585]: enp3s0: adding default route via 
fe80::6a7f:74ff:fe30:f2e2

dhcpcd[29585]: enp3s0: rebinding lease of 192.168.1.222
dhcpcd[29585]: enp3s0: leased 192.168.1.222 for 43200 seconds
dhcpcd[29585]: enp3s0: adding route to 192.168.1.0/24
dhcpcd[29585]: enp3s0: adding default route via 192.168.1.1
dhcpcd[29585]: enp3s0: Router Advertisement from fe80:::


now what i would like to happend is for dnsmasq to stop offering IPv4.
i.e. do dhcpv6 but no traditional dhcp.  in other words a pure IPv6 
network

with no IPv4 offered, something like this:
http://www.rfc-editor.org/rfc/rfc6586.txt


Maybe something in OpenWRT is giving dnsmasq a different config file or 
appending to it?
Check the running processes for the commandline launching dnsmasq for 
clues.


From a DHCP perspective, you may wish to enable RFC2563
https://www.rfc-editor.org/rfc/rfc2563.txt
This effectively allows a DHCPv4 transaction, but no IP address is sent 
to be leased AND a magic bit is sent instructing the client not to 
attempt IPv4LL.
Without this, dhcpcd which you use, in it's default state will assign an 
IPv4LL address due to the lack of a DHCP one.


I don't know of any other DHCP client which supports this, so YMMV.

Thanks

Roy

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

Re: [Dnsmasq-discuss] Shellshock.

[Roy Marples]

On Friday 26 Sep 2014 21:14:20 Simon Kelley wrote:
> This is just a heads-up that if you're using the --dhcp-script option in
> dnsmasq, and the script you're calling is being interpreted by bash,
> then you're affected by the shellshock bug.
> 
> The bug allows execution of arbitrary code contained in the values of
> environment variables, and there are several variables in the
> environment inherited by the DHCP script whose values can be set
> directly by a DHCP client, so any DHCP client on your network (or
> elsewhere, if your firewall allows) can execute arbitrary shellcode,
> probably as root, with a simple DHCP request.
> 
> The fix, of course, is to update bash.

What's your reason for not sanitising the variables?

I just released dhcpcd-6.4.7 which fixes this exact issue. I changed from 
using my custom sanitiser to svis(3) with VIS_CSTYLE | VIS_OCTAL and the 
output can be decoded using unvis(1).
Oddly enough this encoding matches the style dhcpcd was using previously which 
is a nice win for me.

glibc doesn't ship with svis(3), so I wrote a heavily stripped down NetBSD 
version which can be found here:
http://roy.marples.name/projects/dhcpcd/artifact/608ef4144b31cc21e3c811d1957cb836733e73bc

And the extra chars passed for sanitising:
#define ESCAPE_CHARS"|&;<>()$`\\\"'\t\n"

As noted here:
http://pubs.opengroup.org/onlinepubs/009604599/utilities/xcu_chap02.html
Section 2.2, quoting

Roy

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

Re: [Dnsmasq-discuss] Shellshock.

[Roy Marples]

Hi Simon

On Monday 29 Sep 2014 20:17:56 Simon Kelley wrote:
> There's no definition of what is allowed in those DHCP options, so it's
> quite possible that a shell metacharacter would be encountered.
> Sanitising the strings would therefore change what gets passed to the
> script, ie it would be an API change.

I've not looked at the dnsmasq source for this, but are you encoding binary 
non graphic data? If not, what is the expectation in script? If so, you are 
encoding it regardless - thus if you encode the shell metas in a similar 
fashion the API hasn't changed.

Just because the DHCP RFC for option foo says it's an ASCII string does not 
mean that's what is really in the option, could easily be a PNG of Rick 
Astley!

> Of course, the shell isn't supposed to interpret metacharacters in the
> value of shell variables unless explicitly told to: so sanitising
> shouldn't be required (though I concede it would mitigate a lot of
> common shell-script errors.)

Shells shouldn't allow function definitions in variables, but here we are :)

Thanks

Roy

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

Re: [Dnsmasq-discuss] Shellshock.

[Roy Marples]

On 2014-09-30 13:33, Nicholas Weaver wrote:

Although, to be honest, although the DHCP vector is trivial to exploit
[1], if the attacker can give you a bogus DHCP reply you've lost
already.

At this point, the attacker already has a full man-in-the-middle of
all network traffic, and can easily launch invisible attacks on
clients (e.g. cause a hidden iframe to appear to their metasploit
server instance, insert cached scripts into the browser context,
etc...).


http://tools.ietf.org/html/rfc3118
Although this does rely on you trusting the DHCP server and I admit it's 
a non trivial setup as not many servers or clients actually support it.



[1] the DHCP server on my test network has: option domain-name "() {
ignored;}; /bin/touch pwnage ; (/bin/sleep 10; /bin/ping -c 10
10.128.0.2) & "; in its config


I have similar in my server config, but as the server id :)

Roy

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

Re: [Dnsmasq-discuss] Shellshock.

[Roy Marples]

On 2014-09-29 20:17, Simon Kelley wrote:

On 27/09/14 11:01, Roy Marples wrote:

On Friday 26 Sep 2014 21:14:20 Simon Kelley wrote:
This is just a heads-up that if you're using the --dhcp-script option 
in

dnsmasq, and the script you're calling is being interpreted by bash,
then you're affected by the shellshock bug.

The bug allows execution of arbitrary code contained in the values of
environment variables, and there are several variables in the
environment inherited by the DHCP script whose values can be set
directly by a DHCP client, so any DHCP client on your network (or
elsewhere, if your firewall allows) can execute arbitrary shellcode,
probably as root, with a simple DHCP request.

The fix, of course, is to update bash.


What's your reason for not sanitising the variables?

I just released dhcpcd-6.4.7 which fixes this exact issue. I changed 
from
using my custom sanitiser to svis(3) with VIS_CSTYLE | VIS_OCTAL and 
the

output can be decoded using unvis(1).
Oddly enough this encoding matches the style dhcpcd was using 
previously which

is a nice win for me.


In the cold light day after shellshock I've come to the conclusion that 
you're right am I'm wrong.
Admittedly I was swayed by a SUSE security report which dealt with badly 
quoted shell scripts which addressed the issue by introducing some 
sanistisation into dhcpcd and I went from there.


Now, dhcpcd just sanistises according to the option encoding. So as most 
string options specify ASCII NVT dhcpcd will ensure that's what you get, 
stopping at the first invalid or non printable character. There are 
other encoding types such as domain, ascii, raw and binhex which will 
satisfy everything hopefully.

No more shell sanitising!

Roy

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

Re: [Dnsmasq-discuss] [PATCH v2 0/1] Use nanosecond granularity when checking for file changes.

[Roy Marples]

On 2014-10-03 21:08, Simon Kelley wrote:

This looks fine, but I have a vague worry about breaking the build on
old C libraries that don't define the st_mtim field. Does anyone know
when this entered the standard?


It's not in *any* accepted standard other than glibc.
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html

Please #define accordingly, for OS's other than Linux w glibc.

Roy

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

Re: [Dnsmasq-discuss] [PATCH v2 0/1] Use nanosecond granularity when checking for file changes.

[Roy Marples]

On 2014-10-03 22:13, Roy Marples wrote:

On 2014-10-03 21:08, Simon Kelley wrote:

This looks fine, but I have a vague worry about breaking the build on
old C libraries that don't define the st_mtim field. Does anyone know
when this entered the standard?


It's not in *any* accepted standard other than glibc.
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html

Please #define accordingly, for OS's other than Linux w glibc.


Or tackle the problem a different way:

Store st_mtime, add a 2 second timeout to the event loop to look again 
at the file
If the st_mtime is the same as stored read it, otherwise timeout for 
another 2 seconds.

Once read, poll at normal intervals (whatever they are).

Or go the proper way and use inotify for linux and kevent for BSD and 
get file change notifications rather than the inefficient polling.


Roy

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

Re: [Dnsmasq-discuss] Announce: dnsmasq-2.73rc1

[Roy Marples]

On 20/03/2015 12:49, Alfonso Ranieri wrote:
> Il 20/03/2015 00:42, Simon Kelley ha scritto:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> I want to start the release-process towards 2.73. There's a whole heap
>> of good stuff since 2.72, and good reasons to get it out there before
>> proceeding further with stuff that's in progress.
>>
>> Please test if you can, code is available at
> 
> I, am using dnsmasq in a small router firmware for some Netgear router
> modem.
> 
> To make the new inotify system dnsmasq compile under my toolchain (which
> is gcc 4.2.2, kernel 2.6.30, uClibc 0.9.29) I had to make these changes
> (expecially realpath() wants the second args to be not NULL)
> 
> --- src/inotify.c.orig  2015-03-20 13:44:29.0 +0100
> +++ src/inotify.c   2015-03-20 13:44:42.0 +0100
> @@ -19,6 +19,13 @@
> 
>  #include 
> 
> +#ifndef IN_CLOEXEC
> +#ifndef O_CLOEXEC
> +#define O_CLOEXEC 0200
> +#endif
> +#define IN_CLOEXEC O_CLOEXEC
> +#endif
> +
>  #ifndef IN_NONBLOCK
>  # define IN_NONBLOCK O_NONBLOCK
>  #endif
> @@ -57,7 +64,9 @@
>for (res = daemon->resolv_files; res; res = res->next)
>  {
>char *d = NULL, *path;
> -  if (!(path = realpath(res->name, NULL)))
> + char _b[256];
> +
> +  if (!(path = realpath(res->name, _b)))
> {
>   /* realpath will fail if the file doesn't exist, but
>  dnsmasq copes with missing files, so fall back

While that may compile, it surely won't work.
If O_CLOEXEC doesn't exist, then you need to set FD_CLOEXEC via fnctl(2)

Roy


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

Re: [Dnsmasq-discuss] [PATCH] Nack requests for unknown leases.

[Roy Marples]

On 25/04/2017 08:08, Alin Năstac wrote:
> I'm talking about second case, the "static" one. The use case is this:
> 1) Client A using ISC DHCP client gets a lease from a different LAN called X
> 2) Client A gets disconnected from LAN X and connected to LAN Y where
> dnsmasq DHCP server runs in a non-authoritative mode.
> 3) Client A is connected to LAN Y (where dnsmasq serve as DHCP server)
> and sends a DHCP requests asking for the same IP address used in LAN X
> 4) dnsmasq does not have a lease for that IP address so it ignores the 
> requests
> 5) After a couple of seconds client A sends a DHCP discovery carrying
> the same option-50 as the DHCP requests at step 3
> 6) dnsmasq will happily lease the requested IP address without
> checking if there is another host that use it; unfortunately there is
> another statically configured host B that use the same address.

Irregardless of dnsmasq, ISC dhclient *should* ARP probe to check the
offered address isn't in use. If changing to another DHCP client which
does do this (like say dhcpcd) or fixing dhclient then consider using an
OS which enforces ARP address validation like say NetBSD or Solaris -
not that dhclient will actually do anything about the invalidated
address on these OS's, but that's another topic.

This is important, because dnsmasq could be being a DHCP relay and may
not be able to ICMP ping the requested IP address - hence both sides
need to validate.

Roy

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