Working Process
Figure 1 shows how SZTP works.
The SZTP working process involves the following phases:
- The device sends a DHCP request packet to the DHCP server, which then returns a DHCP reply packet carrying an address to be allocated to the device and also carrying the bootstrap server address through Option 143.
- The device establishes a secure TLS connection with the bootstrap server using the preset identity certificate (IDevID) through two-way authentication.
The IDevID, which contains information such as the ESN of the device and the public key, must be preset before the device is delivered so that a TLS connection can be established with the bootstrap server.
- After obtaining bootstrapping data from the bootstrap server, the device may be redirected to another bootstrap server based on the Redirect Information field. However, the device will eventually parse the onboarding information that contains the version file information.
- When detecting that its system software and patch file are different from those on the version file server, the device downloads the system software and patch file from the version file server after verifying data validity, and then restarts.
- After the restart, the device repeats the steps in phases 2 to 4. Because the system software and patch file on the device are now the same as those on the version file server, the device downloads the configuration file, verifies data validity, and performs the replacement operation to make the configuration take effect without invoking a restart.
- The SZTP function itself does not save the downloaded configuration file.
- If the device has saved the configuration file, it does not enter the SZTP process upon the next restart. To enable the device to enter the SZTP process upon each restart, perform the following steps:
- Disable the automatic configuration saving function in the configuration file.
- Ensure that the DHCP server, bootstrap server, and version file server are always enabled.