FTL fails to start with conditional forwarding enabled

[aidenmitchell]

Versions

Pi-hole version is v5.5 (Latest: v5.5)
AdminLTE version is v5.7 (Latest: v5.7)
FTL version is release v5.10.1 (Latest: v5.10.1)

Platform

• OS and version: Ubuntu 20.04.3

• Platform: VM on ESXi

Expected behavior

Conditional forwarding works / FTL doesn't fail to start.

Actual behavior / bug

FTL failed to start due to address part not zero at line 44 of /etc/dnsmasq.d/01-pihole.conf

Steps to reproduce

Steps to reproduce the behavior:

1. Enable conditional forwarding
2. Click "Save."
   Disabling conditional forwarding fixes the issue.

Debug Token

• URL: https://tricorder.pi-hole.net/dt2GmB7x/
  Note: this is without conditional forwarding on, it would not upload with FTL failed

[churchofnoise]

I have the same issue on a barebone installation running rpi os bullseye.
Problem was solved by switching off conditional forwarding.

Bizarrely, when I wanted to recreate it, I couldn't (and I can't remember if the local network and DHCP server address were different before). Also, the SSH session into my RPI was lost so sadly don't have the token for the debug log anymore...

[yubiuser]

I can confirm the bug. I'm pretty sure it's an upstream but in dnsmasq as the whole conditional forwarding was reworked lately.

[DL6ER]

Could you upload your 01-pihole.conf so I can have a look at them?

Run

cat /etc/dnsmasq.d/01-pihole.conf | pihole tricorder

[DL6ER]

It comes from

FTL/src/dnsmasq/option.c

Lines 971 to 976 in db8ee8c

	for (i = 0; i < addrbytes; i++)
	if (((u8 *)addr4)[3-i] != 0)
	break;
	if (i != addrbytes || (((u8 *)addr4)[3-addrbytes] & ((1 << addrbits) - 1)) != 0)
	return _("address part not zero");

which was not part of the patch I submitted upstream.

[DL6ER]

The solution will be to set the network to something like 192.168.1.0/24 where the important bit is the zero on the last nibble of the address. Sorry for that, this is definitely a regression and I'll contact Simon, the dnsmasq maintainer, about it

[DL6ER]

@aidenmitchell @churchofnoise @yubiuser Could you try

pihole checkout ftl fix/rev-server

to see if it fixed the hard fail even if you leave the rev-server line as it is?

Sorry for the inconvenience, we're doing our best to get this dnsmasq bug fixed as soon as possible. We already submitted the proposed solution we added here to upstream.

[churchofnoise]

Tried and the problem doesn't reoccur!

[pralor-bot]

This issue has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/new-setup-issues/50028/2

[aidenmitchell]

@aidenmitchell @churchofnoise @yubiuser Could you try

pihole checkout ftl fix/rev-server

to see if it fixed the hard fail even if you leave the rev-server line as it is?

Sorry for the inconvenience, we're doing our best to get this dnsmasq bug fixed as soon as possible. We already submitted the proposed solution we added here to upstream.

Yep, that works perfectly.