ndm

Посмотрите в startup-config. Обычно все отмены настроек делаются с помощью приставки "no". Например "no schedule такое-то" полностью удаляет расписание такое-то. Отключить перезагрузку по расписанию — no system reboot. Не забудьте сохранить конфиг после этого: system configuration save

Release 3.1 Beta 4: Wi-Fi: fixed tremendous slowdown of SMB, DLNA, and other embedded applications via 5GHz Wi-Fi on Extra (KN-1710), and Duo (KN-2110) MWS: fixed configuration of Captive Portal segments on extender devices MWS: fixed misinterpretation of Bridge5 as a segment on Keenetic DSL (KN-2010) and Duo (KN-2110) DDNS: fixed profile assignment to a non-existent network interface Web: fixed Safari 10 support

Версия 3.1 Beta 4: Wi-Fi: исправлена низкая скорость передачи TCP-трафика SMB, DLNA и других встроенных приложений по Wi-Fi 5 ГГц на Extra II, Extra (KN-1710) и Duo (KN-2110) MWS: исправлена передача настроек сегмента с включенной функцией Captive Portal на экстендеры MWS: исправлена передача Bridge5 в качестве сегмента при использовании в роли контроллера Keenetic DSL (KN-2010) или Duo (KN-2110) DDNS: исправлена обработка ошибки при назначении профиля на несуществующий интерфейс Web: исправлена работа в Safari 10

Да, большую часть проблем dual-image решает. Но иногда, сразу старта обновленной версии прошивается загрузчик, и если поврежден начальный сектор, всё слетает к хренам. Тогда никакая кнопка и восстановление не спасает, но это всё в теории. Что на самом деле сломалось, можно только гадать. Заменят и старый в помойку выкинут.

Какие еще пути, разбираться самому. Припаять консоль, подключиться и читать, что там. На кнопку реагирует работающая прошивка! А по симптомам всё слетело под корень.

Всё верно, работаем. Вместо адреса будет доменное имя экстендера, которое дома резолвится в его прямой адрес, а через интернет работает по KeenDNS (облачный доступ) при условии, что он включен на контроллере. Изоляция в Wi-Fi-системе — вопрос более сложный, чем кажется. Синхронизировать настройку (вкл-выкл) изоляции на всех экстендерах ничего не даст, потому что клиенты, подключенные к разным экстендерам, будут видеть друг друга по проводу. Если хотите, обсудим формулировку: «изоляция клиентов на сегменте X Wi-Fi-системы означает, что через BridgeX каждого экстендера может передаваться только трафик между Wi-Fi-клиентами и контроллером, плюс изоляция клиентов внутри AccessPoint-ов, включенных в BridgeX». Всех устроит такая примитивная реализация? Это означает, что либо контроллер при включении изоляции должен передать свой MAC-адрес на экстендеры (придумаем API какой-нибудь, interface BridgeX peer-isolation [controller]), либо они автоматически будут брать MAC-адрес шлюза.

Не совсем понятно, о каком клиенте речь. Экстендер получает адрес сразу во всех сегментах, чтобы мог работать роуминг. Но клиент, подключенный через экстендер, имеет адрес только в одном сегменте согласно SSID, к которому он подключился. И адрес клиента можно "зафиксировать", т.е. настроить, чтобы DHCP-сервер выдавал ему всегда один и тот же адрес.

Не нужно, достаточно указать сегмент "Network access", и к нему будет доступ. Попробуйте пул адресов PPTP-сервера настроить 192.168.1.X - 192.168.1.Y, но так, чтобы они не пересекались с пулом DHCP. Если на тп-линке доступ со стороны PPTP-клиента в сторону PBX открыт, всё заработает. Есть ощущение, что дело в тп-линке, который не знает, куда посылать пакеты до 192.168.1.0/24. Если адреса PPTP-клиентов будут совпадать с домашней сетью, ему будет проще. И для кинетика это корректная конфигурация.

Настройки VPN-сервера на кинетике ограничены, там нельзя сделать правила для каждого клиента, и идентификация подключений в оболочке отсутствует. (Она есть в linux, но на уровень CLI кинетика не выведена.) Возможностей VPN-сервера по умолчанию достаточно для простых задач. Пока всё, что можно менять — это настраивать доступ через VPN к выбранному сегменту или к интернету в целом. Если нужны гибкие настройки, пользуйтесь GRE, IPIP и другими, но это совсем другая тема. Никаких специальных ограничений на SIP/UDP в VPN-сервере нет, т.е. если "удаленная сеть пингуется", то и всё остальное должно работать. Вы пишете, что телефон находится за tp-линком, но не очень понятно, где и по какому адресу у вас FreePBX.

