eucariot (eucariot) wrote,
eucariot
eucariot

Category:

TFTP32 не работает с DHCP-Relay-агентом

Несколько дней убил на то, чтобы разобраться в этой ситуации. Задача элементарна, как два влана прокинуть: настроить на коммутаторе DHCP-relay, чтобы DHCP-запросы от клиентов он перекидывал на определённый адрес.
Схема подключения:



В качестве DHCP-сервера выступала программка TFTP32 - это такой микрокомбайн, который заключает в себе TFTP Client/Server, DNS, DHCP, SNTP и ещё пару других серверов.
При прямом подключении всё прекрасно.
Широковещательный DHCP-Discovery от клиента приходит на сервер.
DHCP-Offer возвращается от сервера клиенту.
Клиент отсылает DHCP-Request
И сервер возвращает DHCP-ACK с IP-адресом.

То есть как простой DHCP-сервер она точно работает.

Для того, чтобы на настроить коммутатор Huawei s5300 в качестве DHCP-Relay агента нужно 3 команды:
[Quidway] dhcp enable
[Quidway] interface vlanif 100
[Quidway-Vlanif100] ip address 192.168.2.1 24
[Quidway-Vlanif100] dhcp select relay
[Quidway-Vlanif100] dhcp relay server-ip 192.168.1.2

Несколько дней, не преувеличивая, я пытался найти причину.
Тут ситуация такая: DHCP-Discovery уходит от клиента к серверу. DHCP-Relay в дебаге рапортует о том, что перенаправил запрос, куда положено. DHCP-Discovery действительно доходит до сервера:



Сервер посылает ответ:



Но этот ответ не доходит до клиента. То есть он только и делает, что шлёт постоянно Discovery, а Offer не получает.
В дебаге на s53 вижу, значит, такой мессадж на китайском английском:

[RELAY ERROR]:[DHCPR_DealReply] relay recive reply packet,the dest port is 68,dorp.

То есть реле-агент, какбе намекаэ, что хер он пропусти сегмент на 68-й порт. И его можно понять. Обратите внимание на порты источника и назначения в DHCP-Discovery. От реле-агента они уходят с 67-го порта.
Но TFTP32 почему-то считает, что порт назначения должен быть 68, то есть словно бы и нет никакого DHCP-реле.
Позже выяснилось, что действительно есть такая проблема: http://reboot.pro/11325/M.
Тут, правда, речь о версии 3.35. Но в 4-й ничего не поменялось.
Как только я настроил другой DHCP-сервер, всё заработало.
Найти документацию или RFC, где были бы описаны порты для работы DHCP-реле не удалось, поэтому, полагаясь на практический опыт, могу сказать, что клиент ожидает ответ на 68-й UDP-порт, а отправляет на 67, а DHCP-реле-агент, отправляя так же на 67, ожидает ответ от сервера тоже на 67 порт.
Вот такие чудеса, которые помогают разобраться в том, как работают протоколы.

Вот так бывает сидишь и не понимаешь: ну нафига мне знать размер поля type в Ethernet-заголовке и какое значение он будет иметь, если внутри IP-пакет? Пока не столкнёшься с какой-нибудь кривой реализацией протокола.
Кстати о кривых реализациях, вчера снимал дамп со своего беспроводного интерфейса и увидел следующую картину:



Не замечаете ничего странного?

Это ARP-ответ. Некое устройство с MAС-адресом htc_a3:6e:0f отсылает сообщение ARP с ответом, что он владелец IP-адреса: 192.168.0.104. Но как оно это делает? Широковещательно: в качестве получателя стоит ff:ff:ff:ff:ff:ff. Всем известно, что ARP-ответ должен быть юникастовым, то есть только на тот MAC-адрес, который и спрашивал, но, очевидно, у кого-то (наверно, HTC) своё понимание о работе этого протокола, и мой ПК должен получать мусорную рассылку от кого-то неизвестного.
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 2 comments