ptpd v.1.1.0 offset filtering bug

[Fran Horan]

I think I see a bug in ptpd v1.1.0 related to the -O offset filtering option.

I doubt v1.1.0 is being supported, but maybe this will help end users who download and want to fix their copy.

The -O runtime option activates an offset filter on the slave side. The option and its nearest neighbor read:

-O do not reset the clock if offset is more than NUMBER nanoseconds
-M do not accept delay values of more than NUMBER nanoseconds

The issue is that the code/implementation for the -O option does not account for offsets in both positive and negative directions. Look in src/dep/serv.c and you will find the following on line #153 where the problem is. I believe line 153 should be using the absolute value of offset:

138 void
139 updateClock(RunTimeOpts * rtOpts, PtpClock * ptpClock)
140 {
141     Integer32 adj;
142     TimeInternal timeTmp;
143
144     DBGV("updateClock\n");
145
146     if (rtOpts->maxReset) { /* If maxReset is 0 then it's OFF */
147         if (ptpClock->offset_from_master.seconds) {
148             INFO("updateClock aborted, offset greater than 1"
149                  " second.");
150             goto display;
151         }
152
153         if (ptpClock->offset_from_master.nanoseconds >
154             rtOpts->maxReset) {
155             INFO("updateClock aborted, offset %d greater than "
156                  "administratively set maximum %d\n",
157                  ptpClock->offset_from_master.nanoseconds,
158                  rtOpts->maxReset);
159             goto display;
160         }
161     }

A side issue is the wording for -O help printout is not really right. When looking at the code and watching it run, it is behaving more like the -M option, it is not accepting a value if it exceeds the threshold.

Thanks,

Fran Horan
JHU/APL

[Fran Horan]

Entered a bug report on this.

https://sourceforge.net/p/ptpd/bugs/73/