Согласно книге Рафаэлло Джованьоли о восстании Спартака, понтифик и будущий

диктатор Гай Юлий Цезарь на вопрос гладиатора: "кто ты - друг наш или враг?" ответил: " хотел бы быть другом и уж во всяком случае никогда не буду врагом".

При разработке ретранслятора DHCP сообщений в режиме прокси мы руководствовались похожими мотивами по отношению к основному DHCP серверу. Перенаправляя DHCP сообщения от клиентов согласно жёстким таймерам Renewal и Rebinding, защищая сервер от излишнего количества трафика с помощью control-plane полисинга, блокируя атаки подозрительных пользователей и в целом взяв на себя часть функций DHCP сервера, мы заслужили почетное и уважаемое сетевое звание - Trusted Neighbor! И путь этот оказался весьма не простым.

Работа протокола DHCP, предшественниками которого кстати были протоколы RARP и BOOTP (ключевое слово bootp очень удобно в фильтрах wireshark) , кажется привычной и понятной:
выдал абоненту

- его IP адрес
- время аренды IP адреса
- маску подсети
- IP адрес шлюза по умолчанию
- IP адрес DNS сервера
- ну пускай IP адрес NTP сервера для синхронизации времени

И всё! Этого достаточно абонентскому устройству для работы в IPv4 сети. Но широкий спектр возможностей протокола DHCP, непредсказуемое поведение как абонентских маршрутизаторов, так и устройств провайдера, усложняют эту задачу и ставят под удар наши дружеские отношения с DHCP сервером. Одних только опций в сообщениях DHCP насчитывается порядка 255 штук, типов таких сообщений 18, а каждый тип может иметь ещё и подтип в зависимости от ситуации на сети. Например многим известное сообщение типа Request от абонента может иметь 4 подтипа

* Request в ответ на Offer от сервера (Selecting)
* Request при рестарте домашнего устройства или падения/восстановления линков (Init-Reboot)
* Request при продлении аренды IP адреса (Renew)
* Request В случае пропадания Request Renew на предыдущем шаге (Rebinding)

Множество сетевых кейсов и сценариев при работе протокола DHCP на этом не заканчиваются. Большинство опций имеют целый список подопций. Так популярная у провайдеров опция 82 (DHCP Relay option), предназначенная для обеспечения функций безопасности и выделения IP адресов на основе переданной информации о абонентах и устройствах на сети, может содержать подопции Agent Circuit ID и Agent Remote ID. Если первая подопция содержит информацию о том, с какого порта/VLAN пришел запрос на DHCP-ретранслятор (здесь может быть MAC адрес абонента и многое другое), то вторая подопция содержит идентификатор или информацию о самом DHCP-ретрансляторе (DHCP ретрансляторов на пути следования пакетов может быть несколько).

Недавно мы столкнулись с Vendor Specific подопцией с номером 9 в опции 82, отправляло ее оборудование OLT в GPON инфраструктуре. В ней сообщалось имя и код вендора этого OLT. Мы к таким пакетам были не готовы и дропали их, подорвав тем самым доверие DHCP сервера. Убедились еще раз в множестве нюансов при работе с протоколом DHCP.

Поклявшись молниями Юпитера, мы поддержали в нашей ОС перенаправление DHCP пакета с Vendor-Specific подопцией в опции 82 и в очередной раз доказали свои дружеские намерения DHCP серверу. А вот реальные немерения Гай Юлия Цезара пускай останутся на его совести.

как будто написано специально с таким количеством воды, чтобы читать это никому не захотелось

Да, это была попытка вести небольшой дневник разработчиков Но видимо идея потухла, там особо активности нет уже с апреля 2022 года Вообще способ changelog для оборудования странный: его можно получить только через приватный канал, а в оформлении вставляется ссылка на фотографию из disk.yandex.ru, known issues качует от релиза к релизу с одним и тем же списком - такое чувство что просто надо заполнить это поле, фиксить не торопятся Сама promo на tilda https://ecorouter.ru/ Да и сам канал https://t.me/+gLGq0Mdl-EU0MWM6