См. Приложение A, начиная со страницы 50 https://www.ietf.org/rfc/rfc1305.pdf, для описания формата пакета NTP.Предполагается, что эти последние 8 байтов содержат метку времени ответа сервера - именно поэтому вы добавляете метку времени в эти байты при создании минимального пакета ответа.
Однако, исходя из того факта, что этот клиент поставилзначение в этих последних 8 байтах, похоже, что он хочет использовать механизм, описанный в разделе 5 протокола SNTP (Simple NTP), для https://www.ietf.org/rfc/rfc2030.txt SNTP использует тот же формат пакета, что и NTP, но использует поля в несколькодругой путь.В SNTP значение, которое клиент помещает в байты с 40 по 47, представляет собой текущее представление клиента о времени.(В этом случае это справедливо, AFAICT, эта временная метка где-то около 1951 года.)
Если это то, что пытается сделать этот клиент, то он хочет, чтобы сервер скопировал эти 8 байтов в байты 24-31(поле Originate Timestamp), а затем запишите текущее время сервера в байты 32-39 (метка времени приема) и в байты 40-47 (метка времени передачи) и отправьте его в качестве ответа.Конечно, также продолжайте изменять первый байт на 0x1C в ответе, чтобы указать, что этот пакет исходит от сервера.Вам также следует установить значение Stratum в байте 1 равным вероятному ненулевому значению, например, 3 или 4.
Учитывая, что часы клиента слишком долго выключены, это может занять несколько раундов запроса /ответ на это, чтобы войти в синхронизацию.Поэтому не ожидайте, что его часы сразу же перейдут в соответствие с часами сервера.(Возможно, это так, но я бы на это не рассчитывал.)
Не думаю, что вам нужно усложнять свою логику, особенно обращаясь с этим клиентом.Вероятно, вы можете применить точно такую же логику к пакетам от клиентов, которые помещают нули в последние 8 байтов.Это просто означает, что вы будете копировать нули в поле Originate Timestamp при построении ответов для этих клиентов.