+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

v6.43.16 [долгосрочная версия] выпущена!

v6.43.16 [долгосрочная версия] выпущена!, Объявления

emils

Guest

15.05.2019 11:42:00

RouterOS версия 6.43.16 была выпущена в публичном “долгосрочном” канале! Перед обновлением: Не забудьте сделать резервную копию/экспорт файлов перед обновлением и сохранить их на другом носителе; Убедитесь, что устройство не потеряет питание в процессе обновления; Устройство имеет достаточно свободного места для загрузки всех пакетов RouterOS. Что нового в 6.43.16 (2019-14 мая 11:40): Изменения в этом релизе: *) w60g - исправлена утечка памяти (введена в v6.43.15); Чтобы обновиться, нажмите "Проверить обновления" в разделе /system package в интерфейсе конфигурации вашего RouterOS или перейдите на нашу страницу загрузок: http://www.mikrotik.com/download Если у вас возникли проблемы, связанные с версией, отправьте файл supout с вашего роутера на support@mikrotik.com. Файл должен быть сгенерирован, когда роутер не работает так, как ожидалось, или после того, как на устройстве возникла проблема. Пожалуйста, держите эту тему форума строго в рамках этого конкретного релиза RouterOS.

hnt

Guest

16.06.2019 10:08:00

Привет, я хотел обновить мой wAP LTE KIT с версии 6.42.9 до последнего обновления с исправлениями, но критическая функция, которую я использую — LTE Passtrough — кажется, работает по-другому, и мне интересно, нормально ли это, потому что новый способ работы нарушает функциональность для меня. Настройка следующая: wAP LTE KIT ----eth---- Juniper SRX. На wAP настроена функция LTE Passtrough, а Juniper SRX является DHCP-клиентом. На версии 6.42.9 все работало отлично. После обновления Juniper обменивается DHCP-пакетами с Mikrotik, однако результат в том, что Mikrotik говорит: "data assigned xx.x.x.x to xx:xx:xx:xx:xx:xx", но Juniper не настраивает IP-адрес. Может, кто-то объяснит, что именно изменилось? Я видел в журнале изменений информацию о /32, но вижу, что это не все. Например, шлюз отправляется другим способом, как и server-id. Я был бы признателен за любую информацию, чтобы я мог дальше расследовать эту проблему.

zBear Guest	#3 0 01.07.2019 11:46:00 мы получим долгосрочную версию с этим исправлением?

daggerCVN Guest	#4 0 01.07.2019 13:21:00 Аналогично по поводу недавнего обновления уязвимостей в Linux DOS — получит ли Long-Term его и когда. Если нет, пожалуйста, предоставьте рекомендуемые правила фильтрации для брандмауэра. Спасибо.

Deantwo

Guest

01.07.2019 13:36:00

В advisory, на который ссылается блог, предлагается блокировать TCP-трафик с низким MSS, но не уточняется, что именно подразумевается под "низким MSS". Так что я думаю, это может быть что-то вроде этого: /ip firewall raw add action=drop chain=prerouting protocol=tcp tcp-mss=0-500 Но это только предположение, я бы подождал официального ответа от MikroTik. Как упомянуто в advisory, это может повлиять на нормальную работу, если легитимный TCP-трафик использует "низкий MSS".

ivanfm Guest	#6 0 01.07.2019 13:47:00 Примеры iptables рассматривают 1:500 как маленький диапазон iptables -A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001/block-low-mss/iptables.txt

muetzekoeln Guest	#7 0 01.07.2019 14:02:00 Пожалуйста, посмотрите также: http://forum.mikrotik.com/t/linux-vulnerabilities-cve-2019-11477-cve-2019-11478-cve-2019-11479/130957/1

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры