-
Постов
2 268 -
Зарегистрирован
-
Посещение
-
Победитель дней
38
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент KorDen
-
php7-fastcgi не содержит файлов и не создает скрипт в init.d ~ # opkg files php7-fastcgi Package php7-fastcgi (7.2.2-1) is installed on root and has the following files: ~ # opkg info php7-fastcgi Package: php7-fastcgi Version: 7.2.2-1 Depends: libc, libssp, librt, libpthread, php7, php7-cgi Status: install user installed Section: lang Architecture: mipsel-3.4 MD5Sum: ff7acd63ca70817d3b2ccd0cb837379a Size: 746 Filename: php7-fastcgi_7.2.2-1_mipsel-3.4.ipk Description: As FastCGI support is now a core feature the php7-fastcgi package now depends on the php7-cgi package, containing just the startup script. Installed-Time: 1523257518
-
Из виндовых как минимум в uTorrent и qBittorrent можно указать диапазон исходящих портов, и оно правильно работает, проверено. Скажем, есть основной толстый проводной инет; резерв LTE-модем; VPN через текущий дефолтный канал. Большинство клиентов ходят через текущий дефолт. Для торрентов (source-based) и другого тяжелого, но не критичного трафика (скажем, онлайн-видеонаблюдение, при наличии локальной записи - тут уже destination ip:port based) задан жестко только толстый инет, и при его падении они должны дохнуть, чтобы не забить резерв и не выкачать лимит. При этом я например могу независимо закинуть условно ПК где крутятся торренты ходить в сеть через канал VPN, но торренты должны продолжить ходить через инет (по задаваемому приоритету правил или по принципу наиболее точного правила) Дальше думаю о том, что вроде как нельзя рулить destination ip/port, Мыcль улетает в сторону традиционных цисковских access-list или -t mangle -j mark, потому что как-то не совсем ясно, как будут указываться разные диапазоны входящих/исходящих портов в Ip hotspot. Скажем, правило "только толстый канал" в моем представлении бы содержало что-то типа (имена переменных условны) src_host aa:bb:cc:dd:ee:ff src_port tcp 20000 through 21000 src_host aa:bb:cc:dd:ee:ff src_port udp 20000 through 21000 dst_host 1.2.3.4 dst_port tcp 8443 dst_host 5.6.7.8/24 При этом у этого правила высший приоритет, дальше с приоритетом пониже я могу добавить для src aa:bb:cc:dd:ee:ff правило "ходить только через vpn" а условные торренты и пакеты в сетку 5.6.7.8/24 продолжат ходить мимо VPN (последнее это по сути обычный маршрут через заданный, добавлено для наглядности и чтобы были понятны приоритеты) Короче, типичный mangle/mark, только интегрированный с существующей системой резервирования инета.
-
По порту со стороны клиента же, как я и написал... Ну т.е. в клиенте строго указываем исходящий порт (диапазон), входящий трафик уже идет на один конкретный порт. А дальше политика на tcp/udp стримы с диапазона портов. В том числе в идеале хитрую политику на распределение по двум каналам... Или выделение по tcp/udp порту - тяжелая нагрузка?
-
Возможно ли в дальнейшем расширение до полноценного PBR по портам? Типа "не гнать торренты (source host aa:bb:cc:dd:ee port 1234) в 3G-модем"?
-
Подозреваю, возможности мониторить состояние хостов с точки зрения роутера. Скажем, банально измерять пинг/процент потерь до яндекса, или через прокси забирать данные по мониторингу локальных железок с офиса без использования туннелей. Но всё же это в сторону Entware, до тех пор пока в младших моделях флеш маленький и нет нормальной ФС для хранения настроек-сертификатов-etc, будет отчасти так же костыльно, как сейчас с конфигом OpenVPN
-
А это нормально, что хотя в opkg.conf остались прописаны только новые пути, при opkg update он продолжает стучаться и по старому пути? ~ # opkg update Downloading http://entware-3x.zyxmon.org/binaries/mipsel/Packages.gz Updated list of available packages in /opt/var/opkg-lists/keen3x Downloading http://bin.entware.net/mipselsf-k3.4/Packages.gz Updated list of available packages in /opt/var/opkg-lists/entware Downloading http://bin.entware.net/mipselsf-k3.4/keenetic/Packages.gz Updated list of available packages in /opt/var/opkg-lists/keendev
-
Словил странный глюк (сейчас 2.12.A.4.0-6), пока не было времени поэкспериментировать и выявить, нужно было срочно починить. Две линии с разными номерами с одного сервера, две S850HX. Линия 1 - IN/OUT с трубок 1 и 2, Линия 2 - IN/OUT только с трубки 2. В итоге получилось, что звонки на первую линию так же идут только на трубку 2, первая трубка при входящем вызове молчит, т.е. ощущение что правило для входящих для 2 линии применилось и для 1 линии. Исходящие можно было делать с обоих. Перезагрузка не помогла, починилось удалением второй линии (не пробовал разрешить входящие со 2 линии на 1 трубку).
-
Динамический проброс (ssh -D 1234 с последующим socks-прокси на этот порт с выходом куда угодно через роутер, в т.ч. в инет) работать будет, или только статический/с ограничениями?
-
Пока - нет, но stv6110.ko уже есть в модулях, да и учитывая "Drivers are included in kernel branch 2.6.39", чую, поддержка скоро появится, если будете тестировщиком @McMCC, похоже тему надо переименовывать в "Смотрим цифровое телевидение (DVB) через кинетик" и указывать кто какие стандарты поддерживают
-
@McMCC, я уже собрал у себя 4.0.9 с поддержкой DVB, всё работает на Ultra II (ну, еще надо будет работоспособность DVB-S ради интереса проверить..)
-
Ага, @Александр Рыжов подсказывает, что в Entware tvheadend собран без поддержки DVB, а я видимо действительно уже запутался где я что видел. @McMCC, уже готового tvheadend с поддержкой dvb у вас случаем нет?
-
Я пользовался тем, что есть в Entware-3x, т.е. 4.0.9. На ультре он вроде успешно видел T230C, сейчас воткнул на экстре только T230C - тоже не видит напрямую, что-то где-то поломано похоже.. Edit: Так, на 2.12.A.4.0-2 вроде тюнеры завелись (вообще, не в tvheadend), пошел обновлять ультру на проверку...
-
О, на драйвере tbs похоже взлетело, по крайней мере по логу Update: Работает DVB-C minisatip -> tvheadend, напрямую в tvheadend тюнер что-то не подхватывается, но это уже детали
-
@McMCC, FAIL на прошивке _2338, вначале случайно подсунул пустой файл фирмвари, получил очевидный фейл, но вот за исключением трейса vmalloc всё остальное похоже аналогично, т.е. даже без подгрузки прошивки... depmod -a после прошивки запускал. С фирмварью получил аналогичную прошлым ошибку: 0001 тоже не отличается вроде:
-
В usb-devices после покдлючения тюнера появляется только T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=734c ProdID=5521 Rev=00.01 S: Manufacturer=TBS-Tech S: Product=TBS 5521 C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=tbs5520se
-
Тут еще проблема в том, что неосторожное движение в вебе может очень сильно всё поломать. Взять хотя бы переименование ISP и ISP-IPTV и обратно при добавлении/удалении VLAN. А потом вспомнить о всяких tunnel source ISP. По-хорошему веб должен кричать что что-то не то и предлагать просмотреть diff конфига, но партия идет по пути "ничего лишнего в вебе" И в итоге простая правка параметров ipsec-туннеля в вебе при необходимости править конфиг превращается в глубокое погружение в ipsec с его фазами, терминологией policy-map-...
-
Не, всё равно на get_device_parent.isra.6+0x5c/0x1e8 падает. Замечу, у меня на ПК на версии от crazycat зависает полностью система при переподключении. В случае с Extra II это был USB-хаб с Ethernet (AsixEthernet), на ультре были только тюнер+флешка, на ПК только тюнер... Попозже скину с ПК
-
@McMCC, да вроде не особо отличается Странно, при горячем подключении тюнера дергается весь USB-хаб...