
hoaxisr
Участники форума-
Постов
44 -
Зарегистрирован
-
Посещение
-
Победитель дней
1
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент hoaxisr
-
Последняя "стабильная" 4.3.4 - есть большое внутреннее сопротивление ставить эту версию. ( 4.3.2-то пришлось ставить по указанию техподдержки.) Вернусь к тестированию и информированию с появлением 5.х в бете или 4.3.х > 4.3.4 в стабильном канале.
-
В целом, да. Раз роутеров без wifi у Кинетик не имеется и планов таких решений видимо нет. То неплохо было бы иметь лицензию на контроллер, поскольку ставить головным роутер кинетик не хотелось бы, а точки доступа вполне себе конкурентные.
-
Добавлю sock5 в политике по умолчанию стоят в самом низу, вверху самый первым стоит основное PPPoE соединение с провайдером.
-
Текущая реализация точек доступа (Buddy, Voyager, и роутеров, переведенных в режим ретранслятор) предполагает наличие роутера Keenetic в качестве головного устройства (да, есть в базе знаний статья как использовать такой роутер без DHCP сервера), но железка все равно нужна. Предложение: выделить компоненты системы "Контроллер WiFi системы" как отдельный продукт с возможностью установки на x86/arm операционные системы для управления точками доступа Keenetic. Продавать на это ПО лицензию (тут уж маркетинг компании сам оценит стоимость/планы и так далее). Цель: дать возможность использовать и строить WiFi сети без головной железки Keenetic, на базе программно-аппаратных решений широкого спектра. Расширить позиционирование точек доступа как масштабируемое решение SMB.
- 2 ответа
-
- 1
-
-
Подскажите, пожалуйста, является ли нормальным следующий сценарий поведения роутера и устройств: 1.Имеем роутер с KeeneticOS 4.3.2 2. На роутере есть сервер l2tp/ipsec, sstp 3. Сервер по этим протоколам для клиентов настроен с опцией "доступ в LAN (домашний сегмент сети)" 4. На роутере есть sock5 подключение(я) , которые ведут к локальной машине, на которой есть настроенный прием такого соединения и его редирект в vless на удаленные сервера. Если sock5 активны, то 1. клиенты l2tp не следуют правилам маршрутизации домашней сети, при это клиенты sstp им следуют. 2. Все мобильные устройства с функцией vowifi идут только через socks5. И пропадает мобильная связь у устройств, пока они подключены к wifi. По этой причине. Если отключить socks5 прокси, то поведение устройств с vowifi становится ожидаемым, они идут к свои узлам как положено через основное интернет соединение. Клиенты l2tp/ipsec сервера тоже начинают следовать правилам маршрутизации домашней сети.
-
Установил filebrowser, дал ему путь в смонитрованный диск. Он не зависает конечно при открытии папок, но какие-либо действия совершить в папке с большим количеством фото не может - он вешает роутер. Лучший вариант доступа для меня - SMB там все работает. А как решить проблему назначения папки для WebDAV или SMB пока не ясно. Была бы хотя бы в CLI возможность конфигурации. Было бы круто.
-
Вариант конечно. Ещё вариант прямо указать, что при большом количестве файлов роутер не nas и все сломается. Прям в разделе с usb. Ещё вариант не кешировать роутеру то, что не требуется. В этом нет никакой практической пользы.
-
Это не поможет настроить "приложения" в webui роутера. Ему же нужно указывать папки для webdav/smb/ftp, а это становится невозможным.
-
"Задумывается", но не уходит в ребут как 7621 роутер. И отображений миниатюр нет в webui. Совершенно не ясно для чего кешировать корневые папки, перед открытием корня диска.
-
Добрый день, аналогичное поведение и на других роутерах, там правда более слабое железо (7621), но симптомы аналогичные. Если в корне будет папка с большим (около 20 тысяч) количеством файлов, то WebUI не сможет открыть даже корень диска и показать папки. Хотя поддержка говорит о том, что ограничений на количество файлов нет, по факту оно есть. Как один из путей решения, который помог мне - это создание "матрёшки" из папок, если внутри проблемной папки создать подпапки и раскидать туда файлы можно будет видеть корень диска через webui. ошибки в селф тесте кстати будут видны, но толку от этого немного.
-
Если смотреть "активные соединения" то в моменте когда это было - не было вообще ни одного соединения из вне. Плюс доступ к webdav же тоже по https (на вкладке "Приложения/Личное облако/WebDAV") видно, что соединение через https.
-
OpenConnect сервер, IKeV2/IPSec, WG, WebDAV
-
Май 23 16:36:50 ndm Netfilter::Util::Conntrack: flushed 229 IPv4 connections for 127.0.0.1. Май 23 16:36:50 ndm Netfilter::Lockout::Manager: "Http": ban remote host 127.0.0.1 for 15 minutes. Может не нужно самобаниться? Хотя все продолжает работать вроде после этого сообщения.
-
После установки MagiTrickle у меня автоматически демон не запускался через /opt/etc/init.d/rc.unslung соответственно netfilter.d/100-magictrickle вылетал с ошибкой. Изменил хук из netfilter.d на такой: #!/bin/sh SOCKET_PATH="/opt/var/run/magitrickle.sock" BIN="/opt/bin/magitrickled" # Проверяем, что бинарник существует и исполняемый [ -x "$BIN" ] || exit 0 # Проверяем, запущен ли демон if ! pidof magitrickled >/dev/null 2>&1; then # Если не запущен, запускаем в фоне "$BIN" & # Немного ждем, чтобы сокет успел появиться sleep 1 fi # Если сокет есть, отправляем запрос if [ -S "$SOCKET_PATH" ]; then BODY="{\"type\":\"$type\",\"table\":\"$table\"}" LENGTH=$(printf "%s" "$BODY" | wc -c) socat - UNIX-CONNECT:"$SOCKET_PATH" >/dev/null 2>&1 <<EOF POST /api/v1/system/hooks/netfilterd HTTP/1.1 Host: Content-Type: application/json Content-Length: $LENGTH $BODY EOF fi exit 0 И теперь демон даже если не поднимается (а он не поднимается через автозапуск entware у меня), то его поднимет хук. Может быть будет полезно.
-
Можно и не закрывать. Я был бы рад, если бы упростили этот процесс. и просто добавили выбор режима работы в стоковую прошивку. Логика позиционирования мне не ясна, но это дело производителя конечно. Тем более он в случае необходимости может использоваться весьма интересно. Там БП же встроенный.
-
Тему можно закрывать, SDK все позволяет сделать уже сейчас. Правда можно было бы сильно упростить процесс, если бы хоть немного документации дать. Но в целом, спасибо, что даёте такой инструмент.
-
Не секрет, что все устройства семейства Buddy есть полные аппаратные "клоны" устройств с функцией роутер. Фактические отсутствие режима "роутер" носит исключительно программный характер (возможно по каким-то маркетинговым соображениям), дайте, пожалуйста, возможность включить функционал "роутер" в рамках фирменного ПО, без необходимости установки альтернативных решений на Linux ПО. Возможно неплохим вариантом может стать возможность сборки такой прошивки через Keenetic SDK без предоставления поддержки или апгрейда. То есть самостоятельная ответственность пользователя. Вообще роутер, имеющий исключительно получать internet по 1 порту и просто раздавать его по wifi это прям отличное устройство закрывающее потребности некоторого числа клиентов. Плюс цена устройств buddy обычно выше своих аппаратных братьев в форм факторе "роутер".