?

Log in

No account? Create an account

Изменяю своим привычкам


Previous Entry Share Next Entry
TFTP32 не работает с DHCP-Relay-агентом
eucariot
Несколько дней убил на то, чтобы разобраться в этой ситуации. Задача элементарна, как два влана прокинуть: настроить на коммутаторе 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) своё понимание о работе этого протокола, и мой ПК должен получать мусорную рассылку от кого-то неизвестного.

  • 1
>Это ARP-ответ.
странно, но замечал это не только от девайсов фирмы HTC. еще какие то недокоммуникаторы от других контор были замечены в подобных недокументированных рассылках

Вообще, это Gratious ARP - чтобы оповестить всех сети о новом MAC-адресе, например. Но это всё не про коммуникаторы должно быть.

  • 1