Is your feature request related to a problem? Please describe.
.

Describe the solution you'd like
I would like ztpd --version to output the version that the ztpd binary is. To my knowledge there is no other way to check the version of the binary. Having this information outputted in the logs would also help debugging.

Describe alternatives you've considered
.

Additional context
.

I noticed that if ztpd_run() returns a negative error code then nothing will be deinitialized before the main() function exits. Currently ztpd is all single-threaded, so this isn't an issue, as when the process exits all memory the process used will be released by the kernel. However, if in the future someone decides to add multi-threaded or multi-process capabilities to ztpd this will result in a possible memory leak. I thought I'd make note of this here just in case that happens.

Is your feature request related to a problem? Please describe.
The code to manage the event loop was written from scratch. During early development, there were not many event loop features that were needed, so a hand-written one allowed rapid prototyping. However, the event loop has become more complicated and so, it may be a better idea to replace the hand-written event loop code with a publicly available, well documented and tested event library.

Describe the solution you'd like
The hand-written event code should be replaced with a well-tested, open-source event library for C. Many popular event libraries available, the following libraries are a good start for consideration:

• libevent
• libev
• libuv

Describe alternatives you've considered

• Leave the event loop as it is. This risks more complicated maintenance and requires more bootstrap time for onboarding.

Additional context

• None

Is your feature request related to a problem? Please describe.
Enrollee configuration currently only supports bootstrapping type qrcode. Internally, this requires/forces the use of the TPM openssl engine which means systems without a TPM cannot be used for testing.

Describe the solution you'd like
An option should be configurable for enrollees to specify a static DPP bootstrapping key for use with bootstrapping type qrcode. For example, the json configuration could look something like this:

{
    "bootstrap.info": {
        "type": "qrcode",
        "keyType": "static",
        "key": "30570201010420777fc55dc51e967c10ec051b91d860b5f1e6c934e48d5daffef98d032c64b170a00a06082a8648ce3d030107a124032200020c804188c7f85beb6e91070d2b3e5e39b90ca77b4d3c5251bc1844d6ca29dcad"
    }
}

There could even be an auto-generation method where ztpd auto-generates a bootstrapping key and outputs it somewhere that is easy to be found (eg. journald logs or a file). Eg.

{
    "bootstrap.info": {
        "type": "qrcode",
        "keyType": "generate"
    }
}

wpa_supplicant already supports this when creating a new bootstrapping key without also providing private key (it get's auto-generated on first use). The public key can be obtained later using the bootstrapping id and the DPP_BOOTSTRAP_GET_URI <ID> control socket command.

Describe alternatives you've considered
Alternatives are currently to program wpa_supplicant manually using cli tools (eg. wpa_cli). This is clunky and disrupts instrumentation between ztpd and wpa_supplicant, and is annoying for our partners to use since they then have to mess with systemd unit configuration resets and custom configuration.

Additional context
Our partner engineering teams need a better method to test their configurator against our enrollee without too much effort/ramp-up/setup. A similar method exists for the configurator, the file based BIP, which allows specification of static DPP URIs for supported enrollees. The request here is to provide an analogous option for enrollee testing.

Is your feature request related to a problem? Please describe.
Static code analysis is needed to detect easy/obvious bugs. PR completion should be gated based on the analysis output (no new issues introduced).

Describe the solution you'd like
Enable basic static code analysis tools to scan the code as part of the PR process and gate PR completion on it. CodeQL is supported out-of-box by github so should be the top priority. cppcheck is also a good option but is not supported out-of-box so can be a future addition.

Describe alternatives you've considered
Manual static code analysis is already a soft requirement for PRs. However, it would be better to gate PR completion by an automated check.

Additional context
None.

Describe the bug
In src/wpas/wpa_controller.c:wpa_controller_qrcode() the reply buffer doesn't have a null terminator set so when strtoul reads it, sometimes it reads past the reply_length. This causes ztpd to believe the id is something other than what wpa sent it, meaning the configurator will not be able to provision any enrollee.

To Reproduce
Steps to reproduce the behavior:

1. Whenever the code calls wpa_controller_qrcode() you have a chance to see this undefined behavior.
2. See error

Expected behavior
strtoul should read exactly reply_length bytes from the reply buffer.

Desktop (please complete the following information):

• OS: Azure Percept Device

Describe the bug
The ztpd daemon always returns a 0 exit code from its main process, regardless of whether the process exited cleanly or not. This is due to ztpd_run() having a void return type.

To Reproduce
Steps to reproduce the behavior:

1. ztpd -c /path/to/ztpd/config.json -d
2. kill -9 $(pidof -s ztpd)

Expected behavior
ztpd exits with a non-zero exit code.

Desktop (please complete the following information):

• OS: Azure Percept Device
• ztp v0.4.0.