arbayten

спасибо

Есть немножко твиков, которые можно попробовать потестить на К (настройки для обеих сторон) на предмет прокачки, фрагментации на уровне kernel, cpu. cli> interface OpenVPN0 ip mtu 6000 ovpn config (остальное под себя)> dev tun proto udp tun-mtu 6000 sndbuf 0 rcvbuf 0 fragment 0 mssfix 0 cipher aes-256-cbc comp-lzo no переподнимаем в cli> interface OpenVPN0 down interface OpenVPN0 up *** Потом пробуем поднимать ip mtu и tun-mtu до: 9000, 12000, 24000, 36000, 48000, 60000 -> Помимо выключения внутренней фрагментации, "подстройки" буферов ovpn, принудительного выключения сжатия (чтобы не тратить cpu) - пытаемся скармливать блоку шифрования размер "побольше", аппаратный/софт aes - я ф.з. как там openssl -> потом на выходе с OpenVPN0 с толстяка снимают одежду, нарезают, пакуют на уровне kernel под выходной mtu аплинка. Если поможет поднять перформанс, то было бы интересно узнать ваши бенчмарки, есть ли улучшения и какие, какой потолок на GbE. Для продакшена в сетях где на путях маячит packet-loss иметь ввиду возможные последствия от завышенного mtu толстяка (из серии: при сборке на приемнике будет выкидыш, если хотя бы часть потеряется + нужно держать буфера для вероятных RO очереди, а что тут с ними - ф.з.) -> tcp клиентов решит проблему в конечном итоге, но приложения на udp могут быть под стрессом - это все индивидуально, чем выше задерете, тем сильнее аукнется -> для нормальных/проверенных сетей редкость, так что вероятное улучшение показателей все перевешивает.

человек ведь не один такой, типичные девайсы 1T1R в типичном копировании WLAN<->WLAN в среднем 2.5-3MB/s в типичных ОС, как бы скорость подтверждается WLAN<->USB3 (форс. до 2) на средних 5MB/s (т.е. типичные ситуации, которые на всех форумах типично сглаживают про типичный эфир итп. =) ... можно еще в теории скостить половину кэпа на apcli, но кагбэ 2T2R тут в сценарии для обслуги, т.к. с EDCCA непонятки, т.е. все фонит и шумит одновременно, а 150*0.65 с одной даже близко не тянет ... ну т.е. жопу из коробки достаешь и радуешься, как-то так, сложилось мнение. понятное дело, что я ни в чем не разбираюсь и все это фигня, а в массе население довольно как слоны. при всем уважении.

а потом окажется, что клиент не роутер и надо включить ip форвард, поколдовать фаер

и еще немного: раз pmtud, видимо, включен по-умолчанию (а выключить чем-нибудь можно?) для tcp и udp ... скажем, на первом пристрелочном tcp-хэндшейке можно выяснить mtu хоста из mss и взять минимальный с обоих поинтов, но не pmtu - это пока рогом не упремся ... но чтобы мысль не потерять -> т.е. с платформы ip пакеты выходят с df ... м.б. добавить что-нибудь вроде interface ip clear-df <acl> и ставить set ip df 0, чтобы проблему с меньшим mtu на пути попробовали решать другие железки? (м.б. даже добавлять это в конфиг по-умолчанию при поднятии подобных туннелей "пользователем").

т.е. все как обычно: например, клиент арпит ip получателя броадкастом, броадкаст проходит в т.ч. через туннель, получатель отвечает арпом в юникасте, арп-кэши обоих хостов подсети пополнились соответствующими записями, для них все едино; при стандартном mtu бриджа в 1500 на eoip заходит ethernet-кадр от клиента макс. размером в 1514, при allow fragment он бьется с учетом +8 +20 и pmtud ... на базе icmp с df (?) до другого конца туннеля и потенциальный затык если по пути black hole на блоке icmp ... как-то так? если на базе icmp с df ... то какое время действия pmtu через которое будет повторный icmp? если нет ответа на icmp, то идет дискард или все равно отправляем? если часть пакета потеряли, то дискардим весь пакет оставляя решение за протоколами более высокого уровня? детали важны, чтобы люди понимали, где может быть проблема.

