mesb

Вобщем втыкание клиенту в конфиг 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 винтами к отверстиям по углам воображаемого квадрата, что позволяет устройство если нужно чуть вперёд выдвинуть например и тп. У нас одна из вариаций была вообще к ровной поверхности стены за эти уши прижали плашмя. Все органы на одной стороне, тобишь порты Лан, юсб, лампочки, кнопочки. Ну про корпус из металла полагаю и так подозреваем. Размер не больше одного юнита по высоте.

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

Обзавёлся kn2311 и пока наблюждаю растущий трафик на интерфейсе модема. Настройки сделаны аналогично 2310 модели как рекомендовал супорт и там на 3.9.3 ничего такого небыло. Пока наблюдаю будет ли этот трафик заметен мегафону.

Сложно сказать, точно лишь одно - при переходе на резерв всё работает нормально. Ничего больше я из настроек не удалял.

Следовал тут инструкции из базы знаний - в целом отлично работает, но есть нюансы: 1. На дроиде работает только при условии что на роутере запущен родной media server, со сторонними на томже роутере - никак. Пробовал с xupnpd из ентвари, стоит запустить встроенный всё норм сразу. 2. Выявилось что на айфоне не работает, телефон лажл минут 10 прицепленный по л2тп впн через вифи от мобильного роутера, но ничего в влц так и не всплыло несмотря на вкл\выкл медиа сервера.