Jump to content

Albram

Forum Members
  • Posts

    340
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Albram

  1. Разница есть, например, при копировании больших объёмов в локалке с/на hdd, у которого скорость чуть больше 100МБайт/сек при чтении (не Мбит).
  2. Нет такой возможности, т.к. стоит максимально возможная. У меня тоже, например телефон, иногда подключаются одинаково и с WPA2 и с WPA3 на 585Мбит/сек, но затем с WPA3 он в течении считанных минут, а иногда и почти сразу, переходит на 866Мбит/сек и так и остается на этой скорости, если условия не меняются. Тогда как с WPA2 долго держит 585, и потом переключается на 650Мбит/сек, а максимально что я видел на нём с WPA2 это 705. ))) логично, но хочу разобраться, может есть возможность использовать смешанный режим.
  3. После замены роутера на KN-1810 (Версия ОС 3.4.12) имя сети wifi cделал прежним, а шифрование выставил WPA2-PSK + WPA3-PSK, т.к. есть устройства и с WPA2 и с WPA3. Все устройства сети, после ввода нового пароля, успешно зарегистрировались, кто с WPA2, кто с WPA3, кроме Apple TV 3-его поколения (модель A1469). На нём выходила ошибка: "Введённый пароль сети Wi-Fi недействителен. Повторите попытку. (-100)" или (-3900), но при этом не предлагалось ввести другой пароль. После включения старого роутера с таким же именем wifi сети, после первой же неудачной попытки предлагалось ввести новый пароль, и если в этот момент выключить старый роутер и ввести пароль сети от нового, то Apple TV успешно регистрировался на KN-1810. Попробовав различные комбинации (забыть сеть, перезагрузка с выключением и т.д.), но без включенного старого роутера невозможно было зарегистрироваться в wifi сети KN-1810. После этого решил сбросить настройки на Apple TV к заводским, но после сброса ничего не изменилось, он по-прежнему не регистрировался в сети с той же ошибкой. В итоге оказалось, что причина в WPA3, который этот старый Apple TV не поддерживает. После выставления на роутере шифрования WPA2-PSK + WPA3-PSK, Apple TV перестает регистрироваться в сети, и, ни в логе, ни в файле self-test нет видимых попыток регистрации. Т.е. после сохранения новой конфигурации, все устройства в течении нескольких секунд успешно регистрируются, и это видно и в логе, и в self-test, а попыток регистрации от Apple TV нет. Если оставить только шифрование WPA2, то через 4-5 секунд после сохранения конфигурации Apple TV успешно регистрируется в сети, и это видно и в логе, и в self-test. Проблема скорее всего в Apple TV (хотя не обязательно), но хотелось бы понять, почему в логах и self-test нет ничего, что указывало бы на проблему. Все другие устройства, причем того же периода выпуска и поколения, как и Apple TV, например старый планшет iPad Air, тоже не поддерживающие WPA3, прекрасно регистрируется с WPA2. Собственно вопрос навеян тем, что в режиме WPA2-PSK + WPA3-PSK, устройства с WPA3 соединяются на более высокой скорости, чем когда выставлен только WPA2. Или регистрируются на примерно одинаковой, но затем быстро доходят до максимальной с WPA3.
  4. Нет, это нужно для понимания как работает DPI вашего провайдера. Т.е. вы этого не делали при настройке? Конечно, просто добавить правило iptables для перенаправления всех запросов на 80 порт в тор, но это снизит быстродействие, т.к. тор ещё тот тормоз, и нужно делать исключения для нужных веб интерфейсов (например роутера). Ещё вам нужно выяснить какое правило вызывает вот эту ошибку: "ip: RTNETLINK answers: Address family not supported by protocol"
  5. Чтобы это понять, нужно знать какой провайдер у вас указан в настройках скрипта, какой провайдер у вас на самом деле, в каком режиме работает скрипт (fragmentation, modification и т.д.), и видеть вывод запуска blockcheck при отключенных всех обходах и dnscrypt. А по тем данным, которые приведены, можно сказать, что проблема начинается здесь: и возможно она связана с использованием ipv6.
  6. Это может быть связано с чем угодно, вы же никакой технической информации не привели. Вам нужно начать с самого начала, с запуска blockcheck при отключенных всех обходах и dnscrypt (если используется). А потом, по полученным результатам, сравнивать этот вывод с режимом, в котором работает скрипт, и смотреть подходит этот режим или его нужно менять.
  7. Неординарное, конечно, применение, но реализовать такое проще, т.к. не нужно вести и обновлять ipset и фильтровать запросы по соответствию этому списку. Глянул в скрипты, которые сейчас используются, их структура и размещение стали совсем другими, чем было когда я это настраивал... Попробуйте удалить из всех используемых скриптом правил iptables опции сравнения с ipset, чтобы все пакеты направить на фрагментацию. Для примера, применительно к настройкам по умолчанию в скриптах, в файле firewall.user.mns в двух местах удалите значения: -m set --match-set zapret src
  8. Вот это скорее всего. В первом сообщении этой темы написано: "У скрипта 3 режима работы Fragmentation - принудительно выставляется малый размер TCP окна, в результате чего пакеты фрагментируются и не попадают под анализ DPI. Используется NFQUEUE. Самый быстрый режим. Установлен по умолчанию. Работает в IPv4 для HTTP и для HTTPS (не всегда) " Перед установкой вы проводили тестирование на компе со всеми выключенными средствами обхода (включая dnscrypt, или что-то иное) вот этим ?
  9. Здравствуйте. Да, на 2.16 zapret работает. Настроенный на роутере zapret вам тут не поможет. Он для другого предназначен. Придется вам продолжить его использовать, или искать по каким параметрам оператор определяет, что запросы идут с ПК (а возможно, что он определяет не то, что с ПК идут запросы, а то, что раздается интернет на тарифах для этого не предназначенных, вот и блокирует), и искать как это обойти. Подсказка: если проблема в том, о чем я написал в скобках, то вам поможет фиксация ttl, но с "игрой" с ttl в 2.16 не всё гладко, прочтите посты немного выше, например этот.
  10. 👍 Видимо да, если вообще оно будет. Я по совету Le ecureuil позвал в эту тему @vst (он и до этого тут отписывался), и если у него будет время и желание, тогда думаю, что решение найдется.
  11. Не совсем так. Статуса LISTEN на udp портах нет, посмотрите на другие сервисы, висящие на udp портах, они тоже без статуса listen, но это не значит, что эти порты не слушаются. В 2.16 проблема в отсутствии процесса на udp/3702, а не в том, что нет статуса LISTEN. Вот так выглядит, когда не работает сетевое определение: ~ # netstat -tulnp | grep 3702 tcp 0 0 0.0.0.0:3702 0.0.0.0:* LISTEN 1385/tsmb-server А так, когда работает: ~ # netstat -tulnp | grep 3702 tcp 0 0 0.0.0.0:3702 0.0.0.0:* LISTEN 1385/tsmb-server udp 0 0 0.0.0.0:3702 0.0.0.0:* 1385/tsmb-server
  12. Там версия без внешнего файла конфига, потому и размер меньше. В принципе, эта версия тоже должна работать.
  13. Страницу, надеюсь новую открыли, или обновили? Модуль cgi установлен? ~ # opkg list-installed | grep lighttpd Настройки по части cgi ещё раз проверьте. Где-то там скорее всего ошибка.
  14. Вопросительный знак после service нужно вводить, но это уже неважно, т.к. выше TheBB подсказал, что через вебинтерфейс роутера выключите "Сервер WebDAV". После этого посмотрите исчезли ли процессы прошивочного lighthhtpd ps | grep lighttpd И если их там нет, то запустите lighttpd из Entware: /opt/etc/init.d/S80lighttpd start Проверьте что он запустился: ps | grep lighttpd Если запустился, то пробуйте выполнить ручную проверку в smarthtml.
  15. В CLI роутера посмотрите какие сервисы доступны для управления: (config)> service ? Нужно попробовать остановить запущенный прошивочный lighttpd, и запустить lighttpd из Entware.
  16. Но lighttpd из Entware не стартует. Тогда попробуйте найти конфиг для работающего прошивочного lihgttpd find / | grep lighttpd.conf
  17. Смотрите есть ли /opt/etc/init.d/S80lighttpd, и посмотрите что в /tmp/lighttpd/lighttpd.conf
  18. А вы как lighttpd ставили, что у вас бинарный файл лежит в /usr/sbin/, а конфиг в /tmp/ ? Эти каталоги к Entware не имеют отношения. Или lighttpd у вас в прошивке есть? При установке, как на первой странице этой темы, бинарник должен быть в /opt/sbin/lighttpd, а конфиг в /opt/etc/lighttpd/lighttpd.conf
  19. Да, было бы неплохо, если бы @vst помог. Суть проблемы вкратце: после перезагрузки или включения роутера нет процесса tsmb-server слушающего порт udp/3702, есть только tcp/3702. Переключением в CLI значения cifs master (cifs no master) на противоположное, перезапускает сервис, и появляется процесс tsmb-server на udp/3702. В версии 2.16.D.3.0-4 вероятность того, что процесс на udp/3702 будет работать после старта роутера, была близка к 50%, в 2.16.D.3.0-5 стало заметно хуже. У меня, например, после 5 перезагрузок сервиса не было ни разу.
  20. И тут всё нормально, если на 8080 у вас ничего больше нет (но тогда lighttpd не запускался бы).
  21. Обновился до 2.16.D.3.0-5, т.к. там более новая версия tsmb. Теперь, вместо, примерно 50x50, при перезагрузке, что порт 3702 будет слушаться и на tcp, и на udp, стало так, что, после пяти перезагрузок, ни разу сервис на udp/3702 не поднимался. Пока срабатывает только изменение cifs no master или cifs master.
×
×
  • Create New...