имхо, все же сюда могут зайти в т.ч. адекватные новички (если все это скоро не накроется), которым бы: 1) ip tcp adjust-mss 1300 .. +20 +20 -> 1340 -> т.е. для tcp only будет формироваться ip пакет макс.размером 1340 в отношении которого уже может применяться ip mtu; 2) этот пакет, видимо, завернется в eoip получив еще немного жира: т.к. бридж прозрачен, то без .1q -> добавляем 14 от 802.3 (т.к. eoip знает L2 на другой стороне), 8 от gre и еще 20 от ip (чтобы дойти до другого конца туннеля) .. т.е. набрали вес до 1340+14+8+20 = 1382; 3) и вот новый ip пакет в чистом виде eoip макс.размером 1382 путешествует по сетям и если по пути придется пройти интерфейс с mtu меньше чем 1382, то ... имеет смысл дополнительно обернуть в то, что может решать подобные проблемы; 4) предположим, пакет дошел до нужного конца, дальше по принципу луковицы: сняли верх (20 от ip), на проходной отдали 8 от gre, на L2 отдали 14, все, доехали и тут тоже может быть косяк с mtu на интерфейсе хоста (а дальше снова отдавать 20 и 20 и данные сегмента раскрылись). если это не объяснять, то все бесполезно. п.1 не учитывает пакеты вне tcp. system set net.core.eoip_allow_fragment 1 - видимо фрагментирует и собирает ip пакеты на основе размера mtu интерфейса через который он (eoip) эти пакеты пропинывает.

наверное, да, можно заодно попробовать пойти по путям проще а-ля: https://github.com/fritz-smh/yi-hack в плане препарирования настроек под себя на том что есть на стоке, но закрыто пользователю, т.к. цена и так сладкая. .. а потом зафлэшить lede .. если окончательно не залочат вроде бы информации выше достаточно для этого .. я ф.з. .. ffmpeg есть и под винду x64/x86, взяли камеру, настроили rtsp, играетесь ffmpeg с записью в удобном окружении предварительно изучив все возможности ff*, сошли до платформы на Entware, оценили влияние на перформанс, что еще, создали скрипты на демонизирующий запуск, на убийство процесса, нашли нужные хуки, например, поднятие/падение интерфейса в сторону камеры, навесили, прояснили для себя на всякий случай все моменты с nat и rtsp alg, далее надо решить вопрос со слоем безопасности в топологии, м.б. покопать внутренности rtsp-сервера камеры на предмет поддержки rtsps, если да, то отдебажить при необходимости работу ffmpeg с rtsps .. по идее это минимум (не кандидатский).

конфиг, видимо, выглядит как-то так: https://github.com/jedisct1/pure-ftpd/blob/master/pure-ftpd.conf.in # Port range for passive connections - keep it as broad as possible. # PassivePortRange 30000 50000 общий принцип: помимо 21/tcp на входящих фаера открываете диапазон_портов/tcp (если только это не "умный" фаер, которому "хэлпер" сообщает какой порт открыть при ответе сервера на pasv). если внешняя сеть "враждебна", то как бы оптимальный выбор: FTP with SSL/TLS (AUTH TLS Explicit), большинство клиентов умеют шифровать хотя бы контрольный канал, в идеале шифровать оба, но для этого относительно часто в настройках нужно искать что-то вроде "использовать кэшированную сессию TLS", от сервера тоже зависит (сейчас такая мода с reuse cached session). вот только сток вроде не позволяет подцепить свои сертификаты (по крайней мере удобно), выводы.

м.б. можно попробовать сделать камеру мечты с учетом флэша для прошивки а-ля: https://lede-project.org/toh/hwdata/d-link/d-link_dcs-93x https://wiki.openwrt.org/toh/d-link/dcs-930l и застримить как угодно под пределы железа: https://trac.ffmpeg.org/wiki/StreamingGuide

ну, всегда ведь можно распределить нагрузку, писать то, в чем отдают, формировать очередь, забирать в кластер на пост-обработку, благо, кодеков и форматов немерено ... по x264 пространство для маневра большое в плане качества/размера/требуемых вычислительных мощностей, всегда можно поспрашивать специалистов, готовящих релизы на трекерах, если будут в хорошем настроении - вполне подскажут.

угу, если на стороне камеры делать готовый вывод на том же h.264 для видео .. и какой-нибудь приемлемый для аудио (если есть), то ffmpeg с ключами -c copy -map 0 запишет все потоки с сохранением исходных кодеков в выбранный подходящий контейнер с минимальным напрягом на cpu .. осталось решить какое ПО займется триггерами на запуск/остановку ffmpeg и чтобы можно было при этом удобно систематизировать хранение, сервировать при необходимости лайв/сохраненное для клиентов (без транскодинга, будем реалистами) ... чтобы в конечном итоге сделать из роутера подобие dvr ... и тут, например, умирает носитель из-за каких-то глюков в драйвере usb или в этом роде, самое оно для продакшена), а чтобы этого не было выделяем отдельный бокс, который по расписанию от wol-пакетов просыпается и бэкапит хранилище ... ф.з. ... сама идея имхо только для случая падения аплинка до машины, которая отдельно вылизана под задачи видеонаблюдения.

