admin

Внимание: для устройств KN-1111, KN-1211, KN-1212, KN-1311, KN-1611, KN-1711 последней официальной версией является 4.3 LTS. Ветка 5.0 не планировалась для долгосрочной поддержки, а продолжение выпуска 5.1 и выше для данных устройств технически затруднено. Принято решение для KN-1111, KN-1211, KN-1212, KN-1311, KN-1611, KN-1711 удалить каналы обновлений Preview и Dev, и оставить только 4.3 LTS.

Это было случайностью. Этот адрес нужен только на этапе первоначальной настройки и только из локалки, дальше все переходит на пользовательский домен с сертификатом.

Не нужно хардкодить адреса, просто на домен и поддомены keenetic.net сделайте апстримом адрес роутера в вашей локальной сети.

Эти адреса не принадлежат каким-то непубличным подсетям в смысле RFC1918, и они маршрутизируются. Они только не могут быть кому-то отданы в рамках процедуры делегации. Тем, кто не использует DNS из роутера так или иначе не смогут на него попасть по этому адресу, так как мы его никогда не заявляли "мировой константой", хардкодить его было нельзя. Также после получения сертификата KeenDNS в любом случае будет редирект туда.

Всё верно, протокол больше не поддерживается, поэтому компонент пришлось удалить. Нет возможности нести затраты по поддержке сервиса netatalk, включая выпуск обновлений безопасности. см. также https://ru.wikipedia.org/wiki/Apple_Filing_Protocol:

Должно быть исправлено в вышедшем 5.1 и предстоящем 5.0.

Визуально по коду должны работать

Исправлена когда-то будет, но пока или это, или на 4.3 сидеть.

Пока на время поиска железа и исправления влияющая часть wsd будет включена только в Home-сегменте. Камеры из других сегментов не будут подвержены.

Спасибо за репорт, поправлено.

Вся валидация происходит во внешнем модуле ядра, и если он не возвращает ошибки - то мы тоже считаем что это ok. На совсем грубые ошибки он проверяет, но ошибки "по сути" - это уже к авторам модуля, не все их задумки нам до конца ясны.\ Насчет оригинальной проблемы - у ТС на самом деле параметр нормальный, он корректно обрабатывается ядром, но такое ощущение что ответная сторона ожидает другое его значение. В таком случае мы, разумеется, не можем помочь ничем - параметр сам по себе валидный.

wireguard asc 5 10 50 148 66 147632797-1874677417 2094890447-2129672526 2130979375-2142094535 2142582337-2147294952 23 5 "<b 0x084481800001000300000000077469636b65747306776964676574096b696e6f706f69736b0272750000010001c00c0005000100000039001806776964676574077469636b6574730679616e646578c025c0390005000100000039002b1765787465726e616c2d7469636b6574732d776964676574066166697368610679616e646578036e657400c05d000100010000001c000457fafe25>" "" "" "" ""

Замена с I1 = <b 0x084481800001000300000000077469636b65747306776964676574096b696e6f706f69736b0272750000010001c00c0005000100000039001806776964676574077469636b6574730679616e646578c025c0390005000100000039002b1765787465726e616c2d7469636b6574732d776964676574066166697368610679616e646578036e657400c05d000100010000001c000457fafe25> на I1 = 0x084481800001000300000000077469636b65747306776964676574096b696e6f706f69736b0272750000010001c00c0005000100000039001806776964676574077469636b6574730679616e646578c025c0390005000100000039002b1765787465726e616c2d7469636b6574732d776964676574066166697368610679616e646578036e657400c05d000100010000001c000457fafe25 выключает I1-тег, так как он обязательно должен быть в треугольных скобках для применения, иначе просто выходит из обработки ( https://github.com/asc-vpn/ascwg-linux-kernel-module/blob/master/src/junk.c#L184 ). Сейчас проверил еще раз, он распознается правильно. Вам стоит обратиться к вашему провайдеру или руками удалять I*, так как они у вас "нерабочие".

Если включен dns-based routing, то на версии 5.0 это ожидаемый процесс. В 5.1 вероятно ситуация будет улучшена.

Всем спасибо за столь активный интерес к данной ситуации. Однако хотелось бы не будить лихо, пока оно тихо, и громко кричать имена собственные сторонних сервисов. Потому тему пока прикроем, а сам протокол давайте называть, ну скажем, ASC 2.0. Так вот, ASC 2.0 (мне так кажется) стоит ждать в ближайшее время.