On Mon, Jan 10, 2022 at 08:34:04AM +0000, Cindy Han via Linuxptp-devel wrote:
> Hi,
>
> We met some issues during ptp4l test, and we believe these issues shall be
> fixed by ptp4l.
>
> 1. According the standard, the ptp4l shall not check the suffix for
> Delay_req since it is event message.
Can you please point to the exact location in the standard where it
says event messages cannot have a TLV? That would be a major problem,
e.g. it would prevent an authentication mechanism to protect (all) PTP
messages with a MAC TLV.
> static uint8_t *msg_suffix(struct ptp_message *m)
> {
> switch (msg_type(m)) {
> case SYNC:
> return NULL;
> case DELAY_REQ:
> return m->delay_req.suffix; <- should
> return NULL
I suspect that would break the NetSync Monitor support.
> If these padding added by the HW are less than 4 bytes, there is no complain
> from ptp4l. But once they are equal or bigger than 4 bytes, the current logic
> in ptp4l treat them as bad messages. So the ptp4l shall calculate the suffix
> length based on the message length, not the length from the transport.
This was proposed several times before. You can search the archives
and see if you have a new argument that could be made.
> 1. The bad message checker does not cover all bad scenarios which may
> cause ptp4l crashes since the attribute of message length in PTP message
> could be manipulated with huge number, however the cnt length and pdu length
> are correct.
Are you saying the current code crashes on some received messages?
--
Miroslav Lichvar
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
