PoliceMan

Привет! Есть 2 провайдера, обновился до 4.1 и настроил wireguard на работу через запасного, при этом туннель не собирается и в логах ошибка: Мар 19 17:21:59 ndm Wireguard::Interface: "Wireguard1": "Ye...Vg=": via interface is not ready, standby. Мар 19 17:22:00 kernel wireguard: Wireguard1: invalid handshake initiation from x.x.x.x:x Я правильно понял, что функция работает только через основное соединение, или что-то сделал не так? Идея была в том, что через основное соединение идёт весь траффик, а чтоб запасное не простаивало, поднять туннель на нём.

Подскажите, вы модуль использовали pymysql или mysqlclient? С первым завелось, хотя второй должен быть побыстрее, но собрать его пока не получилось.

Привет! После обновления на ветку 3.9 (начиная с 3.9.1 и до сих пор) появились спонтанные перезагрузки на Viva (KN-1910) RU при количестве маршрутов ~80000 (в отдельной таблице). На 3.8 и ранее, таких проблем не возникало. В логах, непосредственно перед перезагрузкой, появляются следующие записи: Feb 25 06:15:40 viva ndm: Event::Forwarder: unable to send "Event::Type::DbKey" to "Network::Policy::Object_" for 30 seconds. Feb 25 06:15:40 viva ndm: Event::Forwarder: "Network::PolicyTable::Queue_" (378) backtrace: Feb 25 06:15:40 viva ndm: Event::Forwarder: <unknown>()+0x0 Feb 25 06:15:40 viva ndm: Event::Forwarder: __lock()+0x0 Feb 25 06:15:40 viva ndm: Event::Forwarder: __libc_malloc_impl()+0x80 Feb 25 06:15:40 viva ndm: Event::Forwarder: operator new(unsigned int)+0x38 Feb 25 06:15:40 viva ndm: Event::Forwarder: operator new(unsigned int, std::nothrow_t const&)+0x2c Feb 25 06:15:40 viva ndm: Event::Forwarder: (anonymous namespace)::ParseNetlinkRouteMessage_(nlmsghdr const&, AutoPVector<Network::RoutingTable::Entry, StdDeleter>&) [clone .part.0] [clone .lto_priv.0]+0x35c Feb 25 06:15:40 viva ndm: Event::Forwarder: Io::Nla::Parse::OnResponseAuto<Network::RoutingTable::FlushTable(unsigned int)::{lambda(nlmsghdr const&)#1}>::operator()(nlmsghdr const&)+0x90 Feb 25 06:15:40 viva ndm: Event::Forwarder: (anonymous namespace)::WaitForReply_(Io::Netlink&, nlmsghdr const*, Io::Nla::Parse::OnResponse*, AutoBufferBase<char>&)+0x770 Feb 25 06:15:40 viva ndm: Event::Forwarder: Io::Netlink::Send(Io::Nla::Print::PacketBase&, unsigned int, Io::Nla::Parse::OnResponse*)+0x2ec Feb 25 06:15:40 viva ndm: Event::Forwarder: Network::RoutingTable::FlushTable(unsigned int)+0x314 Feb 25 06:15:40 viva ndm: Event::Forwarder: Network::Object_::ApplyRoutes_()+0x194 Feb 25 06:15:40 viva ndm: Event::Forwarder: Network::Object_::Apply_::Apply()+0x3c Feb 25 06:15:40 viva ndm: Event::Forwarder: Task::Thread::Run_()+0x27c Feb 25 06:15:40 viva ndm: Event::Forwarder: Task::Thread::Run()+0x38 Feb 25 06:15:40 viva ndm: Event::Forwarder: Thread::StartRoutine_(void*)+0x42c Feb 25 06:15:40 viva ndm: Event::Forwarder: start()+0xc8 Feb 25 06:15:40 viva ndm: Event::Forwarder: __clone()+0x6c Есть ли возможность это исправить? Спасибо!

Получаю фото с камеры в кинетике следующей командой: ffmpeg -loglevel 0 -y -rtsp_transport udp -i rtsp://10.0.0.16:10554/udp/av0_0 -frames:v 1 snapshot.jpg

Привет! Есть Viva (KN-1910) и Ultra (KN-1810) на последних stable прошивках с обновлённым entware. Поставил man, но на любую команду с man получаю Segmentation fault. Я такой один, или проблема известная и есть решение? Спасибо!

Догадался, что можно посмотреть запросы админки) Правильный ответ: {"mac":"xx:xx:xx:xx:xx:xx","policy":{"no":true}}

Всем привет! Пытаюсь найти аналог двум командам в rest api: ip hotspot host xx:xx:xx:xx:xx:xx policy Policy3 no ip hotspot host xx:xx:xx:xx:xx:xx policy Для первой это POST /rci/ip/hotspot/host {"mac":"xx:xx:xx:xx:xx:xx","policy":"Policy3"} А вот вторую, как только не пробовал и no:true и т.д. Всегда ошибка. Подскажите правильный вариант. Спасибо!

Поддерживаю, на первой ультре тоже не ставится.

