Remove hardcoded IP address 172.20.0.1

[jacobsvante]

I noticed in the guide that you set 172.20.0.1 as the IP address for the provisioner. Is there any specific reason for this?

At least with my UniFi router it was quite easy to use another IP.

Here's the configuration I did on the router:

1. Create a separate network
2. Map the provisioner device's port to this new network
3. Do the same for the CM4-to-provision port
4. Set a fixed IP for the provisioner so that it doesn't change
5. Configure DHCP TFTP server IP in settings to the provisioner's fixed IP address

Now all I needed to do on the CM4 device was to change the hardcoded IP address in /var/lib/cmprovision/scriptexecute/cmdline.txt to the provisioner's IP. Then voila, provisioning works smoothly!

To avoid hardcoding - Perhaps you could add a setting in the Webui for the provisioner server IP? Defaulted to 172.20.0.1 for backwards compatibility.

[maxnet]

I noticed in the guide that you set 172.20.0.1 as the IP address for the provisioner. Is there any specific reason for this?

Yes.
To make it harder for the user to misconfigure cmprovision to act as a DHCP server on the wrong network.

Handing computers on your normal office network an IP-address without gateway that will not give them Internet connectivity is not so nice.

Here's the configuration I did on the router:

Configure DHCP TFTP server IP in settings to the provisioner's fixed IP address

Don't think it is listening to your router's DHCP server.
The Pi boot firmware will only respond to PXE packets that contain the magic string "Raspberry Pi Boot"

If it is working, it is likely that you have cmprovision's DHCP server running as well...

To avoid hardcoding - Perhaps you could add a setting in the Webui for the provisioner server IP?

I am missing the problem you are trying to solve.
Why is it a problem that cmprovision uses 172.20.0.1/16 ?

And letting users bring their own DHCP server also introduces a lot of problems, we prefer not to give technical support on.
It usually will not work, unless you configure your DHCP server to send "Raspberry Pi Boot"
And it is easy to misconfigure it.
E.g. if a user let it hand out IP-addresses from a /24 pool and the addresses have a lease time of 1 week -which is a pretty common router configuration- it can cause problems if user wants to provision more than 128 devices per week.
(Each device can claim 2 IP-address because DHCP client of boot firmware, and DHCP client of Linux that gets booted use different client ID when making requests).

[jayjayseal]

It works if you disable DHCP or set the network's DHCP relay to the CMprovision server ip (in Unifi).
Also Enable DHCP guarding and set the cmprovision server ip (it will restrict the switches to only allow this IP to serve DHCP leases and blocks others from doing so. It also does not notify you that the cmprovison is a "Rogue" DHCP server)

Also make sure the gateway ip (in unifi) is not X.X.X.1 but 2 for example

Example in unifi's network config

Gateway IP : 192.168.200.2(/24)
Network Broadcast IP: 192.168.200.255
Network IP Count: 254
Network IP Range: 192.168.200.1 - 192.168.200.254
Network Subnet Mask: 255.255.255.0

Reserve 192.168.200.1 for your cmprovision server ip.
Configure dnamasq to set the gateway and DNS to your unifi gateway. This way your devices can access the internet after provisioning (in auto reboot scenarios)

dnsmasq.conf
dhcp-option=6,192.168.200.2
dhcp-option=3,192.168.200.2

In the example above you will also have to change the subnetmask to 255.255.255.0 instead of 255.255.0.0

Also remember to change cmdline.txt to the correct ip.

See, It's not as simple but it works. It's probably not cmprovision not answering... it's the switch refusing :)