Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • 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
    hAP ac2 перестает отвечать

    hAP ac2 перестает отвечать

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    hAP ac2 перестает отвечать, RouterOS
     
    netflow
    Guest
    #1
    0
    14.02.2020 21:38:00
    Получил hAP ac2 меньше двух недель назад. Он уже трижды завис, становится полностью неотзывчивым. В такие моменты даже watchdog не срабатывает. Единственный выход — это отключить питание. Кто-то испытывал такую же проблему? Есть ли возможность мониторить, что происходит, и, надеюсь, найти причину (сегфолт или что-то другое)? У кого-то был успех с использованием последовательной консоли с Raspberry Pi Zero, подключенным к USB-порту? В данный момент работает версия 6.46.3 с соответствующей прошивкой на заводских 716 МГц.
     
     
     
    netflow
    Guest
    #2
    0
    27.03.2020 21:17:00
    Мне нужно снова поднять этот вопрос. Я получил новый hAP ac2 после замены первого по гарантии из-за той же самой проблемы. К сожалению, проблема по-прежнему возникает с новым устройством. Следующая конфигурация работает некоторое время, но затем внезапно зависает навсегда. Судя по всему, это может быть ошибка сегментации в драйвере/ядре, так как watchdog не успевает сработать. Я могу создать условие за считанные секунды, если подключусь к Wi-Fi на 5 ГГц и запущу тест скорости с помощью телефона. Буду признателен за помощь с подключением через последовательный интерфейс, чтобы понять, что вызывает сбой драйвера/ядра. Также прокомментируйте мою конфигурацию ниже. Я не могу опубликовать всю конфигурацию, но я обрезал наиболее значимые части: # model = RBD52G-5HacD2HnD
    /interface ethernet
    set [ find default-name=ether1 ] l2mtu=9214 mtu=9210
    set [ find default-name=ether2 ] l2mtu=9214 mtu=9214
    set [ find default-name=ether3 ] l2mtu=9214 mtu=9214
    set [ find default-name=ether4 ] l2mtu=9214 mtu=9214
    set [ find default-name=ether5 ] l2mtu=9214 mtu=9214
    /interface ethernet switch port
    set 0 default-vlan-id=2 vlan-header=add-if-missing vlan-mode=secure
    set 1 default-vlan-id=2 vlan-header=always-strip vlan-mode=secure
    set 2 default-vlan-id=2 vlan-header=always-strip vlan-mode=secure
    set 3 default-vlan-id=2 vlan-header=always-strip vlan-mode=secure
    set 5 default-vlan-id=2 vlan-mode=secure
    /interface ethernet switch vlan
    add independent-learning=yes ports=ether1,ether2,ether3,ether4,switch1-cpu switch=switch1 vlan-id=2
    add independent-learning=yes ports=ether1,switch1-cpu switch=switch1 vlan-id=3

    /interface vlan
    add interface=ether1 mtu=9210 name=vlan-2 vlan-id=2
    add interface=ether1 mtu=9210 name=vlan-3 vlan-id=3

    /interface bridge
    add add-dhcp-option82=yes comment="Только для включения аппаратного моста" dhcp-snooping=yes name=bridge-lan protocol-mode=\
       none
    add name=bridge-vlan-3 protocol-mode=none
    /interface bridge port
    add bridge=bridge-lan interface=ether1 trusted=yes
    add bridge=bridge-lan interface=ether2
    add bridge=bridge-lan interface=ether3
    add bridge=bridge-lan interface=ether4
    add bridge=bridge-lan interface=wlan1
    add bridge=bridge-lan interface=wlan2
    add bridge=bridge-vlan-3 interface=vlan-3

    /ip address
    add address=10.39.0.220/24 interface=bridge-lan network=10.39.0.0
    add address=10.39.1.220/24 interface=vlan-3 network=10.39.1.0 По сути, это коммутатор с изоляцией VLAN, агрегатный порт на ether1, порт доступа к vlan-2. bridge-lan для включения аппаратного моста, а также чтобы подключить Wi-Fi к vlan-2 через порт CPU. bridge-vlan3 для интеграции интерфейса vlan-3 через порт CPU. Не использую функции VLAN моста, так как это отключит аппаратные оптимизации на данном устройстве.
     
     
     
    mkx
    Guest
    #3
    0
    27.03.2020 22:10:00
    Мои пять копеек: у этого устройства есть немного проблемный чип переключателя. У меня есть случай, когда эта ошибка мешает мне настраивать VLAN на оборудовании, и мне приходится использовать фильтрацию VLAN на мосту. Поддержка MT подтвердила проблему и сказала, что у них нет срока исправления (это было почти год назад). Это может быть связано или нет: изначально я использовал устройство, настроенное с VLAN на оборудовании, и устройство зависало несколько раз в день (монитор, настроенный на пинг другого устройства, мог перезагрузить устройство, восстанавливая сервис до следующего зависания). Нестабильность прекратилась, как только я начал использовать фильтрацию VLAN на мосту; ваша текущая настройка может быть реализована с помощью одного моста.
     
     
     
    netflow
    Guest
    #4
    0
    28.03.2020 09:34:00
    Спасибо за ответ. С одним мостом я потеряю аппаратное ускорение переключателя. Но я согласен, что это может быть единственным обходным вариантом, учитывая ошибку в чипе.
     
     
     
    mkx
    Guest
    #5
    0
    28.03.2020 11:17:00
    Упоминая единственный мост, я не имел в виду фильтрацию VLAN на мосту. Я имел в виду следующее: настроить порты Ethernet с настройками VLAN так, как у вас сейчас, добавить все порты Ethernet в один мост и создать необходимые интерфейсы VLAN поверх моста (вместо ether1, как у вас сейчас). Помните: когда bridge vlan-filtering=no, мост ведет себя точно как тупой (не VLAN) коммутатор и не обращает внимания на теги VLAN (ему важны только MAC-адреса). В этом случае прикрепленные порты должны с ними работать. Для портов Ethernet это уже сделано. Для портов WLAN нужно настроить use-vlan=yes vlan-id=XY… некоторые интерфейсы не поддерживают «родной» VLAN и не могут быть подключены к такому мосту (но я не вижу таких в вашей конфигурации). Как я упоминал в своем предыдущем посте, я преобразовал свою конфигурацию в мост с фильтрацией VLAN. Действительно, весь трафик проходит через CPU, но в случае RBD52G CPU достаточно мощный, чтобы обеспечивать соединения на скорости проводного порта без перегрузки. Узким местом становится связь на 2 Гбит/с полный дуплекс между CPU и чипом коммутатора… что на самом деле достаточно для связывания двух пар портов Ethernet, когда устройства общаются в полудуплексном режиме (что в реальной жизни происходит чаще всего). Так что да, такая конфигурация действительно снижает пропускную способность переключения/мостов, но в реальном использовании не сильно.
     
     
     
    netflow
    Guest
    #6
    0
    29.03.2020 13:47:00
    Спасибо за отличный совет, это заставило меня снова попробовать эту настройку, которую я изначально пытался сделать без успеха. Мне пришлось отключить DHCP snooping и убрать default-vlan-id для порта CPU. Теперь это гораздо более чистая настройка. Я все еще сталкиваюсь с проблемой стабильности ядра, но теперь устройство хотя бы может перезагрузиться само. Так что я могу считать это вехой.
     
     
     
    netflow
    Guest
    #7
    0
    10.04.2020 17:27:00
    С помощью USB последовательного кабеля, подключенного к локальной консоли, я всё еще мог получить доступ к маршрутизатору, как только он потерял все соединения по Ethernet и Wi-Fi. В журналах есть две подозрительные записи незадолго до потери соединения: Apr/10/2020 18:42:37 ошибка сценария: поврежденный системный пакет: плохой образ Apr/10/2020 18:46:48 ошибка сценария: поврежденный системный пакет: плохой образ. Я сгенерировал supout и отправил его в поддержку MT.
     
     
     
    netflow
    Guest
    #8
    0
    10.04.2020 18:37:00
    Эта проблема с пакетом, вероятно, возникла из-за какой-то корruptции во время тестирования устройства. Я обновился до 6.47beta54. Я все еще могу воспроизвести проблему с подключением практически по желанию, для этого достаточно некоторой активности по Wi-Fi (например, speedtest) на одном клиенте с 5 ГГц вместе с какой-то записью во флеш-память. Теперь я действительно подозреваю, что проблема в флеш-накопителе. Поскольку это уже мое второе устройство с такой же проблемой, я очень надеюсь, что это программный сбой и MT сможет исправить это в ближайшее время.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры