Re: [Linuxptp-devel] [PATCH 0/1] msg: fix incorrect suffix detection for frames longer than messageLength

2020-10-28 Thread Matthew P. Grosvenor
Hi Richard, I think you’re missing the point here. You made two assertions: The NIC MAC should either strip the CRC, or should drop a packet with a bad CRC. It is completely useless for a NIC to forward the CRC to the host. I am saying that I disagree with you on both of those assertions. It

Re: [Linuxptp-devel] Machine Readable Output

2020-10-27 Thread Matthew P. Grosvenor
Thanks for this. I just ended up writing a log parser for the ptp4l output which did the job as well. The current output contains exactly the outputs that I wanted/needed. The reason for asking here was to see if there was more value that I could add by making this sort of thing available to

Re: [Linuxptp-devel] Machine Readable Output

2020-07-25 Thread Matthew P. Grosvenor
> The messages are standardized and use TLV format so writing your own > send/receive bits would not be too difficult. Plus, if you don't mind > GPL you can just simply fork and port pmc into whatever language you prefer. This is exactly what I’m trying to avoid: committing the cardinal sin of

Re: [Linuxptp-devel] Machine Readable Output

2020-07-21 Thread Matthew P. Grosvenor
Thanks, you’re right, the pmc tool might be the right place to do this, but it doesn’t seem to actually solve the problem? The output of the pmc tool is still unstructured text. So to feed it into a script I would still need to write an output parser of some sort and I would have to guess