[Dnsmasq-discuss] [PATCH] dnsmasq unit tests!
Hello everyone, we have merged support for multiple IPv6 addresses to our release in RHEL. We tried to ensure it does not break anything and we failed. I made already some dnsmasq tests in separate repository [1], running in network namespaces. There are two kinds of tests. Simple shell backed bats tests in bash. bats and bash packages are required to run them. Second kind are few tests in beakerlib [2], which is test framework used in Fedora and RHEL testing. They exist and can test few things. But now, I have accomplished creating few unit tests [3] for dnsmasq. They are kind of hack, but they should allow basic testing of options working. I used cmocka library. Dnsmasq is not very well prepared for unit testing, but some parts can be tested. It is much easier to test just code, without providing fake network configuration. I want to use it to ensure no change in DHCP breaks expected behaviour. It is much easier to prepare code changes than full fledged functional test, emulating real request over network. I would love if you could try it and tell me what you think about it. I am attaching squished patch, separate commits are at our github [3]. If someone would like to add some test, please create a pull request! If you would like to try it: git clone -b unittests https://github.com/InfrastructureServices/dnsmasq.git cd dnsmasq make cd tests make ./option_test ./dhcp_test Since these are related to dnsmasq internals, I think merge to master would be nice eventually. Some parts of dnsmasq should be adjusted for easier testing, I have to prepare some changes. It might be starting block to ensure new releases do not break existing functionality. Any opinions would be appreciated too. Cheers, Petr 1. https://github.com/InfrastructureServices/dnsmasq-tests 2. https://github.com/beakerlib/beakerlib 3. https://github.com/InfrastructureServices/dnsmasq/tree/unittests/tests -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB >From 9395cc84f93c63573ba28e4e349c44adb5dbb34d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= Date: Mon, 4 May 2020 16:26:17 +0200 Subject: [PATCH] Create unittests with dhcp and option tests MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Squashed commit of the following: commit 715c420bf069a6c4fce2238816ff2c3fe371c4c8 Author: Petr Menšík Date: Mon May 4 16:00:31 2020 +0200 Add mixed DHCP test entries for both IPv4 and IPv6 Ensure it works also with both ways. commit c288ca9651ab0f1b777cc938c8e175f55e3819c2 Author: Petr Menšík Date: Mon May 4 15:42:45 2020 +0200 Merge all objs and add licenses Stop using workarounds for option test, use full objects from dnsmasq, without few exceptions. Updated also all files to include license headers. commit 33cdd6a312947cdc7d83f0cbf59d22ffd1ccd036 Author: Petr Menšík Date: Mon May 4 15:20:09 2020 +0200 Add starting parameters to dnsmasq Ensures dnsmasq does not read configuration from the system. commit 2aed21f9aa1fe42d94bb67d1b0fe630a56096c91 Author: Petr Menšík Date: Mon May 4 15:04:35 2020 +0200 Fix dhcp test Prepare two basic tests for ipv4 parsing and ipv6 parsing in separate configuration. Check mac-assigned configuration gets different hostname than just hostname matched entry. commit 4ccf8a664abad1e5079f6422f50fe3500152bbf2 Author: Petr Menšík Date: Mon May 4 15:03:21 2020 +0200 Do not optimize, fix multiple tests in one file commit 6408f8d8af43b5727828571fe5d78c69fbd1361f Author: Petr Menšík Date: Mon May 4 11:22:47 2020 +0200 Add rule to create cscope commit 2568d4b18286b6c5d844604fb1fad2631e9378e4 Author: Petr Menšík Date: Mon May 4 11:22:36 2020 +0200 Add gitignore file commit d687698363709b872c80f9c6e0d5ae5c7c27cdac Author: Petr Menšík Date: Mon May 4 11:22:20 2020 +0200 Create dhcp_test Use most of source files with exception of dnsmasq.o. Solve undefined symbols with fake test commands. Currently compiles, but crashes. commit e0e686a9106a78c8ecdc0b0a8d42bdcbdbf7f617 Author: Petr Menšík Date: Mon May 4 11:22:04 2020 +0200 Add first basic option test commit 10e9cf5d0b589af839dd806c6cf7e87ca2e310ce Author: Petr Menšík Date: Sat May 2 10:28:44 2020 +0200 Basic core for unit tests Have to fix yet pending unresolved symbols. --- Makefile| 2 +- tests/.gitignore| 3 + tests/Makefile | 51 +++ tests/dhcp_test.c | 315 tests/option_test.c | 47 +++ tests/test.h| 28 tests/testcore.c| 35 + tests/testlib.c | 85 8 files changed, 565 insertions(+), 1 deletion(-) create mode 100644 tests/.gitignore create mode 100644 tests/Makefile create mode 100644 tests/dhcp_test.c create mode 100644 tests/option_test.c create mode 100644
[Dnsmasq-discuss] lease time affects ipv6 prefix life time
I have this in dnsmas.conf to advertise the current ipv6 prefix:
dhcp-range=::,constructor:${interface},slaac,ra-names,64,${lease_time}
enable-ra
If the prefix gets changed, dnsmasq starts to announce the new prefix, but it
keeps announcing the old one (as deprecated) as well for a while.
I wonder why the value of ${lease_time} is not used verbatim? It is forced to
be at least 120, which might be fine for real DHCP. In practice this means a
stale and unusable prefix is announced as "valid = 120, preferred = 0" for
about two minutes. It seems clients can cope with it. Still, I would like to
zap the old prefix "instantly" with lease_time=1.
Olaf
pgpyWw4ZnebZr.pgp
Description: Digitale Signatur von OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] authoritative reverse zone
Hi, I'm attempting to set up dnsmasq in my lab and wish it to be authoritative for various internal test domains. I'm not setting up global DNS as these are all internal-only. I've setup a minimal config as follows: no-dhcp-interface= no-resolve local-ttl=60 server=ip.of.upstream server=/second.test/172.28.140.10/ auth-server=ns.int.my.domain auth-zone=first.test,172.28.136.0/24 host-record=a1.first.test,172.28.136.10 With the above, I can "dig SOA first.test @localhost" and I get the NS and SOA record. I can also "dig a1.first.test @localhost" and I get the A record and can "dig -x 172.28.136.10 @localhost" and I get the PTR record. However, if I "dig SOA -x 172.28.136.0 @localhost" I see the query, but no answer. Monitoring the logs shows dnsmasq forwarding it upstream. The last paragraph of the man page under auth-zone says that the IP address and subnet is for reverse-DNS queries. Am I missing something? Shouldn't I get the SOA record of the reverse-DNS lookup? Thanks in advance, Gareth ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Regression in 2.81 related to support for multiple IPv6 addresses
On Fri, 2020-05-01 at 16:52 +0200, Harald Jensas wrote: > On Fri, 1 May 2020, 16:28 Petr Menšík, wrote: > > Hi Harald and Geert, > > > > I looked at it and it is quite confusing what it does. Not quite > > simple > > to understand. I think it is not uncommon for dnsmasq code, but > > this > > brings more knobs to make it more complicated. > > > > I tried to rewrite it hopefully with less repetitions and cleaner > > code. > > However when I did this, I have realized current algorihm is quite > > bad. > > > > When dnsmasq would have 40 client records for dhcp-host, it would > > have > > to walk throught that list about 4*40 times for every DHCP request. > > It > > seems to me smarter sorting of dhcp_configs would allow single or > > two > > passes. Just push the most specific records with client ids and > > hwaddr > > first, then just hostnames. > > > > Anyway, I think some unit test would be needed. Any opinions on my > > patches. Have not yet tested them in real network. > > > > Cheers, > > Petr > > Hi Petr, > > I looked at the patches, I think the refactoring looks good. > > I am slightly worried about the sorting, I know openstack neutron > does sorting to ensure IPv4 records come before records without > address (IPv6 stateless). Look at the docstring[1] for details. In > the future I would like to use tag:dhcpv6 in neutron instead of > sorting, but that is'nt really possible before most distros have a > version of dnsmasq with support for tags in host definitions. > On second review of this, afaict the matching based on address family makes the sorting currently done in Openstack neutron redundant. With these patches dnsmasq will prefer the entry with the IPv4 address, thus sorting the hosts file to ensure the IPv4 entry is "first" would no longer be required. A quick test verifies this is the case, i.e both configs below allow the DHCPv4 client to succeed: # IPv4 entry last: dhcp-host=52:54:00:bc:c3:fd,set:foo-tag,host2-foo dhcp-host=52:54:00:bc:c3:fd,172.20.0.11,host2 # IPv4 entry first: dhcp-host=52:54:00:bc:c3:fd,172.20.0.11,host2 dhcp-host=52:54:00:bc:c3:fd,set:foo-tag,host2-foo On master the configuration with the IPv4 entry first fails. > Today is a public holiday for me, and I am away from computers. I > will do some testing as soon as I am back home. > I did some tests with Petr's two patches applied: Both clients succeed regardless of order in config: dhcp-host=52:54:00:bc:c3:fd,[fd12:3456:789a:1::aadd],host2 dhcp-host=52:54:00:bc:c3:fd,172.20.0.11,host2 and dhcp-host=52:54:00:bc:c3:fd,172.20.0.11,host2 dhcp-host=52:54:00:bc:c3:fd,[fd12:3456:789a:1::aadd],host2 Using a prefix for IPv6 still works: dhcp-host=52:54:00:3f:5c:c0,[fd12:3456:789a:1::aa08/126],host1 Using a list for IPv6 still works: dhcp-host=52:54:00:3f:5c:c0,[fd12:3456:789a:1::aa02],[fd12:3456:789a:1::aa04],[fd12:3456:789a:1::aa06],host1 My conclusion is that Petr's proposed patches are good. > [1] > https://opendev.org/openstack/neutron/src/branch/master/neutron/agent/linux/dhcp.py#L572 > > > // > Harald > > > On 4/30/20 11:07 AM, Harald Jensås wrote: > > > On Wed, 2020-04-29 at 16:18 +0200, Harald Jensås wrote: > > >> Hi, > > >> > > >> We discovered an issue introduced in this commit: > > >> 137286e9baecf6a3ba97722ef1b49c851b531810 > > >> > > >> Prior to this commit one could have two dhcp-host entries, one > > for > > >> IPv4 > > >> and another for IPv6, for example: > > >> > > >> dhcp-host=52:54:00:bc:c3:fd,172.20.0.11,host2 > > >> dhcp-host=52:54:00:bc:c3:fd,[fd12:3456:789a:1::aadd],host2 > > >> > > >> This no longer works. In the above example dhcpv6 client > > succedes, > > >> but > > >> the dhcpv4 client get 'no address available'. Swapping the order > > of > > >> the > > >> two entries in the config file allow the dhcpv4 client to > > succeed, > > >> but > > >> then the dhcpv5 client fails. > > >> > > >> Alternative configurations that do work in 2.81: > > >> > > >> dhcp-host=52:54:00:bc:c3:fd,172.20.0.11,host2 > > >> dhcp- > > >> host=tag:dhcpv6,52:54:00:bc:c3:fd,[fd12:3456:789a:1::aadd],host2 > > >> > > >> or: > > >> > > >> dhcp- > > >> > > host=52:54:00:bc:c3:fd,172.20.0.11,[fd12:3456:789a:1::aadd],host2 > > >> > > >> > > >> I'm not sure using two dhcp-host entries was ever intended to > > work, > > >> as > > >> the manual page states that both ipv4 and ipv6 address can be > > defined > > >> in a single entry. > > >> > > >> A first tought for possible fix would be to internally set the > > >> 'tag:dhcpv6' for any dhcp-host entry with only ipv6 addresse(s). > > >> > > > > > > An attempt for a fix, preferring dhcp-host entries with > > CONFIG_ADDR or > > > CONFIG_ADDR6 flag set. With this change I can use these two > > configs > > > successfully: > > > > > > dhcp- > > host=52:54:00:bc:c3:fd,172.20.0.11,[fd12:3456:789a:1::aadd],host2 > > > or > > > dhcp-host=52:54:00:bc:c3:fd,[fd12:3456:789a:1::aadd],host2 > > >
