mesb

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

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

Может возможно вернуться к практике как 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 нет на такую модель, а супорт тоже не смог собрать то что нам надо было.

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

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

Дополню немного как я это вижу: Наличие съёмных ушей с возможностью смены ориентации. Для примера на коммутах Т и Д ухи крепятся 4 винтами к отверстиям по углам воображаемого квадрата, что позволяет устройство если нужно чуть вперёд выдвинуть например и тп. У нас одна из вариаций была вообще к ровной поверхности стены за эти уши прижали плашмя. Все органы на одной стороне, тобишь порты Лан, юсб, лампочки, кнопочки. Ну про корпус из металла полагаю и так подозреваем. Размер не больше одного юнита по высоте.

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