> > > > + unsigned short suffix_id = ntohs(*(unsigned short*)(ptr + > > > > + (cnt > > > > + - 2))); > > > > > > This seems to be parsing the frame from the end. Couldn't that > > > randomly match a non-PRP frame, even if you consider the length > > > check > > below? > > > > > > To me it would make more sense to start after the PTP message > > > according to the messageLength field. > > > > > > > This is a good point. > > PRP supports also pure ethernet frames but in case of PTP over > > ethernet we actually have the messageLength. > > I will need to see if I can get it in a good way already in the raw > > receive (seems like only the ethernet header is currently parsed) > > > > If I understand correctly, the message length is validated in msg.c:429. > How would you feel about a solution where I move the PRP trailer validation > to be just before that check? > > Do you prefer the acceptance of PRP trailer to be active all the time or is it > better if I add another config parameter? > > Side note 1: > The PRP trailer should normally be removed by the PRP implementation, so if > a PRP hw implementation is used the trailer won't be there. > In short, PRP uses dual lines to send the same information, LAN A and LAN B, > the first arriving packet is handled and the duplicate from the other > interface > is dropped. > PTP over PRP can't mix the information from the 2 lines (path delay might be > different) so we need to run a PTP instance on each interface instead of on > the combined prp0 created by the kernel. > Hence the PRP trailer will be still there in PTP packages received directly > from > the interface, the PRP stack hasn't had the chance to remove it (which it > would if traffic is read from prp0) > > Side note 2: > PRP has a requirement for minimum packet length to be 70 bytes so short > messages like e.g. Sync Message (44) would get 2 bytes padding before the 6 > bytes PRP trailer. The LSDU size inside the PRP trailer would be 52 (44 + 2 + > 6). >
The 2nd side note is causing a problem when using the message length for validation. In raw receive the information about if VLAN is being used or not, is available. This information is needed in order to know if padding is expected or not in order to meet the minimum 70bytes frame requirement. I think the cleanest solution is to handle the PRP trailer stripping in raw receive. There the information about VLAN is available and it makes the PRP trailer stripping (which normally should be done by PRP stack) invisible to the rest of the PTP implementation. Do you prefer to keep the raw receive clean of PTP message struct or should I make an attempt to parse a PTP message there and use the messageLength field? -- Magnus Armholt _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
