originateTimestamp equals 0 in returned packet
- Dominant language
- JavaScript
- Stars
- 28
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Description
Running the slightly modified example
```js
const ntp = require('..');
ntp(function(err, response){
if(err) return console.error(err);
console.log(response);
});
```
`originateTimestamp === 0` is returned which renders roundtrip delay `d` and system clock offset `t` unusable.
```js
Packet {
leapIndicator: 0,
version: 4,
mode: 4,
stratum: 2,
pollInterval: 6,
precision: 233,
referenceIdentifier: ,
referenceTimestamp: 1577013057260.7312,
originateTimestamp: 0,
receiveTimestamp: 1577013390216.6448,
transmitTimestamp: 1577013390216.6702,
rootDelay: ,
rootDispersion: ,
destinationTimestamp: 1577013390262,
time: 2019-12-22T11:16:30.216Z,
d: 1577013390261.9746,
t: 788506695085.6575
}
```
According to https://tools.ietf.org/html/rfc2030#section-6
> In unicast and anycast modes, the Receive Timestamp and Transmit Timestamp
> fields are set to the time of day when the message is sent and the
> Originate Timestamp field is copied unchanged from the Transmit
> Timestamp field of the request. It is important that this field be
> copied intact, as a NTP client uses it to avoid replays. In multicast
> mode, the Originate Timestamp and Receive Timestamp fields are set to
> 0 and the Transmit Timestamp field is set to the time of day when the
> message is sent.
I suppose that client and server operate in unicast/ anycast mode. If this is the case I would like to change:
```diff
--- a/index.js
+++ b/index.js
@@ -63,7 +63,7 @@ NTP.prototype.time = function (callback) {
NTP.createPacket = function () {
const packet = new Packet();
packet.mode = Packet.MODES.CLIENT;
- packet.originateTimestamp = Date.now();
+ packet.transmitTimestamp = Date.now();
return packet.toBuffer();
};
```
Contributor guide
Research direction
Start in index.js at NTP.createPacket and reproduce the issue with the example shown in the report. Compare the constructed packet with the RFC 2030 behavior cited, then verify that the returned timestamps make the roundtrip delay and system clock offset usable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 45/100