admin

Всё верно, протокол больше не поддерживается, поэтому компонент пришлось удалить. Нет возможности нести затраты по поддержке сервиса 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/amnezia-vpn/amneziawg-linux-kernel-module/blob/master/src/junk.c#L184 ). Сейчас проверил еще раз, он распознается правильно. Вам стоит обратиться к вашему провайдеру или руками удалять I*, так как они у вас "нерабочие".

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

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

Служебный сертификат кинетика сменился на netcraze.io, старый keenetic.io генерит поток запросов на обновление (это баг, но на работу устройства сильно не влияет). Поможет либо обновиться на 4.3.7, 5.0.7 (когда они выйдут), либо удалить, как Вы и сделали. Сертификат берется автоматически. Он нужен для переходов в устройство из RMM, внутри MWS-системы, и для других облачных функций в будущем.

В более старых моделях просто не было WS-Discovery.

Установить 5.0 и выше.

Потому что все сделано по стандарту, а перезагружаться стали только кривые китайские поделки. А нормальные устройства все себя нормально ведут.