Параметры rsync по умолчанию для каждого удаленного хоста

Похоже, что вывод tcpdumpсодержит только запросы и вообще не содержит ответов. Если это то, что происходит на самом деле, то следует ожидать ошибки тайм-аута.

В строке server_argsвашей конфигурации TFTP для xinetd у вас есть -u tftp. Это указывает in.tftpdработать от имени пользователя tftp. В свете этого это сообщение, зарегистрированное in.tftpd, может быть важным :

Jan 15 13:13:21 tools in.tftpd[7955]: no user tftp: Success

Пишет "нет пользователя tftp". Существует ли учетная запись пользователя tftpв вашей системе?

Для понимания Successв конце сообщения журнала требуются некоторые знания программирования на C. Скорее всего, это происходит из-за минималистской функции обработки ошибок -, которая, вероятно, просто вызывает perror(), а затем выполняет всю необходимую очистку -перед выходом.

Функция perror()принимает сообщение от вызывающего объекта, а затем добавляет к нему стандартное сообщение об ошибке, соответствующее текущему значению переменной errno. Он предназначен для использования в ситуациях, когда предыдущий системный вызов не удался; пользовательское сообщение должно описывать, что делала программа в момент возникновения ошибки, а стандартное сообщение должно затем разъяснять тип возникшей проблемы.

Но если программист использовал свою функцию обработки ошибок -, чтобы сообщить об ошибке, которая была обнаружена другим способом, часть стандартного сообщения об ошибке будет читаться Success.

Я предполагаю, что процесс in.tftpdзапускается xinetd, готовится переключиться на пользователя tftpи обнаруживает, что такого пользователя не существует. Таким образом, процесс in.tftpdвыводит это сообщение журнала и умирает, ничего не отправив клиенту.

Краткое сообщение с вводящим в заблуждение «Успехом» в конце является примером старой концепции «если ваш единственный инструмент — молоток, вы склонны относиться ко всему как к гвоздям». В этом случае программист, вероятно, использовал свою единственную функцию обработки ошибок в ситуации, для которой ее формат вывода не совсем подходит.

Кроме того,эти запросы выглядят немного странно:

12:34:33.477401 IP 172.16.1.202.ah-esp-encap > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:35.481131 IP 172.16.1.202.acp-port > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:39.490793 IP 172.16.1.202.msync > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:45.477712 IP 172.16.1.202.gxs-data-port > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:53.441801 IP 172.16.1.202.vrtl-vmf-sa > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0

tsize 0указывает, что клиент ожидает передачи TFTP с общим размером файла 0 байт.

Известно ли вам, что спецификация UEFI PXE, существовавшая в UEFI версии 2.3 или около того, требует, чтобы DHCP-сервер сообщал PXE-клиенту размер файла, который он должен загрузить? Если вы используете DHCP-сервер ISC, требуемый параметр может быть указан как

option boot-size <size value>; 

<size value>должен представлять собой размер загрузочного файла в байтах, разделенный на 512 и округленный в большую сторону.