mesb

Ну я в голове держу гига3/ультра2 и иже с ними: https://forum.keenetic.com/topic/17774-412/?do=findComment&comment=180508

Если вдруг что в курилке у нас более свободное обсуждение этих тревел/мобильных аппаратов:

Насколько я помню дельта для определенных устройств, и то как она поддерживается не совсем соответствует идее oldstable. Плюс уже озвучено было что в неё также заедет текущий стейбл, а не прошлый.

И прощай нормальный сон мобилы и многие другие сюрпризы.

Agreed, it would be nice addition after all.

Может возможно вернуться к практике как Zyxel keenetic lte где был таки разъём?)

Вобщем втыкание клиенту в конфиг ppp параметра noccp казалось бы помогло, но помоему оно тупо отключило всё шифрование что несколько не то что я хотел.

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

Всем привет. Возможно кто-то уже испытывал проблемы и нашёл решение покуда супорт молчит после моего обращения в телеге. Есть кин 2311 на актуальной 407, белый айпи, pppoe, включен пптп сервер, выставлен ключ в 128. Проблем у андроид и виндоус клиентов нет никаких при работе. Выявил проблемы когда клиентом выступает linux клиент, в частности тестирую на mageia 9, но подозреваю что ловил похожее и на федоре и на 1211 кине на работе. Нюанс следующий, подключается успешно, вы даже можете подключаться к самому кинетику на его ссх например. Но как только вы попытаетесь подключиться например по ссх на сервер в локальной сети кинетика - всё соединение умирает наглухо и на клиенте вал из логов: Смена ключа на 40 бит не помогает. Однако стоит в кинетике снять галочку требования шифрования и убрать сие mppe на клиенте - проблема исчезает. Была мысль что кривой сам клиент - но он подключается к микроту без проблем. И обратите внимание что когда я обращаюсь через тоннель к самому кинетику у меня всё работает, умирание тоннеля случается только если я обращаюсь именно в локалку кинетика словно это проблема где-то на транзите или выходе с кина. Если кто-то это уже победил чем-то помимо отключения мппе - прошу поделиться.

Ещё дополню, в пару к этому функционалу в вебе неплохо бы иметь опцию отстреливать конкретного впн юзера кнопкой и просто по времени сидения. Ибо сейчас засидевшихся приходится сбрасывать выключая и включая весь впн сервис на роутере.

Вот это прямо грусть. Хотелось бы получить этакую замену CHR от М вашего разлива на базе кинос. Чтобы вкинул на виртуалку и понеслась впны и прочие радости, да с ентваре.

Я по-моему репортил ранее это и ещё краем глаза посматривал в телеграм группу, там какраз народ тоже в это вступил на первых стабильных релизах, и в 3.9.3 они что-то поправили на тот момент с ипсеками, но нет, в отличии от других мне не повезло.

Ну мне всёже это кажется преувеличением. На моей памяти на первые релизы в стабильный канал 3.7, 3.8, 3.9 всегда поднимался вой. Даже я в какой-то момент помню офис откатывал с 3.9.3 или чот такого на последнюю 3.8 из бекапа из-за какого-то бага с впн который проявился у части офисов.

Ну я в целом долго жил на 2.16, и на актуальных стал жить начав с 3.7 и точто я вижу с разработкой и подходом увы далеко не только тут. Это в целом такие подходы к разработке приняты сейчас.

Так не получится, посмотрите в сдк, они делают добаваление новых моделей уже в новых ветках. Тоесть если оставлять в таком канале 3.9.8 гвоздями её просто не будет для новых моделей.

Нет вы поняли неправильно. Вот сейчас на момент этого поста, в олдстейбл должна быть 3.9.8 как считающаяся наиболее стабильной для разных сценариев эксплуатации. Устаканившаяся. Когда-то у нас после всех наших багрепортов устаканится и 4.0 в лице версии например 4.0.7 которая щас стабильная, но к тому времени кины уже соберутся зарелизить в стейбл канал например 4.1.1. И в момент релиза 4.1.1 в стейбл канал, есесно оно ещё не устаканившееся будет и начнётся вой, но в олдстейбл поидее переезжать должна будет 4.0.7 будучи устаканившейся.

Всмысле? Ещё раз если вам непонятно как это должно работать: Стабильная 4.0.4 Олдстабильная 3.9.8 Далее например они всё пофиксили для большинства кейсов и имеем: Стабильная 4.0.5 Олдстабильная 3.9.8 Теперь допустим что они выпустили в стейбл 4.1.1: Всё сдвигается далее: Стабильная 4.1.1 Олдстабильная 4.0.5 Понаходили опять багов и: Стабильная 4.1.2 Олдстабильная 4.0.5 К моменту как достигнем теоретической 4.1.9 Стабильная 4.1.9 Олдстабильная 4.0.5 Где-то тут они могут в альфе уже напилить какую-нибудь 5.0.1 до состояния стейбл по их мнению и выпустить в стейбл: Стабильная 5.0.1 Олдстабильная 4.1.9 Ваши посты создают впечатление что вы ожидаете что стабилизации не произойдёт, но это не так. Да она происходила не сразу, но к 3.7.5, 3.8.7, 3.9.8 или когда там заканчивался цикл, предыдущая прошивка хороша для большинства.

Я лишь напомню что не всегда тесты перед релизом могут прямо всё выявить. А бесконечно полировать современные методы разработки не приветствуют)

Идея олдстейбл не в 3.х. Я по опыту общения с продуктом понимаю что рано или поздно стабилизируется и 4.0 ветка. Просто для понимания как это вижу я, например в разрезе актуальной линейки кинов: Стейбл 4.0 Олдстейбл 3.9 Когда придет время в будущем оно превратится в: Стейбл 4.1 Олдстейбл 4.0 И даже: Стейбл 5.0 Олдстейбл 4.9 Тоесть просто каждый раз предыдущая ветка. К моменту выхода новой ветки в стейбл предыдущем будет уже юзабельна и более менее пофикшена во всех критичных нам местах. И ещё раз, камрады, необязательно дорабатывать олдстейбл и тратить время на сопровождение. По идее достаточно чтобы оно было доступно просто для установки как нужно. И давало возможность вернуться туда а не на новый свежий стейбл которому ещё предстоит пару тройку релизов устаканиться.

Идея то неплоха но врятли они чото будут менять в текущей сборочной системе. А так да, было бы неплохо иметь возможность именно выключения хотябы. У нас первые кандидаты на такие отключения были бы sip/rtsp alg, ipv6, upnp. Ибо сейчас приходится просто собирать прошивку без оных для работы.

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

Идея норм. Но возникает вопрос к впнам типа сстп и ике2 которые юзают именно кинднс. Как с ними то быть?

Поддерживаю. Есть небольшие сети с лдап/ад в локальной сети где многие на удалёнке и такое решение бы пригодилось. Добавлю только момент что нужно возможность приоритета иметь, типа если ненашло в радиусе, потом почекало локального юзера на случай проблемы.

Ну да, у меня случился такой кейс например: У нас основная масса это набор 1210/1211/1212 и пока нет проблем их покупать по мере установки новых мы просто уже проверенную 3.9.8 с нужными компонентами вливали в новый. Тоже самое происходило с 2310 по мере установки в более "сложных" местах. Однако они покупались реже и запаса мы не создаём, и в какой-то момент пришлось купить 2910 ибо он был заменой там где мы отвариваемся. И соответственно у нас нужной 3.9.8 нет на такую модель, а супорт тоже не смог собрать то что нам надо было.

Basically it is not the first time it was asking for. On the ru side of the forum there is the same request. So it would be nice to have it at least via cli