Details
Description
A response to a ForwardOpen request has an incorrect size due to bug in eip_dtls_encap module. All of this seems to be caused by an inconsistency between CT20 and the spec vol.8:
All explicit messages must have the CPF 0x8003 format. The length member of this CPF is expected to address the only the UnconnectedMessage size. But in practice CT20 is expecting 10 bytes more in the length member(CompareTCP FwdOpen response) which seems to be the 3 members before UnconnectedMessage.
As an instance, a response to a FwdOpen request, is expected to have a same CPF.Length comparing TCP UCMM and DTLS UCMM but the DTLS is expected to clame 10 more bytes.
The actual bug is in the part that calculates the msg length to pass it to mbedTls for encryption but it doesn't take the 10 extra bytes into account.
- Fix the calculation of the msg size with taking the extra 10 bytes into account
more possible actions
- Investigate this behavior. (Also wire shark seems to behave same as CT20!)
- Communicate with ODVA and ask for a clarification.