Всем привет! Пытаюсь выжать максимум скорости на гигабитном канале, при закачке торрентов. Использую qBittorrent v4.3.1 на opkg (Entware), система стоит на отдельной флешке с двумя разделами: ext4 и swap на 2 Гб, Ultra (KN-1810), который не терминирует Интернет, является частью Wi-Fi системы, подключён, так-же, гигабитом к Viva (KN-1910). Диск для закачек - SEAGATE Backup Plus Slim STDR2000202, подключен через USB 3.0 Пока выжать удалось максимум 30 Мб/с при использовании NTFS, на днях решил потестить ext4, на ней, не больше 10 Мб/с. Нашел на форуме, что рекомендуется NTFS, но сообщение от 2017 года, может, с того времени, рекомендации поменялись? Либо у кого есть советы, как оптимизировать ext (отключить журналирование например) опциями, что бы выжать больше? Или выше NTFS не прыгнуть?

Поддерживаю вопрос, на днях появилась новая версия, с другими протоколами: https://www.opennet.ru/opennews/art.shtml?num=54480

Я в итоге перешел с OpenVPN на Wireguard. Там всё ок.

Судя по ошибке в mc, кончилось место на диске.

Удалось вам победить OpenVPN? Столкнулся с такой же проблемой.

Привет! А подскажите, новый донгл будет без DECT, только FXS?

Нет, порт должен быть 443. keendns.net вроде не дает ssl сертификаты. См скриншоты. mtproto висит на порту 5443. Ссылка для телеги вида tg.<domain>.keenetic.link&port=443

В веб-интерфейсе есть доступ к внутренним ресурсам по имени. Там можно выбрать на какой ресурс внутри сети давать доступ (в том числе и сам кинетик), по какому домену четвертого уровня и на какой порт внутри сети пробрасывать. Поднимаете mtprotoproxy на любом порту, настраиваете правило и ресурс становится доступным по указанному имени, на 443 порту. Не факт что взлетит, но попробовать стоит.

А если попробовать в сторону публикации ресурса на домене четвертого уровня?

Поддерживаю вопрос!

А человек выше пишет про баг в хардварном крипто модуле, это не оно же?

Продолжаю эксперименты на тему EoIP. Проблема с SMB. С компьютера за новой ультрой, пытаюсь установить связь до старой ультры с включенным smb. Судя по дампам траффика, сессия устанавливается нормально, пакеты бегут, но когда доходит дело до обмена данными, старая ультра отвечает SMB-пакетом размером 15к с установленным DF и до клиента он не доходит, клиент запрашивает ретрансмиты, старая ультра бьет на пакеты по 1514, но они так же не доходят до цели. Я правильно понимаю, что net.core.eoip_allow_fragment 1 должен такую проблему решать? Но толи лыжи не едут, толи проблема в другом?

Поигрался с mtu, потом вернул все на место, без ребутов, скорость стала 60 мегабит. Мистика какаято) Вообще первая ультра у меня держит в аппаратно ускоренном ipsec'е скорости выше 20 мегабит, поэтому я грешил на mtu или eoip, вон у человека постом выше, скорости пободрее. ~ # iperf -m -c 10.0.0.101 ------------------------------------------------------------ Client connecting to 10.0.0.101, TCP port 5001 TCP window size: 20.7 KByte (default) ------------------------------------------------------------ [ 3] local 10.0.0.1 port 54458 connected with 10.0.0.101 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 71.1 MBytes 59.4 Mbits/sec [ 3] MSS size 1440 bytes (MTU 1500 bytes, ethernet)

Сделал EoIP туннель, между новой ультрой и первой ультрой с ipsec в автоматическом режиме. Забриджевал с home, включил фрагментацию. С одной стороны интернет ipoe, с другой pppoe. mtu на стороне ipoe на всех интерфейсах 1500, на стороне pppoe 1492 (кроме isp, там 1500). Скорость не поднимается выше 20 мегабит в туннеле. Напрямую, через интернет, скорость поднимается до 100 мегабит. Подскажите плз в какую сторону копнуть?

Использовать PPTP небезопасно уже около шести лет: https://technet.microsoft.com/library/security/2743314 Можно митигировать используя PEAP, но лучше перейти на более безопасные протоколы.

Вроде починилось на билайне. И правда, сутки почти были какие-то проблемы.

Потестировал еще, какая-то нестабильная фигня. ip static помогло, но ненадолго. Некоторое время работает, затем пакеты начинают прилетать с адресом внутреннего интерфейса без nat. Заработало так же и при ip nat, сразу после перезагрузки, но через некоторое время отваливается и пакеты начинают опять прилетать с адресом 77.77.77.77, но для 8.8.8.8 прилетают с внешним IP, а пинги на 8.8.4.4 работают и все ок, причем для одного внутреннего хоста так, а для хоста подключающегося к кинетику по l2tp/ipsec все продолжает работать нормально. Похоже на какой-то кеш, который работает не совсем корректно. Вот сейчас, не трогая никаких настроек, опять заработало. Чудеса какие-то)