Подобные сообщения обозначают что SQL сервер не успел вовремя обработать запрос и DHCP клиент инициировал повторную отправку, потому информация о первичном запросе от клиента была удалена из очереди dhcpd как дубль. Через какое-то время SQL сервер всё же ответил на первый, уже затёртый запрос, но т.к. этот запрос был удалён из очереди - dhcpd не смог найти кому переслать этот ответ. Примерно так.
Вообще в последнее время задумываюсь о том что надо написать с нуля, без костылей и заплаток адекватный DHCP сервер изначально ориентированный на SQL.
ЗЫ Обновил патч на сайте. http://www.netpatch.ru/projects/dhcp2radiu...2.patch.tar.bz2 - убрал "лишнюю" функцию can_unicast_without_arp (out) в условии и устранил потенциальную уязвимость при обработке DHCP запросов.
Роман, прошу прощения, что сразу не ответил на свое же сообщение. Возможно эта ошибка возникает и в случае долгого ответа sql, в моем же случае проблема была в том, что я по незнанию оставил закоментаренным radius-cache-ttl, как в примере в статье, наивно полагая, что это где-то описано как дефолт, в итоге получил время ttl 0. Конечно при этом функция delete_old_xid удаляля все что было в кеше. Т.ч. моя проблема решена, dhcperf показал 32 запроса в секунду.
