On Mon, Sep 23, 2019 at 12:36:57PM +0000, Christian Leeb wrote: > If I look at ptp4l code there are several locations where delay > requests are flushed, maybe after sending the request? If, after > flushing, a peer delay response is received, obviously I get the > "rogue peer delay response".
Right. The peer delay request is asynchronous, and a request could very well be pending at the time of the flush. > Under these circumstances I wonder if the transition to FAULLY state > is the right reaction. Why not just print the message but continue > with the same state? The proper fix is, instead of flushing, to mark the request as stale and then ignore the response. BTW, when reviewing the code, I noticed another problem with the peer delay request mechanism. After a clock jump, the port code flushes the old peer delay requests in order to avoid a bogus delay measurement. This flush should be performed on all p2p ports, not just the one that is slaved to the remote GM. Thanks, Richard _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
