Информация
Настройка
Новости
Контакты
Новинка
Распродажа
Оплата
Доставка
Загрузки
  • Прошивки
    • 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
    При автоматическом обновлении произошла ошибка: истекло время ожидания соединения.

    При автоматическом обновлении произошла ошибка: истекло время ожидания соединения.

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    При автоматическом обновлении произошла ошибка: истекло время ожидания соединения., RouterOS
     
    smilem
    Guest
    #1
    0
    16.08.2014 21:11:00
    Здравствуйте, Реклама кажется приятной: "Если вы уже используете RouterOS, обновление до последней версии очень простое. Всего один клик — и RouterOS найдет свежую версию, покажет список изменений и предложит обновиться. Сделать это можно через Winbox, консоль, Webfig или QuickSet. Просто нажмите «Проверить обновления» в QuickSet, Webfig или в меню пакетов Winbox." Но на деле, когда я пытаюсь автоматически обновить свою Mikrotik OS, получаю ошибку: Ошибка — время соединения истекло. Роутер не может получить последнюю версию и обновиться. Как это решить? Нужно ли создавать правило в файерволе для обновлений? Если да, не могли бы подсказать подробности?
     
     
     
    nacholibrev
    Guest
    #2
    0
    17.02.2015 15:31:00
    У меня была такая же проблема, всё из-за моего файрвола — он блокировал все подключения с незнакомых источников. Отключи свой кастомный файрвол, который сбрасывает (TCP), и попробуй снова.
     
     
     
    lambert
    Guest
    #3
    0
    18.02.2015 03:56:00
    Хотя весь управляющий трафик до моих устройств RouterOS работает и я могу пинговать и подключаться по SSH к Интернету с устройств RouterOS, проверка автообновления зависала, пока я не добавил правила проверки состояний в цепочку input фаервола. Похоже, что под капотом используется FTP. Я не копался, почему это не работало без разрешения для established и related соединений в input.

    /ip firewall filter  
    add chain=input comment="разрешить установленные соединения" connection-state=established  
    add chain=input comment="разрешить связанные соединения" connection-state=related  

    Просто поставьте их перед правилами deny. Чем ближе к верху правил allow, тем лучше производительность.
     
     
     
    xiliane
    Guest
    #4
    0
    28.02.2015 16:09:00
    Я только что сбросил кэш DNS.
     
     
     
    beef
    Guest
    #5
    0
    23.04.2016 03:14:00
    Ни одно из этих предложений мне не подходит, и я не вижу ничего в моём фаерволе (v4 или v6), что могло бы блокировать пакеты.

    [admin@T-Bone] /system package update> check-for-updates
    channel: current  
    current-version: 6.35  
    latest-version: 6.35  
    status: ERROR: connection timed out  

    [admin@T-Bone] /system package update>
    [admin@T-Bone] /ip firewall filter> print
    Flags: X - отключено, I - недействительно, D - динамическое  

    0    ;;; VPN  
         chain=input action=accept protocol=ipsec-ah log=no log-prefix=""  

    1    ;;; VPN  
         chain=input action=accept protocol=ipsec-esp log=no log-prefix=""  

    2    ;;; VPN  
         chain=input action=accept protocol=udp port=500,4500,1701 log=no log-prefix=""  

    3    ;;; Разрешить установленные соединения  
         chain=input action=accept connection-state=established log=no log-prefix=""  

    4    ;;; Принять связанные соединения  
         chain=input action=accept connection-state=related log=no log-prefix=""  

    5    ;;; Разрешить ICMP (ping)  
         chain=input action=accept protocol=icmp limit=50/5s,2:packet log=no log-prefix=""  

    6    chain=input action=accept src-address=192.168.1.0/24 in-interface=!pppoe-out1 log=no log-prefix=""  

    7    ;;; Бросить недействительные соединения  
         chain=input action=drop connection-state=invalid log=no log-prefix=""  

    8    ;;; Бросить всё остальное  
         chain=input action=drop log=no log-prefix="IPV4 Firewall"  

    9 I  ;;; Ограничения по времени для DC:85:DE:2C:B3:5A "CJ_The_Second" (AzureWave Technology)  
         ;;; время неактивности  
         chain=forward action=reject reject-with=icmp-admin-prohibited src-mac-address=DC:85:DE:2C:B3:5A time=1h-8h,sun,mon,tue,wed,thu,fri,sat log=no log-prefix=""  

    10 I  ;;; Ограничения по времени для 94:DE:80:CE:5A:EA "CJ_the_Second" (Giga-Byte Technology Co,)  
         ;;; время неактивности  
         chain=forward action=reject reject-with=icmp-admin-prohibited src-mac-address=94:DE:80:CE:5A:EA time=1h-8h,sun,mon,tue,wed,thu,fri,sat log=no log-prefix=""  

    11 I  ;;; Ограничения по времени для 00:1F:5B:CA:53:2A "CJ" (Apple Inc)  
         ;;; время неактивности  
         chain=forward action=reject reject-with=icmp-admin-prohibited src-mac-address=00:1F:5B:CA:53:2A time=1h-8h,sun,mon,tue,wed,thu,fri,sat log=no log-prefix=""  

    12 I  ;;; Ограничения по времени для C0:CE:CD:36:97:41 "iPhone" (Apple Inc)  
         ;;; время неактивности  
         chain=forward action=reject reject-with=icmp-admin-prohibited src-mac-address=C0:CE:CD:36:97:41 time=1h-7h,sun,mon,tue,wed,thu,fri,sat log=no log-prefix=""  

    13    ;;; Разрешить уже установленные соединения  
         chain=forward action=accept connection-state=established log=no log-prefix=""  

    14    ;;; Разрешить связанные соединения  
         chain=forward action=accept connection-state=related log=no log-prefix=""  

    15    ;;; Бросить недействительные соединения  
         chain=forward action=drop connection-state=invalid protocol=tcp log=no log-prefix=""  

    16    ;;; Заблокировать bogon  
         chain=forward action=drop src-address=0.0.0.0/8 log=no log-prefix=""  

    17    ;;; Заблокировать bogon  
         chain=forward action=drop dst-address=0.0.0.0/8 log=no log-prefix=""  

    18    ;;; Заблокировать bogon  
         chain=forward action=drop src-address=127.0.0.0/8 log=no log-prefix=""  

    19    ;;; Заблокировать bogon  
         chain=forward action=drop dst-address=127.0.0.0/8 log=no log-prefix=""  

    20    ;;; Заблокировать bogon  
         chain=forward action=drop src-address=224.0.0.0/3 log=no log-prefix=""  

    21    ;;; Заблокировать bogon  
         chain=forward action=drop dst-address=224.0.0.0/3 log=no log-prefix=""  

    22    chain=forward action=jump jump-target=tcp protocol=tcp log=no log-prefix=""  

    23    chain=forward action=jump jump-target=udp protocol=udp log=no log-prefix=""  

    24    chain=forward action=jump jump-target=icmp protocol=icmp log=no log-prefix=""  

    25    ;;; Запрет TFTP  
         chain=tcp action=drop protocol=tcp dst-port=69 log=no log-prefix=""  

    26    ;;; Запрет RPC portmapper  
         chain=tcp action=drop protocol=tcp dst-port=111 log=no log-prefix=""  

    27    ;;; Запрет RPC portmapper  
         chain=tcp action=drop protocol=tcp dst-port=135 log=no log-prefix=""  

    28    ;;; Запрет NBT  
         chain=tcp action=drop protocol=tcp dst-port=137-139 log=no log-prefix=""  

    29    ;;; Запрет cifs  
         chain=tcp action=drop protocol=tcp dst-port=445 log=no log-prefix=""  

    30    ;;; Запрет NFS  
         chain=tcp action=drop protocol=tcp dst-port=2049 log=no log-prefix=""  

    31    ;;; Запрет NetBus  
         chain=tcp action=drop protocol=tcp dst-port=12345-12346 log=no log-prefix=""  

    32    ;;; Запрет NetBus  
         chain=tcp action=drop protocol=tcp dst-port=20034 log=no log-prefix=""  

    33    ;;; Запрет BackOriffice  
         chain=tcp action=drop protocol=tcp dst-port=3133 log=no log-prefix=""  

    34    ;;; Запрет DHCP  
         chain=tcp action=drop protocol=tcp dst-port=67-68 log=no log-prefix=""  

    35    ;;; Запрет TFTP  
         chain=udp action=drop protocol=udp dst-port=69 log=no log-prefix=""  

    36    ;;; Запрет PRC portmapper  
         chain=udp action=drop protocol=udp dst-port=111 log=no log-prefix=""  

    37    ;;; Запрет PRC portmapper  
         chain=udp action=drop protocol=udp dst-port=135 log=no log-prefix=""  

    38    ;;; Запрет NBT  
         chain=udp action=drop protocol=udp dst-port=137-139 log=no log-prefix=""  

    39    ;;; Запрет NFS  
         chain=udp action=drop protocol=udp dst-port=2049 log=no log-prefix=""  

    40    ;;; Запрет BackOriffice  
         chain=udp action=drop protocol=udp dst-port=3133 log=no log-prefix=""  

    41    ;;; echo reply  
         chain=icmp action=accept protocol=icmp icmp-options=0:0 log=no log-prefix=""  

    42    ;;; net unreachable  
         chain=icmp action=accept protocol=icmp icmp-options=3:0 log=no log-prefix=""  

    43    ;;; host unreachable  
         chain=icmp action=accept protocol=icmp icmp-options=3:1 log=no log-prefix=""  

    44    ;;; host unreachable, фрагментация необходима  
         chain=icmp action=accept protocol=icmp icmp-options=3:4 log=no log-prefix=""  

    45    ;;; разрешить source quench  
         chain=icmp action=accept protocol=icmp icmp-options=4:0 log=no log-prefix=""  

    46    ;;; разрешить echo request  
         chain=icmp action=accept protocol=icmp icmp-options=8:0 log=no log-prefix=""  

    47    ;;; разрешить time exceed  
         chain=icmp action=accept protocol=icmp icmp-options=11:0 log=no log-prefix=""  

    48    ;;; разрешить parameter bad  
         chain=icmp action=accept protocol=icmp icmp-options=12:0 log=no log-prefix=""  

    49    ;;; запретить все остальные типы  
         chain=icmp action=drop log=no log-prefix=""
     
     
     
    beef
    Guest
    #6
    0
    05.06.2016 16:52:00
    Хорошо, я полностью в растерянности на данный момент. Мой сертифицированный дилер Mikrotik говорит, что DNS настроен правильно, и я сделал чистую установку сети по его рекомендации, но без результата. Я даже создал правило фаервола в цепочке input, чтобы принимать всё, и поставил его в начало списка.
     
     
     
    pe1chl
    Guest
    #7
    0
    05.06.2016 18:13:00
    По моему опыту, это не работает, если MTU вашего интернет-соединения меньше 1500 и вы не настроили «clamp TCP MSS to MTU». Думаю, это баг в их серверах обновлений.
     
     
     
    beef
    Guest
    #8
    0
    05.06.2016 18:55:00
    Хмм, это, пожалуй, самый ценный совет на данный момент, спасибо. Мой MTU меньше 1500 на интерфейсе PPPoE (который сам по себе является MLPPP DSL-соединением). Однако, я не вижу опции clamp ни на одном из моих текущих интерфейсов.
     
     
     
    pe1chl
    Guest
    #9
    0
    05.06.2016 19:33:00
    Вы можете настроить правило в цепочке postrouting на странице Mangle в фаерволе, которое будет соответствовать TCP-трафику на вашем интерфейсе PPPoE и изменять MSS с последующим применением действия clamp MSS к PMTU.
     
     
     
    beef
    Guest
    #10
    0
    05.06.2016 20:57:00
    Окей, это самый близкий вариант, который мне удалось найти для решения этой проблемы… Все ещё иногда выскакивают сообщения о тайм-ауте, но, похоже, со временем всё же удаётся как-то проскочить успешно. Вот моё правило: chain=postrouting action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp log=no log-prefix=""
     
     
     
    pe1chl
    Guest
    #11
    0
    06.06.2016 06:40:00
    Окей, это здорово! Но не знаю, почему это не решает всю проблему целиком. Я не проверял, работает ли это в postrouting, вы можете попробовать заменить правило на два отдельных: одно в цепочке output (для самого роутера) и другое — в цепочке forward (для трафика от пользователей). Я заметил эту проблему, когда подключал роутер к интернету через VPN. MTU на стороне интернета меньше, чем локальный MTU на роутере. В таком случае роутер, который предоставляет VPN (выше по цепочке), посылает сообщения «пакет слишком большой» к серверу обновлений, сервер снижает размер пакета и повторно отправляет его, и этот пакет приходит к роутеру, который нужно обновить. Но роутер не запоминает новый размер пакета, и следующий пакет снова отправляется на полный размер. Поскольку сообщения «пакет слишком большой» не приходят для каждого пакета, соединение постепенно умирает, и роутер, который нужно обновить, выдает ошибку таймаута. Метод «clamp MSS» заставляет сервер обновлений постоянно использовать меньший MSS. Однако, на мой взгляд, это баг самого сервера обновлений. Он отдан на аутсорсинг cloudfront.net, так что MikroTik, скорее всего, не имеет на это большого влияния.
     
     
     
    markmuehlbauer
    Guest
    #12
    0
    10.03.2017 17:24:00
    Это ОПРЕДЕЛЁННО баг, который тянется «вечно». Честно говоря, я махнул рукой после множества постов с подтверждением, что это баг, и это было ещё несколько лет назад. На мой взгляд, забудьте про эту функцию — она абсолютно ненадёжна. Mikrotik — отличная «черная коробка», которая умеет всё, но вот в этом одном вопросе обновлений через System/Packages — полный провал. Да, я просто высказываюсь, но в конце хочу сказать: лучше сосредоточьтесь на чём-то важном и забудьте эту функцию, потому что она сломана и никто не собирается это исправлять.
     
     
     
    pe1chl
    Guest
    #13
    0
    11.03.2017 08:58:00
    Подождите минутку, это ошибка на сервере обновлений, облачном веб-сервере в интернете, а не в роутере MikroTik!
     
     
     
    TedjeVanEs
    Guest
    #14
    0
    14.03.2017 21:28:00
    Раньше, кажется, всё работало: какое-то время назад я обновлялся автоматически с версии 5.x до 6.x. Но сейчас это не работает. Когда это починят? Плавное автоматическое обновление — это же вопрос безопасности для всех.
     
     
     
    beef
    Guest
    #15
    0
    01.05.2017 22:50:00
    Ну что ж, оказывается, версия 6.39 решила эту давнюю проблему!! Думаю, это связано с «ppp — реализован внутренний алгоритм для “change-mss”, правила mangle не нужны;».
     
     
     
    pe1chl
    Guest
    #16
    0
    02.05.2017 07:46:00
    Тоже может быть! В общем, для большинства пользователей это как будто замалчивает проблему. Конечно, ситуация не улучшается, если вы используете VPN, который не применяет PPP в качестве промежуточного уровня. Удивительно, что облачный веб-сервис (они используют cloudfront) может так долго существовать с неправильной обработкой ICMP-сообщений «превышен размер»…
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры