A 16-byte SALT with a leading zero would be sent as only a 15-byte number. The chance of this occuring is 1 in 256, which is small but still significant. Solution is to specify required size of MPI output in loadTLV. This forces mbedtls_mpi_write_binary() to pad with leading zeros.
Also eliminated unused code (TLV pack_old).
HomeSpan defaults to running the HAP Server on port 80 (the standard HTTP port). This method allows the user to over-ride the default and have HomeSpan run the HAP Server on any other port.
ALSO: In updating this portion of the code, identified an additional parameter to the ESP32 version of WiFiServer that allows one to specify the number of simultaneous Server connections. The ESP32 default is 4, which suggests that the ESP32 was internally juggling connections that HomeSpan was keeping open (since the HomeSpan default is 8 connections).
This WiFiServer call has been updated to now specify both the port number AND the number of maximum simultaneous connections (to match whatever has been set by HomeSpan). This may or may not result in improving performance when more than 4 clients are connected.
Convention is that every *.cpp references, in this order:
1) Any required core librries
2) Its own *.h (i.e. Foo.cpp -> Foo.h)
3) All other *.h files needed by the cpp, UNLESS those *.h files are already in its own *.h file. Must include all *.h files that are not in its own *.h file even if it is others that are referenced.
And updated other SRP routines to complete implementation of use of stored verification code instead of live setup code.
Next up: Add method to change setup code in serial interface and implement similar code after network configuration routines.
This generates an SRP verification code from a setupCode and randomly-generated salt. Function creates the salt internally and returns both the resulting verification code and salt that was used. These are stored in NVS permanently.
Next Step: create SRP6A:loadVerifycode()
Gregg