昨日のRD-H1の続き。
うまく動くようになったのでメモ。

一般的なNTP知識。

タイムスタンプの形式
64bit長で、整数部32bit、小数部32bitの固定小数点数。
UTC 1900/1/1 00:00 が基準。

Reference Timestamp

local clockを更新した時間

Originate Timestamp (t1)

クライアントがサーバにリクエストを出した（クライアントの）時間

Receive Timestamp (t2)

サーバがクライアントからリクエストを受け取った（サーバの）時間

Transmit Timestamp (t3)

サーバがクライアントにリプライを出した（サーバの）時間

NTPのパケット上にはありませんが、t4はクライアントがサーバからリプライを受け取った（クライアントの）時間です。

ラウンドトリップ遅延は、
(t4 - t1) - (t3 - t2)
です。つまり、（往復時間） - （サーバでの処理時間）です。
t1, t4 はクライアント時間で、t2,t3はサーバ時間である点に注意します。
(t2 - t1)はネットワーク上での遅延＋（サーバ時間-クライアント時間）です。
(t4 - t3)はネットワーク上での遅延＋（クライアント時間ｰサーバ時間）です。
ネットワーク上の遅延が上りと下りで同じであれば、(t2 - t1) + (t4 - t3)が（サーバ時間ｰクライアント時間）*2になります。
つまり、(t2 - t1 + t3 - t4)/2がクロックオフセットになります。

FreeBSDのNTPをいじる

FreeBSD上では、
64bitの時間は、struct l_fp;
で定義されています。
１秒は、小数部の値で、
#define FP_SECOND (0x10000)
と定義されています。
l_fp rの時間をsecだけ進めるには、マクロを使って
L_ADDUF(r, FP_SECOND * sec)
でできます。

ntp_proto.cのfast_xmitがクライアントへのリプライを作っているところなので、そこを改変。
全クライアントに間違った時間を返すと厄介なので、IPアドレスで時間をずらすかどうかを判定。変な時間を返すときは、stratumは15で返すのがせめてもの礼儀かもしれない（というか、正確な時間を返さない時点でダメなんだけど）。

ちなみに、RD-H1は設定画面の時間合わせの項目の時刻サーバを選んだ時点で、NTPサーバに問い合わせにいきます。自動で問い合わせにくるのを待っているのは面倒なので、テストするときはこの仕様を使うと便利です。

最後に。同じようなことをしようとする人は、くれぐれも外部に偽サービスを提供してしまわないようにお気をつけください。

東芝のRD-H1にはNTPで時間を合わせる機能があります。
とっても便利なのですが、正確すぎて困ります。予定時刻の数秒前くらいから録画して欲しいときは、NTPを使わずに手動で時間を合わせなければいけません。

そこで、偽物のNTPサーバで偽物の情報を流してしまおう、という作戦。

暴挙です。

RD-H1の使うNTPサーバは、
ntp01.rd-style.com
なので、LAN内のDNSサーバで解決するようにしてLAN内のNTPサーバを割り当てます。

NTPサーバは、サーバ自体の時間がずれていると、それはそれで問題になるので、ntpdをいじって違う時間を返すようにします。

DNSは問題ないんだけど、ntpdはいまいち上手く動かない。あれ？
fast_xmitあたりだと思うんだけどな・・・