самый простой подход для записи потока в файл(ы с разбивкой) вроде все же из этой серии: https://gist.github.com/mowings/6960b8058daf44be1b4e вопрос похоже исключительно как лучше минимизировать влияние транскодинга на cpu роутера ... если постараться в raw все равно останутся дисковые операции на потенциально существенных объемах, а какие тут показатели у Entware для USB3?

если бы это было единственным затыком, кому захочется современного ядра и всех интерфейсов вплоть до phyN, тот сможет и повторить ndms при желании: https://lede-project.org/docs/guide-developer/start но смысл был в том, чтобы использовать поиск. и так случайно вышло, что https://lede-project.org/packages/pkgdata/crtmpserver выглядит универсальным по описанию, но в 3x repo нема.

https://lede-project.org/packages/start?dataflt[Description_wiki*~]=rtsp

из простых (при условии, что клиент запросит сток-dns роутера) вариантов - команды cli: 1) ip host (видимо, которую Вам не предлагать); 2) ip dhcp pool update-dns (для ленивых).

вангую что bridge2 нужен ip

чтобы было понятнее, можно попробовать найти различия: https://ip-calculator.ru/#!ip=192.168.234.1/23 https://ip-calculator.ru/#!ip=192.168.235.1/23 1-й роутер: 192.168.234.1, 2-й: 192.168.235.1, подсеть одна: 192.168.234.0/23

для сохранения текущей адресации можно попробовать расширить маску на объединяемых сегментах до /23

как бы смысл eoip в том числе, чтобы использовать в полной мере широковещательный трафик, Вы же, грубо говоря, предлагаете два разных широковещательных домена со всеми вытекающими.

как мин. надо, чтобы диапазоны выдачи не пересекались, иначе можно поймать конфликт ip-адресов; аренду выдаст первый ответивший dhcp, если служба не тормозит, то в большинстве случаев это будет ближайший к клиенту; исходящий фильтр, например, на eoip, - как дело вкуса.

просто было про порт в контексте eoip .. ответ был на опережение про потенциальные затыки на вышестоящих интерфейсах (если это кому-то будет полезно), ну и заодно мало ли кому-нибудь понадобится управлять acl по списку.

если в web-gui нет в выпадающем списке - по аналогии с icmp, то надо протокол ip за номером 47 открыть, видимо, через cli - (config-acl)> permit gre ... если по-другому номер не указать

для 40 MHz при выборе страны US: 3-й, 4-й, 5-й (при channel width 40-above), 9-й, 8-й, 7-й (при channel width 40-below) -> по-умолчанию заявляется channel width 40-below -> т.е. если не уверены, что направление расширения выставится правильно на автомате со стороны прошивки, то: 9-й, 8-й, 7-й.

во-первых, вопрос дублируется и можно все, что хочет пользователь, его святое право (в рамках возможностей железа); во-вторых, на 40 MHz непересекающихся только два: 1+5 и 13+9 (и вторая цифра определяет в какую сторону идет расширение и это надо проверять: а) по настройкам; б) по сканеру, т.к. на К нет никаких гарантий); в-третьих, если применять логику, то оптимальное покрытие спектра, например, при выборе и расчете на профиль US (ch.1-11): 3+7 (задействуются: 1-9), 4+8 (задействуются: 2-10), 5+9 (задействуются: 3-11) и, соответственно, в обратную сторону. как встать, чтобы не толкаться с остальными: сугубо индивидуально -> лучше бы зареквестили статистическое профилирование загруженности воздуха в разрезе времени, каналов, поведения соседских AP -> с формированием оптимальных стратегий по смене активного канала и его расширения (в рамках той же теории игр или адаптацией класса транспортных задач, м.б. кто-нибудь интересное предложит, если студенты тут есть, с таким курсачом (нормально-адекватным) сразу заметят интересные работодатели) - и чтобы этим занимался отдельный модуль, а, пардон, выход на это уже тоже пытались предлагать -> хоть какая-то существенная добавленная стоимость.