Release 3.1 Beta 3 : MWS: fixed error 'system failed [0xcffd004e]' MWS: fixed association with backhaul access points in manual mode fixed timezone offset representation

Версия 3.1 Beta 3 : MWS: исправлена ошибка 'system failed [0xcffd004e]' при захвате экстендеров MWS: исправлено подключение к backhaul-точке доступа в ручном режиме DECT: добавлена поддержка трубки Gigaset C530HX исправлено отображение смещения часовых поясов

Release 3.1 Beta 2: MWS: fixed MAC ACL configuration (@VVS reported) DLNA: fixed media directory names Chilli: fixed compatibility with Yota USB modems

Версия 3.1 Beta 2: MWS: исправлена передача настроек MAC ACL на экстендеры (сообщил @VVS) DLNA: исправлено отображение имен папок медиатеки Chilli: адаптирована работа с USB-модемами Yota

Да, спасибо. Мы сделаем, чтобы лишние адреса не рассылались на экстендеры.

Да, теперь понятно: 50:ff:20:.....:b4 — MAC-адрес кинетика City с адресом 192.168.1.34 MAC-адрес добавлен в список "known host", который рассылается на все экстендеры, в том числе и на City При рассылке из списка удаляются MAC-адреса экстендеров При добавлении MAC-адреса в access-list он должен быть среди зарегистрированных, но его там нет Вывод — нужно удалять экстендеров из "interface mac access-list" при рассылке, спасибо Держать их там нет смысла, раз теперь они висят на backhaul-ТД

Причина ошибки [0xcffd0045] не в пароле, она будет исправлена отдельно. Если экстендер запаролен, его захватить нельзя. Даже если пароль одинаковый с контроллером, это не поможет. Контроллер не хранит пароль и не может его ввести при захвате. Вы можете продолжать пользоваться так же, как и на 3.0, т.е. не делать захват. Какие минусы: Придется все настройки на экстендере вводить вручную. На беспроводных экстендерах будет только домашний сегмент. Не будет работать режим backhaul, т.е. 4-адресная схема Wi-Fi-подключения. Это означает, что MAC-адреса устройств, расположенных за экстендером, будут подменяться MAC-адресом экстендера. При этом функция MAC-repeater, призванная "исправить" проблему с MAC-адресами в версиях 2.x, удалена из кода Wi-Fi-драйвера. Пароль должен быть сброшен только на момент захвата. При захвате контроллер копирует настройки на все экстендеры, в том числе реалм и хеш пароля, так что дети ничего лишнего не натворят. Сам контроллер работает с экстендерами через SSL, авторизуясь по токену.

Проявляется, когда content-length превышает 64k, в ближайшей версии исправим.

Release 3.1 Beta 1: NAT: added GRE and IPIP protocols to "ip static" rules MWS: fixed STP communication between mt7610 and mt76x2 wireless extenders

Версия 3.1 Beta 1: NAT: добавлена поддержка протоколов GRE и IPIP в правилах "ip static" MWS: исправлена передача STP между экстендерами на базе mt7610 и mt76x2

спасибо за поддержку, но судя по статусу (KN-1810, 3xKN-1910 и т.д.) Вы не являетесь представителем широкой социальной группы...

В этом году точно нет. Их преимущества очевидны, но и спрос на такие устройства на территории продаж KN тоже известен, и пока он не позволяет строить такие планы.

Release 3.1 Alpha 5: MWS: implemented wireless connections between Wi-Fi extenders (learn more) TSMB: fixed file listing (@Кинетиковод reported) Opkg: added Cypress M8 support for Powercom UPS (@Namenloss requested) Release 3.1 Alpha 6: MWS: added backhaul connection details to "show mws member" MWS: added "show mws associations" command for backhaul AP diagnostics

Версия 3.1 Alpha 6: MWS: добавлена расширенная информация о подключении в "show mws member" MWS: добавлена команда "show mws associations" для диагностики backhaul AP

Через CLI это можно сделать, как и с любым другим устройством. Нам велели скрыть экстендеры из списка устройств, после чего пропала возможность присвоить ему фиксированный IP через web.

Не было reject, на giga II только через opkg+iptables такие вещи. По более новым железкам — создавайте тему в развитии.