Это единственный клиент, с которым у меня возникает проблема. На самом деле у меня два Fire TV, но проблема только с новой 4K версией. Симптомы: когда срок аренды IP-адреса истекает, клиент теряет связь с сетью, и мне приходится физически отключать и снова подключать сетевой кабель. После этого всё работает нормально до следующего истечения аренды через семь дней.
Amazon Fire TV не получает DHCP-адрес после окончания срока аренды на роутере Mikrotik.
Amazon Fire TV не получает DHCP-адрес после окончания срока аренды на роутере Mikrotik., RouterOS
25.01.2016 16:23:00
|
|
|
|
18.05.2016 14:20:00
Похожая проблема и у меня…
|
|
|
|
31.05.2016 08:26:00
У меня такая же проблема.
|
|
|
|
01.06.2016 17:25:00
Я только что проверил... Такое же поведение наблюдается на RouterOS v6.34.5 и v6.36rc21. С наилучшими пожеланиями, Lui
|
|
|
|
06.06.2016 13:08:00
Привет, извиняюсь, что так долго не мог разобраться с этой проблемой. Спасибо, pe1chl, за твой ответ. Я попробовал то, что ты предложил, и зафиксировал процесс обновления, когда FireTV подключён к другому роутеру. Я использовал ZyWall USG 100 (с ним FireTV работает нормально). DHCPREQUEST, отправленный с FireTV, идентичен (за исключением контрольных сумм и IP-адресов). Но DHCPACK, который отвечает роутер, отличается в некоторых местах. Слева показана настройка с MikroTik, справа — с ZyWall:
Первое отличие в том, что поле «seconds elapsed» (secs) в dhcp-пакете у MikroTik установлено в 0 (в то время как ZyWall ставит 90). В RFC2131 на странице 9 указано, что это поле «Заполняется клиентом — количество секунд, прошедших с начала получения или обновления адреса». Это относится к DHCPREQUEST. На странице 27 объясняется, что поле secs может быть 0 в DHCPACK, но это относится к первичному DHCPDISCOVER-сообщению. Так что, подумал я, это отличие не влияет на нашу проблему. Слева настройка MikroTik, справа — ZyWall: Второе отличие: «IP Address Lease Time» (опция 51) у MikroTik приходит с коротким оставшимся временем аренды. ZyWall сбрасывает это значение на первоначальные 3 минуты. Третье отличие: «Renewal Time Value» (опция 58) и «Rebinding Time Value» (опция 59) полностью отсутствуют у MikroTik. FireTV запрашивал эти опции. В ZIP-файле, который я приложил, содержатся Wireshark pcapng-файлы и два текстовых файла, которые видны на скриншотах. Текстовые файлы включают два пакета, участвующих в процессе обновления, со всеми деталями (один DHCPREQUEST и один DHCPACK для каждой настройки). Может кто-то подтвердить, что DHCPREQUEST с FireTV корректен? Мне интересно, правильна ли короткая аренда, возвращаемая MikroTik. Должен ли ACK от MikroTik выглядеть именно так? RFC2131: С уважением, Lui Capture-details.zip (6.48 KB) |
|
|
|
06.06.2016 22:29:00
Привет, я изменил dhcp-сервер так, чтобы он также отправлял эти две опции. Для этого я использовал следующую конфигурацию dhcp-сервера.
/ip dhcp-server add address-pool=pool1 disabled=no interface=ether2 lease-time=3m name=server1 /ip dhcp-server option add code=58 name=RenewalTimeValue value="'90'" add code=59 name=RebindingTimeValue value="'157'" /ip dhcp-server network add address=10.0.0.0/24 dhcp-option=RenewalTimeValue,RebindingTimeValue dns-server=10.0.0.1 gateway=10.0.0.1 Я проверил через Wireshark, что опции действительно отправляются. К сожалению, это не помогло. Время аренды всё равно не обновляется корректно. Я проверял на трёх других устройствах как dhcp-клиентах (ноутбук с Windows 10, Raspberry Pi и другой роутер MikroTik). Главное отличие в том, что все эти три устройства отправляют unicast на dhcp-сервер для обновления аренды. FireTV же посылает broadcast. В разделе 4.4.5 RFC2131 [1] объясняется процесс повторного получения и истечения аренды. Если я правильно понял, у клиента есть два состояния: RENEWING и REBINDING. Клиент сначала должен войти в состояние RENEWING и использовать unicast-пакет для запроса продления аренды. Если от dhcp-сервера нет ответа, клиент переходит в состояние REBINDING и отправляет broadcast. Я заблокировал все unicast-пакеты к dhcp-серверу, чтобы заставить свой ноутбук войти в состояние REBINDING. Ноутбук (как и ожидалось) отправил broadcast и получил корректный ответ с полным временем аренды. Благодаря этой записи я наконец смог точно определить проблему! FireTV не устанавливает клиентский IP-адрес в своё текущие значение, а использует 0.0.0.0. Согласно RFC, поле «Client IP address» (ciaddr) должно быть заполнено в DHCPREQUEST (независимо от состояния RENEWING или REBINDING, см. последнюю часть раздела 4.3.2 RFC2131). Похоже, FireTV делает две ошибки: - Пропускает состояние RENEWING и сразу переходит в REBINDING (с использованием broadcast) - DHCPREQUEST отправляется без правильного ciaddr (возможно, это главная причина) Странно, что RouterOS не отвечает с полным временем аренды. С уважением, Lui [1] |
|
|
|
07.06.2016 09:27:00
Всегда здорово чему-то научиться! Программное обеспечение на этом устройстве обновлено? Можно попробовать отправить баг-репорт, но, скорее всего, это будет очень сложно…
|
|
|
|
Читают тему