Информация
Настройка
Новости
Контакты
Новинка
Распродажа
Оплата
Доставка
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • Changelogs
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    RouterOS
    Amazon Fire TV не получает DHCP-адрес после окончания срока аренды на роутере Mikrotik.

    Amazon Fire TV не получает DHCP-адрес после окончания срока аренды на роутере Mikrotik.

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Amazon Fire TV не получает DHCP-адрес после окончания срока аренды на роутере Mikrotik., RouterOS
     
    Harley2002
    Guest
    #1
    0
    25.01.2016 16:23:00
    Это единственный клиент, с которым у меня возникает проблема. На самом деле у меня два Fire TV, но проблема только с новой 4K версией. Симптомы: когда срок аренды IP-адреса истекает, клиент теряет связь с сетью, и мне приходится физически отключать и снова подключать сетевой кабель. После этого всё работает нормально до следующего истечения аренды через семь дней.
     
     
     
    momon
    Guest
    #2
    0
    17.05.2016 23:41:00
    Я очень рад, что наткнулся на эту проблему, потому что думал, что у меня что-то сломалось. Но проверив всё, я пришёл к выводу, что тут какой-то конфликт между сетевым адаптером Amazon 4K и тем, как на Mikrotik обновляется аренда IP. Именно это побудило меня поискать в гугле и найти этот пост. У меня такая же проблема, как у вас: к роутеру 750 GL подключено примерно 30 разных устройств (телефоны, точки доступа, телевизоры и т.д.). Единственное устройство с проблемами — это именно Amazon Fire TV (4K версия). У меня ещё есть Fire TV Stick и обычный Fire TV (не 4K, первое поколение), и у них такой проблемы нет. Проблема только с 4K версией. Я проверил всех клиентов — все стоят на DHCP, ни одно устройство не использует статический IP. Думаю, моё временное решение, как и ваше, — просто дать Amazon Fire TV статический IP или выставить время аренды на год (что, правда, не очень хорошая идея). Было бы здорово получить мнение от кого-то из Mikrotik и узнать, удастся ли кому-то ещё повторить эту проблему. Удачи!
     
     
     
    NathanA
    Guest
    #3
    0
    18.05.2016 07:01:00
    На прошлой неделе у меня сама возникла такая же проблема! У меня нет Fire TV, но один мой знакомый недавно купил его и попросил посоветовать роутер, так что я сказал ему взять 951Ui-2HnD для дома. По умолчанию время аренды (lease time) в новых версиях RouterOS очень короткое — 10 минут. И его Fire TV постоянно «терял» соединение с сетью ровно каждые 10 минут! Я посмотрел логи роутера и увидел, что Fire TV не пытается обновить аренду IP до истечения срока, а только через пару секунд после окончания. Я подумал, что, возможно, в прошивке Fire TV баг, из-за которого короткое время аренды ему не подходит, и увеличил время аренды до 8 часов. И что же? Fire TV теперь отключается от сети каждые 8 часов. В конце концов, я устал и просто назначил ему статический IP. Я искал в интернете, есть ли у других похожие проблемы с Fire TV и DHCP, но ничего не нашёл. Случайно наткнулся на эту тему на форуме MikroTik. Сначала не думал, что это может быть проблема MikroTik, ведь все остальные устройства в сети работают нормально, и у меня никогда не было проблем с DHCP-клиентами на MikroTik DHCP-сервере. Я всё ещё не уверен, что вина именно MikroTik, но если нет — странное совпадение, что эту тему обсуждают только здесь, и только пользователи MikroTik-роутеров. Мне кажется, это баг самого Fire TV... Насколько я знаю, DHCP-клиенты должны обновлять свою аренду на середине срока, если они всё ещё в сети и хотят сохранить IP. То есть при аренде в 10 минут Fire TV должен был обновлять каждые 5 минут, при 8 часах — каждые 4 часа. Но в обоих случаях Fire TV ждал до полного истечения аренды, чтобы её продлить, а это слишком поздно. Похоже, проблема возникает только при подключении по Ethernet. Когда мы пробовали по Wi-Fi — всё было нормально. — Нэйтан
     
     
     
    efaden
    Guest
    #4
    0
    18.05.2016 14:20:00
    Похожая проблема и у меня…
     
     
     
    takekazuomi
    Guest
    #5
    0
    31.05.2016 08:26:00
    У меня такая же проблема.
     
     
     
    luidoltp
    Guest
    #6
    0
    01.06.2016 11:45:00
    Привет! У меня тоже есть FireTV 4k, и я подробно изучил проблему. С помощью Wireshark я записал процесс обновления DHCP между роутером и FireTV и заметил странное поведение. Я выставил время аренды (lease-time) на 3 минуты, чтобы обновления происходили чаще и их было проще поймать. В захвате есть как первое присвоение (кабель был подключён), так и один процесс обновления.

    Захват FireTV:  
    FireTV отправляет широковещательный DHCP-Request примерно за 90 секунд до истечения аренды. Роутер Mikrotik отвечает DHCP-ACK, в котором указывается только оставшееся короткое время аренды. Эта процедура повторяется несколько раз, пока аренда всё-таки не истекает. После этого FireTV сбрасывает свой адрес и отправляет новый DHCP-discover. Ему назначается тот же адрес с арендой на 3 минуты. В этот момент FireTV теряет сетевое соединение примерно на 20 секунд. Также появляются странные ICMP-пакеты, которые, кажется, вызывают проблемы. Роутер не имеет настроенного фаервола, и с ноутбука его пингуется без проблем. Так что я не уверен, в чем дело с этими пакетами и связаны ли они с проблемой.

    Захват Windows 10:  
    В отличие от этого, ноутбук с Windows 10 за 90 секунд до окончания аренды отправляет широковещательный DHCP-Inform, получает от роутера DHCP-ACK, а затем отправляет unicast DHCP-Request прямо на Mikrotik. Роутер отвечает DHCP-ACK с новым временем аренды в 3 минуты.

    Я использовал hAP lite с RouterOS v6.35.2. FireTV и ноутбук с Windows 10 были подключены по кабелю к ether2. Ноутбук с Wireshark — к ether3. Зеркальный источник — ether2, зеркало — ether3. Конфигурация роутера приложена.

    К сожалению, у меня нет достаточных навыков, чтобы понять, кто ведёт себя неправильно — Mikrotik или FireTV, или это комбинация обеих сторон. Я пытался найти точный процесс "dhcp renew", но не нашёл подробностей, только то, что должен быть DHCP-Request, за которым следует DHCP-ACK. Может, кто-то взглянет и подскажет, что идёт не так? Очень бы хотелось разобраться в ошибке и иметь возможность сообщить о ней тем, кто сможет её исправить.

    Буду очень благодарен за любые комментарии!  
    С уважением, Lui

    Wireshark-captures_and_router-config.zip (2.49 KB)
     
     
     
    luidoltp
    Guest
    #7
    0
    01.06.2016 17:25:00
    Я только что проверил... Такое же поведение наблюдается на RouterOS v6.34.5 и v6.36rc21. С наилучшими пожеланиями, Lui
     
     
     
    pe1chl
    Guest
    #8
    0
    01.06.2016 20:34:00
    Эти ICMP-пакеты сами по себе не проблема, они указывают на проблему. Роутер отправляет DHCP ACK, а устройство отвечает, что порт, на который отправлено это сообщение, недоступен. Нужно заново сделать трассировку и подробно её развернуть для одного из обменов DHCP request/DHCP ack/ICMP, а также, возможно, для корректного обмена. Затем нужно посмотреть на несколько опционных битов и полей и выяснить, что отличается. Это может быть что-то простое, например, флаг «broadcast» с неправильным значением, либо устройство хочет получать ответ в виде широковещательного сообщения, а не направленного. Было бы полезно также сделать трассировку, когда устройство делает DHCP-запрос к другому роутеру, который обрабатывает ситуацию правильно.
     
     
     
    luidoltp
    Guest
    #9
    0
    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: https://tools.ietf.org/html/rfc2131  

    С уважением, Lui  

    Capture-details.zip (6.48 KB)
     
     
     
    pe1chl
    Guest
    #10
    0
    06.06.2016 14:02:00
    Думаю, это не выглядит так уж плохо… Конечно, время аренды на MikroTik очень короткое, но, похоже, ты сам так настроил для отладки. (То есть, можно было бы увеличить это время на DHCP-сервере, но тогда придётся дольше ждать, чтобы воспроизвести ту же проблему.) Можно попробовать вручную добавить эти две опции в DHCP-сервер MikroTik (задача немного трудозатратная, но проще, потому что у тебя есть пакет с ZyWall, где видно эти опции) и проверить, решит ли это проблему. Когда ты проводил этот тест, видел ли ты по-прежнему связанное ICMP-сообщение и было ли оно на ZyWall тоже? Потому что если роутер так отказывает в ACK, конечно, он его не обработает, и игра с полями опций вряд ли поможет.
     
     
     
    luidoltp
    Guest
    #11
    0
    06.06.2016 14:34:00
    Привет, pe1chl, спасибо за быстрый ответ. На самом деле я установил время аренды всего на 3 минуты для отладки. Под «коротким временем аренды» от MikroTik я имел в виду, что ACK отправляется с оставшимся временем аренды, а не с полными 3 минутами. Поэтому на клиенте (FireTV) аренда заканчивается, потому что она никогда не продлевается. Если я увеличиваю время аренды, проблема всё равно остается… просто возникает реже. Я попробую это проверить и сообщу о результатах. ICMP-сообщение тоже появлялось на ZyWall. Похоже, что пакеты на это никак не влияют. С наилучшими пожеланиями, Питер
     
     
     
    pe1chl
    Guest
    #12
    0
    06.06.2016 14:39:00
    Да, возможно, DHCP-клиент слушает на raw-сокете и видит ответ, в то время как межсетевой экран блокирует этот ответ в обычном пути INPUT. Не очень дружелюбно, но это не должно нарушать работу. В таком случае можно попробовать поиграться с этими двумя опциями — может сработать. Однако то, что роутер не отвечает новым полным арендным сроком, когда его запрашивают заново после половины периода аренды, тоже немного странно. Возможно, это баг, но тогда стоит попытаться выявить условия, при которых это происходит, потому что DHCP-сервер обычно нормально работает с ПК и другими клиентами (по моему опыту, по крайней мере).
     
     
     
    luidoltp
    Guest
    #13
    0
    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] https://tools.ietf.org/html/rfc2131#section-4.4.5
     
     
     
    pe1chl
    Guest
    #14
    0
    07.06.2016 09:27:00
    Всегда здорово чему-то научиться! Программное обеспечение на этом устройстве обновлено? Можно попробовать отправить баг-репорт, но, скорее всего, это будет очень сложно…
     
     
     
    luidoltp
    Guest
    #15
    0
    07.06.2016 18:08:00
    Привет! Я могу с уверенностью подтвердить это. Спасибо, что помогали мне охотиться за этим багом. Без ваших подсказок я бы не продвинулся так далеко! Очень признателен!!

    Да, версия ПО — «Fire OS 5.2.1.0 (550144920)», и в меню было указано, что обновлений нет. Служба поддержки Amazon была довольно отзывчивой. Мне сказали, что они могут переслать мой отчет о баге разработчикам, если я отправлю его по электронной почте (что я и сделал).

    Не ожидаю, что Amazon скоро исправит этот баг… но буду рад ошибиться. Если получу от них какой-то ответ, обязательно обновлю эту ветку.

    С наилучшими пожеланиями, Lui
     
     
     
    matterney
    Guest
    #16
    0
    17.07.2016 22:32:00
    У меня такая же проблема. Использую Router OS 6.35.4 на RB 450G. Подключён жестко Amazon Fire TV — последняя версия. DHCP сбрасывается каждые 10 минут. Пришлось назначить статический IP, чтобы стабилизировать подключение. Есть ли какие-то новости по решению от Amazon или MikroTik? Спасибо!
     
     
     
    luidoltp
    Guest
    #17
    0
    18.07.2016 09:37:00
    Неделю назад я спросил службу поддержки Amazon, есть ли у них новая информация по этой проблеме. Они ответили, что могут только передать баг команде разработчиков, но доступа к информации о текущем статусе у них нет. Было бы интересно узнать, как с обновлением DHCP справляется другое профессиональное оборудование (например, Cisco, Juniper и т.д.) на Fire TV. К сожалению, у меня нет таких устройств дома, чтобы проверить это самому. Было бы здорово, если кто-то, у кого есть такое оборудование, смог бы провести этот тест. Меня всё ещё удивляет, что в интернете так мало сообщений о проблеме с DHCP на Fire TV. Похоже, что у большинства пользователей её нет (или они просто не знают об этом); вероятно, большинство домашних роутеров обрабатывают DHCP-запросы иначе и не так строго, как MikroTik. С наилучшими пожеланиями, Lui
     
     
     
    troykelly
    Guest
    #18
    0
    30.07.2016 23:48:00
    У меня тоже такая проблема — я тоже обращался в Amazon, а они сказали, что ни один пользователь не жаловался на это, и раз жалоб нет, они даже не начали работать над решением. Всем, у кого это происходит, пожалуйста, попросите у Amazon какое-нибудь официальное подтверждение (номер заявки или что-то в этом роде). Похоже, для них это пока «нам всё равно».
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры