Andrew V.

Мне в тг саппорт прислал целый лист возможных исправлений, что потестить с моей стороны. Пока ft не отключал, чтобы действовать по их рекомендациям. Попросили сменить интервал GTK Rekey на тех устройствах в мэше, на которых он не поменялся автоматом (в моем случае почти на всех))) Повторюсь, по факту это не проблемы с переключением клиентов между точками. У меня есть изолированная точка KN-1110 в том же мэше (соединена оптикой с головным Peak) - на расстоянии больше 500 метров. Там клиенты, которые всю жизнь знали только эту точку. И там прошивка еще 4.3.6.2 - в более новую прошивку оно не умеет, но всегда в мэше работало отлично. Так вот и на той точке после перехода головного PEAK на 5.1.0 посыпались те же ошибки pairwise key handshaking timeout (msg 1 of 4-way), replay counter differs in key handshaking (msg 2 of 4-way) - вплоть до того, что клиенты начинали подключаться только после принудительной их перезагрузке по питанию. Кроме того, саппорт мне ответил: Также мы заметили, что в конфигурации Ultra2 стоит старый интервал GTK Rekey. По умолчанию все устройства должны обновлять ключ (group temporal key) для шифрования broadcast/multicast трафика (ранее стояло 3600 секунд, в последних версиях мы увеличили интервал до 86400 секунд), но некоторые клиенты могут сбрасывать сессию при rekey, отключаться, перезапрашивать адрес. Все это может накладываться на изменение настроек и перезапуск контроллера То есть получается, что у многих клиентов с переходом на 5.1.0 если у них в мэше есть либо неактуальные устройства, либо устройства, на которых не тестили 5.1.0 (та же ультра2) - потенциально могут получить такие же проблемы с отвалом устройств из-за смены интервала GTK Rekey на головном роутере?

Благодарю за ответ. А можно надеяться на какой-то фикс этой проблемы? Потому что до этого ни разу за многие годы не было проблем с FT. А клиентов в сети активных у меня под сотню одновременно. А на 5.1.0 такие проблемы не только на китайских релюшках (туя, сонофф и тд), но и на мфу HP и даже устройствах под ios (3 айфона и 3 планшета точно выпадают из сети домашней после любого изменения в ней). Если надо - готов участвовать в тестировании, присылать логи, селфтесты, конфиги и тд.

Да скорее всего дело именно в нем (пока не пробовал, но такая мысль тоже давно есть), но почему это началось именно на 5.1.0 - вот это интересно. Ведь ft у меня был включен уже многие годы, никакие настройки не менял - проблем не было ни разу до 5.1.0

Посмотрите логи, возможно, та же ошибка pairwise key handshaking timeout (msg 1 of 4-way), replay counter differs in key handshaking (msg 2 of 4-way) и т.д. как и у меня.

При любом изменении настроек сети - перезагрузке основного роутера, добавления клиента и тд - на всех роутерах в wifi системе (всё на 5.1.0) начинается вот такое

У меня всегда был wpa2, проблем не было вообще никогда с Tuya. Начались с 5.1.0. И с забыванием свойств устройств под ios тоже началось на 5.1.0. Что-то странное происходит, в логах полно ошибок, мол неправильный ключ, хендшейк не проходит и тд. Это что-то на стороне прошивки.

Ситуация повторяется почти каждый день. Ко мне подходят домашние с претензией, что не работает wifi на их ios гаджетах. Захожу в настройки ipad или iphone, вручную выбираю домашнюю сеть, устройство подключается к сети с частным адресом (хотя частный адрес был отключен для этой сети давно), без запроса пароля, после чего выключаю частный адрес - и всё работает нормально - до следующего отключения или перезагрузки роутера. Потом повторяется по кругу. Что случилось на 5.1.0 - непонятно. Часть wifi устройств туя висит до сих пор в оффлайне, придётся их искать и перезагружать по питанию.

После перехода на 5.1.0 заметил странности с ios клиентами. В доме 4 айфона и штук 6 айпадов. Всё отказывались автоматом подключаться к wifi, хотя до этого на бетах работали без проблем. На каждом пришлось вручную в настройках заново выбрать сеть, устройство сразу подключалось (без необходимости ввода пароля), но подключалось в режиме частного wifi адреса, хотя ранее на всех устройствах частный адрес был отключен. Аналогичные проблемы время от времени возникают с wifi устройствами умного дома - в основном под Tuya. Они не могут нормально переподключиться к сети и выпадают в оффлайн. В логах ошибки типа pairwise key handshaking timeout (msg 1 of 4-way), replay counter differs in key handshaking (msg 2 of 4-way) и т.д. Пока спасаюсь регулярной перезагрузкой то кинетиков, то устройств. Такое ощущение, что кинетики перестали запоминать своих зарегистрированных клиентов. На всех предыдущих прошивках, в том числе beta и тд - всё с этим было нормально, теперь каждое утро просыпаюсь - что-нибудь отвалилось и надо идти переподключать.

Подтверждаю, на 5.1.0 начали регулярно сыпаться устройства tuya, постоянные ошибки в логах типа pairwise key handshaking timeout (msg 1 of 4-way), replay counter differs in key handshaking (msg 2 of 4-way) и т.д. Помогает перезагрузка, но ненадолго. И не всегда. Иногда приходится полностью перезагружать само устройство. До этого на всех бетах 5.1 с этим проблем не было. Везде wpa2, так что дело не в этом точно.

Более того, в приложении они висят как подключенные к головному роутеру проводом (хотя они wifi), а в вебе - как оффлайн. В общем, какая-то глобальная проблема с этим.

UPD 2. Проблема снова возникает после каждой перезагрузки основного роутера в мэш системе. Решается только полной перезагрузкой клиента. Похоже, это всё-таки баг прошивки 5.1.0.

Upd. Всё решилось полной перезагрузкой всех кинетиков в wifi системе и тех клиентов, на которых наблюдались эти проблемы. Странно, на предыдущих десятках обновлений такого поведения не наблюдал.

Похоже на регрессию в обработке публикаций KeenDNS/NDNS в 5.01.C.0.0-1 для сценария “устройство/MAC + нестандартный HTTP-порт” и отдельно для port forwarding через облачный KeenDNS. Факты: В конфигурации 5.01.B.4.0-1 рабочая публикация Home Assistant была задана через устройство/MAC на порт 8123: ip http proxy ha upstream http <HA_MAC> 8123 domain ndns ssl redirect security-level public Эта же версия также содержала проброс 591 → <HA_MAC>:8123. В конфигурации 5.01.C.0.0-1 исходная запись через MAC сохранилась, а дополнительно был создан тестовый вариант через IP: ip http proxy ha1 upstream http <HA_IP> 8123 domain ndns ip http proxy ha upstream http <HA_MAC> 8123 domain ndns При этом проброс 591 → <HA_MAC>:8123 тоже остался. DHCP-привязка <HA_MAC> → <HA_IP> присутствует в обеих конфигурациях, то есть сам адрес устройства в конфиге не потерян. REST/CLI вывод показывает принципиальную разницу: запись, созданная по IP, формирует нормальный upstream, а запись, созданная через устройство/MAC, даёт пустые поля: "ha": "upstream": "<HA_IP>:8123" "ha1": "upstream": "", "host": "" При этом другие записи, созданные через устройство/MAC, но на стандартный HTTP-порт 80, работают. В конфиге таких записей несколько: domofon, road2, pool — все через MAC и порт 80. Вывод по HTTP Proxy: ломается не сам MAC-resolve вообще, а конкретная комбинация: запись KeenDNS, созданная через устройство/MAC, с upstream на нестандартный HTTP-порт 8123. При создании той же публикации по IP upstream формируется корректно. Вывод по port forwarding: правило 591 → <HA_MAC>:8123 в конфигурации сохранилось после обновления, но через облачный KeenDNS стало отдавать 403 Forbidden. Поскольку по другому клиенту порт 280 → 80 работает, это не общая поломка облачного доступа, а проблема с обработкой конкретных нестандартных портов/целей в облачном режиме KeenDNS. Формулировка гипотезы: в 5.01.C.0.0-1 появилась регрессия в слое KeenDNS/NDNS cloud publication, связанная с обработкой внутренних сервисов, заданных через объект устройства/MAC и нестандартный TCP-порт. Дополнительно похожая регрессия проявляется в port forwarding через облачный KeenDNS: правило есть, но внешний доступ через domain:591 возвращает 403. В UI запись через устройство/MAC отображается как <HA_IP>:8123, но в REST/CLI proxy backend для неё имеет upstream="" и host="". Та же запись, созданная вручную по IP, формирует upstream корректно. Одновременно port forwarding на тот же хост и порт через облачный KeenDNS возвращает 403. Обе проблемные схемы используют один и тот же объект назначения по MAC: <HA_MAC> → 192.168.1.123 → 8123 И обе ломаются после обновления: ip http proxy через <HA_MAC>:8123 → upstream пустой / не тот сервис ip static 591 → <HA_MAC>:8123 → через KeenDNS отдаёт 403 При этом вариант: ip http proxy через 192.168.1.123:8123 работает. Значит наиболее аккуратная гипотеза: В 5.01.C.0.0-1 сломалась обработка назначения, заданного через MAC/объект устройства, для внешней публикации сервиса Home Assistant на нестандартном порту 8123. Это проявляется и в ip http proxy, и в ip static port forwarding через облачный KeenDNS. Обе неисправности объединяет один и тот же способ указания цели: не IP-адрес, а устройство/MAC. При указании IP тот же сервис работает.

Чуть конкретики: После обновления с 5.01.B.4.0-1 на 5.01.C.0.0-1 в облачном режиме KeenDNS (без белого IP) обнаружены два изменения поведения, которых ранее не было. Проблема 1. Переадресация через KeenDNS стала возвращать 403 Используется стандартная переадресация порта на внутренний сервис: ip static tcp <WAN> 591 <HOST_MAC> 8123 Данная запись присутствует как в конфигурации 5.01.B.4.0-1, так и в 5.01.C.0.0-1. До обновления работал доступ вида: http://<domain>.keenetic.pro:591 После обновления тот же URL возвращает: 403 Forbidden При этом: внутренний сервис продолжает работать локально; правило переадресации сохранилось; конфигурация не изменялась; проблема появилась сразу после обновления. Проблема 2. Изменилось поведение HTTP Proxy через KeenDNS В рабочей конфигурации 5.01.B.4.0-1 присутствует публикация сервиса: ip http proxy ha upstream http <HOST_MAC> 8123 domain ndns ssl redirect security-level public После обновления на 5.01.C.0.0-1 данный proxy перестал открывать опубликованный сервис и вместо него отображается веб-интерфейс роутера. Для проверки был создан дополнительный proxy: ip http proxy ha1 upstream http <HOST_IP> 8123 domain ndns ssl redirect security-level public где в качестве upstream используется IP-адрес того же устройства вместо MAC-адреса. Поведение через IP отличается от поведения через MAC, что позволяет предположить возможную проблему в обработке upstream по MAC-адресу. Почему предполагаю связь между проблемами Обе проблемы появились одновременно после перехода с 5.01.B.4.0-1 на 5.01.C.0.0-1. Обе затрагивают механизмы публикации внутренних сервисов через KeenDNS в облачном режиме. При этом: обычная доступность сервиса внутри LAN сохранена; DHCP-привязка MAC ↔ IP не изменялась; записи публикации и переадресации в конфигурации сохранились. Поэтому есть подозрение, что обе неисправности могут иметь общий источник в изменениях работы KeenDNS / NDNS / HTTP Proxy между версиями B.4 и C.0. При необходимости могу предоставить оба startup-config для сравнения.

Обновился с 5.1 beta 4 на 5.1.0 - смотрю внешний доступ к home assistant тут же отвалился. Начинаю разбираться. Вижу две странности с переадресацией. Home Assistant внутри сети у меня по адресу http://192.168.1.123:8123 Первая проблема. У меня настроено его доменное имя таким образом: На 5.1 beta 4 по этому адресу ha.blabla.keenetic.pro извне открывался Home Assistant без проблем, на 5.1 теперь открывает заглавную страницу самого Кинетика (как будто ha. - неверное доменное имя). Стоит поменять на любого другого клиента в сети с 80 портом - тут же по имени открывается этот клиент. Возвращаю 8123 порт и Home Assistant - опять открывается сам роутер. На 5.1 beta 4 всё открывалось нормально и по этому имени Home Assistant был доступен извне. Вторая проблема. У меня настроена переадресация таким образом: На 5.1 beta 4 при переходе извне по blabla.keenetic.pro:591 я попадал в интерфейс Home Assistant. Ha 5.1.0 при переходе извне по blabla.keenetic.pro:591 я попадаю на страницу keendns с кодом ошибки "403 - именно так с одной кавычкой. При этом вторая переадресация на Счетчик с порта 280 на порт 80 работает прекрасно. Меняю в первом адресе в выходе на что угодно с портом 80 - работает, возвращаю Home Assistant и 8123 порт - опять ошибка "403. Итого: на 5.1.0, похоже, появилась проблема с переадресацией на порты, отличные от 80. Причем проявляется она в целом ряде мест. UPD. По совету из tg группы сделал следующее: "укажите "Другой клиент" и ip адрес вашего сервера с HA в доменном имени 4го уровня" и адрес ha.blabla.keenetic.pro снова стал открывать Home Assistant. Но при этом если возвращаю не "Другой клиент", а конкретный ip сервера - опять открывается роутер, а не сервер.

Подскажите, пожалуйста, dns маршрутизация ведь никогда не будет работать для сервера Home Assistant, если он в любой политике Не по умолчанию? Ситуация такая. Сервер в политике авг, но нужно, чтобы только его доступ к серверам xiaomi шел не через авг. А всё остальное - через авг. Если делать через dns маршруты - они не срабатывают, поскольку сервер в политике авг. Если делать через ipv4 маршруты - всё работает отлично, но: 1. В качестве интерфейса я могу выбрать только 1 источник интернета - а у меня их 3 (основной и 2 резервных) и хотелось бы выбрать три. И непонятно, при выбранном одном основном и его падении - коннект пойдет через авг или через резерв? Очередность нигде не настраивается. При настройках добавлять автоматически - вкл, эксклюзивный - выкл. 2. Если xiaomi сменит ip своих серверов - вся эта история превратится в тыкву. Нет ли какой-то хитрости всё-таки с dns маршрутизацией для моего случая (весь коннект сервера через выбранную политику, коннект с серверами xiaomi - НЕ через выбранную политику). Заранее спасибо!

Мне кажется, эта проблема была всегда, она не специфична для пятерки..

Моя wifi система: Контроллер - Репитер 1, Репитер 2, Репитер 3, Репитер 4. При обновлении с беты на 4.3.0 словил баг, что ретранслятор (репитер 1) с назначенным адресом 192.168.1.3 полностью пропал из wifi системы. Оказывается, это служебный айпишник, на 4.3.0 были какие-то изменения по этому поводу (сказали в саппорте, у кого этот адрес используется - лучше освобождайте). В итоге до этого система работала лет 5 с такой адресацией - после обновления на 4.3.0 всё развалилось (на странице wifi системы репитер с 192.168.1.3 висит как офлайн, при этом он в доступе по этому внутреннему адресу, спокойно открывается и тд, но wifi система не работает с ним). НО! Проблема не только в этом! Пока я не понимал, в чем дело, я решил перезахватить этот репитер. Сбросил на дефолт, включил как усилитель, подключил по проводу, захватил - всё по классике. Wifi система его захватила с другим ip - всё заработало, оставил как есть. Но спустя пару часов я заметил, что стали отваливаться клиенты, причём массово так. Два дня я это наблюдал и пытался найти причину. Пока случайно не зашел в свойства одного из отвалившихся клиентов в меню кинетика. Оказалось, что для него перезахваченный репитер почему-то оказался в запрете на подключение. Такая же ситуация оказалась на всех отвалившихся клиентах (штук 15). Убрал Репитер из запрещенных - всё заработало. Итого. Ровно на всех клиентах, где в меню кинетика стоял старый запрет на подключение к Репитеру 2 (он вообще в другом конце территории, на нем запрет стоял много лет) - при перезахвате Репитера 1 (который 192.168.1.3) - в запретах заодно оказался и перезахваченный репитер 1. Мне кажется, такого происходить точно не должно.

Оказывается, их вообще убрали..

Добрый день! Для Netcraze будет бета тестирование через testflight? Полагаю, версия Netcraze в appstore не соответствует последней бете Keenetic app в testflight.

Ого ничего себе! Никогда бы не догадался, что надо выбрать репитер галкой и только тогда появится интерфейс для его редактирования. Спасибо! P.S. Но дельту там всё равно не выбрать. В общем, странное решение. Не хватает там пункта "не выбрано", чтобы выбор остался на стороне репитера, как раньше.

В упор не вижу эту настройку в вебе в wifi системе на 4.2.3 (((

Подтверждаю, даже возможность выбора канала delta перестала работать. Было бы круто восстановить хотя бы этот функционал через UI.

У меня в мэше устройства в разном статусе добавлены за последние годы - и как тд, и как усилитель. И там, и там - недоступна смена каналов. Возможно, вам помогла именно настройка с нуля, а не смена типа устройства в мэш. Кроме того, через приложение канал меняется, так что все-таки баг, а не фича )

4.2.1 - НЕ исправлено (