Re: [Linuxptp-devel] [PATCH 1/1 v3] Strip PRP trailer

[Magnus Armholt via Linuxptp-devel]

> > Is it necessary to return the padding length here? If I understand it
> > correctly it's not specific to PRP. It's just the original Ethernet
> > minimum length of 64 plus 6 bytes for the trailer. If you remove the
> > padding_len variable, the function can be simplified a bit.
> >
> In my testing I haven't noticed any issues if I only remove the actual PRP
> trailer (and not padding), but it might because the padding is 00 bytes.
> 
> For example, a PTP SYNC message is 44bytes long, with normal eth header
> (no vlan) being 14bytes it ends up being padded with 6 bytes (followed by
> PRP trailer).
> If I only remove the PRP trailer (6 bytes) but leave the padding length in 
> `cnt`,
> then if I follow the code correctly the message should end up in msg.c:425
> and still have 6 (padding)bytes to process.
> To my understand it should try to parse TLV, and then return a suffix_len of 4
> (successfully taken 1 TLV and failed to take the 2nd) which should fail the
> check on msg.c:429.
> This is just from reading the code, might be that I am missing something.
> 
A packet capture shows that the SYNC message is actually only padded by 2 bytes 
(I forgot the FCS at end of frame)
so that will leave the remaining size (of the padding) to be parsed on 
msg.c:425 to be smaller than the TLV size (4)
so no TLV will be parsed, but the code should still fail the check on 
msg.c:429. 
I am obviously missing something still, because I don't see any issues(no bad 
message indicated, works fine) with the SYNC message, even if I don't remove 
padding length from `cnt`.

- Magnus Armholt


_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel