Bug#1122015: systemd: autopkgtest 'test upstream' fails with dnsmasq 2.92~rc1-1

[Simon Kelley]

Random stuff I've found out about this.

1) This is a systemd test that's failing.
2) Googling got me to

https://github.com/systemd/systemd/blob/main/test/test-network/systemd-
networkd-tests.py#L8634

which seems to start a dnsmasq instance with deliberately broken strings 
in a DHCPv6 option 103 and DHCPv4 option 114. The strings have zero 
chars embeded in them.

3) dnsmasq commit

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ded935be3708f7df2c836046bd73b373a1dc40ac

defines 103 and 114 for the first time in dnsmasq and sets the data type 
to be OT_NAME. That's the change that's broken this for 2.92~rc1-1

Associating OT_NAME with those two options affects two bits of dnsmasq 
code. One is the option-parsing code in  parse_dhcp_opt() which is a 
rather scary set of heuristics that converts the ascii string for an 
option into a set of octets that go into a DHCP packet. The knowledge 
that the invalid url is in fact a string, may affect that process. The 
second is  option_string() which will strip characters which fail 
isprint() from OT_NAME options when logging option values.

I guess one or both of these is changing the results of the test.


I don't think that dnsmasq is doing anything wrong here, and I tend to 
push this onto the systemd tests. I don't understand what the test is 
trying to achieve, but it looks like it's interpreting different, but 
correct, behavior in dnsmasq as a problem.


Some clues, at least.

Simon.

On 12/5/25 21:04, Sven Geuer wrote:
> Source: systemd
> Version: 259~rc2-1
> Severity: important
> X-Debbugs-Cc: Simon Kelley <simon at thekelleys.org.uk>
> Control: affects -1 + src:dnsmasq
> 
> Dear Maintainer,
> 
> in testing, autopkgtest 'test upstream', apparently executed only on
> amd64 architecture, fails with dnsmasq 2.92~rc1-1 from unstable [1]. It
> specifically fails in TEST-85-NETWORK-NetworkdDHCPClientTests,
> test_dhcp_client_reject_captive_portal [2]. Tests with dnsmasq 2.91-1
> succeeded [3].
> 
> As to me, the logs don't reveal enough details about how dnsmasq might
> trigger this failure. I therefore ask for help on this issue.
> 
> PS.: No other autopkgtest involving dnsmasq shows abnormalities [4].
> 
> Sven
> 
> [1] https://ci.debian.net/packages/s/systemd/testing/amd64/66853256/#S64
> [2] https://ci.debian.net/packages/s/systemd/testing/amd64/66853256/#L22325
> [3] https://ci.debian.net/packages/s/systemd/testing/amd64/66721530/#S64
> [4] https://qa.debian.org/excuses.php?package=dnsmasq
>