zep

Знаю, что есть модули HLS, RTMP для NGINX .... жаль Как я понял в принципе можно это реализовать собственным демоном, подключаться к источнику, читать в кольцевой буфер и отдавать из него клиентам!? Ковыряю Astra

Всем привет! Пытаюсь превратить NGINX в рэлей для источника IPTV HTTP (UDPXY). В данный момент NGINX работает как сквозной прокси без буфера. Количество HTTP соединений к NGINX равна количеству соединений UDPXY соответственно. Хотелось бы увидеть NGINX в качестве Relay - одно соединение от UDPXY к NGINX, множество соединений от NGINX к клиентам... Спасибо!

Сделал. Не работает. Все так же трафик не проходит FORWARD # iptables -nvxL Chain FORWARD (policy DROP 5 packets, 240 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo * 0.0.0.0/0 127.0.0.1 0 0 ACCEPT all -- * lo 127.0.0.1 0.0.0.0/0 6 288 ISG all -- * eth0 0.0.0.0/0 0.0.0.0/0 ISG initiator src mode 0 0 ISG all -- eth0 * 0.0.0.0/0 0.0.0.0/0 ISG # ./ISGd.pl Refreshing traffic classification table 3 prefixes loaded to TC table ISG job initialization done for NAS '91.91.91.91', entering main loop Session '172.16.3.2' on 'Virtual1' accepted by '127.0.0.1:1812' Session '172.16.3.2' on 'Virtual1' finished Session '172.16.3.2' on 'Virtual1' accepted by '127.0.0.1:1812' Session '172.16.3.2' on 'Virtual1' finished Session '172.16.3.2' on 'Virtual1' accepted by '127.0.0.1:1812' # /scripts/isg/ISG.pl User IP-address NAT IP-address Port number Uniq. Identifier Durat. Octets-in Octets-out Rate-in Rate-out Service name Flags 172.16.3.2 0.0.0.0 Virtual1 1392AAAC5D90B3AC 48 720 0 0 0 Main session A

Убрал все сервисы. Все-равно не работает. # /scripts/isg/ISG.pl User IP-address NAT IP-address Port number Uniq. Identifier Durat. Octets-in Octets-out Rate-in Rate-out Service name Flags 172.16.3.2 0.0.0.0 Virtual1 7A6A6D1769E61063 65 912 0 0 0 Main session A # /scripts/isg/ISG.pl show_services Virtual1 User IP-address NAT IP-address Port number Uniq. Identifier Durat. Octets-in Octets-out Rate-in Rate-out Service name Flags 91.91.91.91 - это завуалированный адрес самого ISG (у него два интерфейса eth0 - 91.91.91.91 и eth1 - 172.16.3.1). С ним все в порядке. Если в iptables перед FORWARD -j ISG написать FORWARD -j ACCEPT трафик побежит. Порча я понимаю в модуле адра. Как его отладить?

Трафик теряется в цепочке FORWARD -j ISG. Возможно проблемы в работе модуля ядра. # lsmod | grep ISG ipt_ISG 12060 4 x_tables 12845 6 ipt_MASQUERADE,xt_tcpudp,xt_state,iptable_nat,ipt_ISG,ip_tables Пока не понимаю как отладить

# /scripts/isg/ISG.pl show_services Virtual1 User IP-address NAT IP-address Port number Uniq. Identifier Durat. Octets-in Octets-out Rate-in Rate-out Service name Flags 172.16.3.2 0.0.0.0 Virtual1 EC54FDE7964EFAEE 33 576 0 512000 512000 6mbit SOU

Все препроверил.. Трафик в цепочке FORWARD (от клиента в сторону внешней сети) попадает в ISG, но не проходит её. iptables -nvxL Chain FORWARD (policy DROP 71 packets, 3408 bytes) pkts bytes target prot opt in out source destination 137 7416 ISG all -- * * 172.16.3.0/24 0.0.0.0/0 ISG initiator src mode 0 0 ISG all -- * * 0.0.0.0/0 172.16.3.0/24 ISG initiator dst mode

Я сейчас разобьюсь об скалы! Скажите, почему ISG.pl показывает Service Name всегда Main session ??? Пакет master 880b4a7

Всем привет! Успановил пакет на тестовую машину. Все хорошо, сессия поднимается через радиус, появляется в статистике, трафик попадает в FORWARD -j ISG, но там же и остается: OS - Debian 172.16.3.2 - тестовый клиент (весит на интерфейсе eth1) #/scripts/isg/ISGd.pl Session '172.16.3.2' on 'Virtual1' accepted by '127.0.0.1:1812' Service '6mbit' for '172.16.3.2' started #/scripts/isg/ISG.pl User IP-address NAT IP-address Port number Uniq. Identifier Durat. Octets-in Octets-out Rate-in Rate-out Service name Flags 172.16.3.2 0.0.0.0 Virtual1 27622A79D24BE5EB 114 213 0 0 0 Main session A iptables (v1.4.8) *nat -A POSTROUTING -s 172.16.3.0/24 -o eth0 -j SNAT --to-source 91.91.91.91 *filter -A FORWARD -s 172.16.3.0/24 -j ISG --session-init --init-mode src -A FORWARD -d 172.16.3.0/24 -j ISG + echo 1 > /proc/sys/net/ipv4/ip_forward + sysctl net.core.rmem_max=4194304 config.pl $cfg{'srv'}{'6mbit'}{'rate_info'} = "QD;512000;96000;U;512000;96000"; $cfg{'srv'}{'6mbit'}{'traffic_classes'} = [ "OUR_NET", "ALL_OTHER" ]; radius request - reply: # radtest 172.16.3.2 172.16.3.2 127.0.0.1 1 test321 Sending Access-Request of id 17 to 127.0.0.1 port 1812 User-Name = "172.16.3.2" User-Password = "172.16.3.2" NAS-IP-Address = 91.91.91.91 NAS-Port = 1 rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=17, length=58 Cisco-Account-Info = "A6mbit" Class = 0x757365725f69645f3331 Idle-Timeout = 1800 Session-Timeout = 120 Если в iptables прописать -A FORWARD -j ACCEPT , трафик натится и бежит в глобальную сеть. Почему ISG.pl всегда показывает Service Name - Main session ? Флаг сессии всегда только "A" или "X" , почему? А не проще запретить все, а разрешить только где REQUEST_URL ~ ВАШ_URL_ХОСТА_ДАЙ_ДЕНЕГ ?

нет. там все ок. Вообще идея с этой программой хорошая, но стиль написания непредсказуемый. Наверно буду переписывать. П.С. Не в обиду разработчику

Винда XP Prof SP3 не хочет просить адреса DNS (отдавал дпже принудительно, см. ниже) ... Хотя в связке с Dlink DIR-615 все впорядке. мистика.

Зачем гадать. Надо считать. П.С. Если вы дадите клиенту в частном доме гарантированую скорость по кабелю, например свыше 1 Мбит, то он врядле перепрыгнет к другому оператору на беспроводку.

Deac может в России да, но в Украине не слышал такого

Повторюсь из соседнего топика: Как насчет HCNA - http://www.rus.dynamix.ua/prod/hpna/3-1/Dynamix-HP-51M.htm ?

Deac далеко на нем не уедешь Чуть не забыл: на вайфай лицензия РЧ ресурса нужна + длительные сроки сдачи БС, правда в случае с кабелем прийдется наверно платить аренду совмесного подвеса на опорах.

sheih как видите - еще как жив. Основные вопросы, которые возникают при построении сети - целесообразность услуги, стоимость подключения клиента, затраты на обслуживание, перспектива маштабируемости и внедрения услуг..... и наконец рентабельность. В данном случае удовлетворяет множеству требований. Поэтому должно быть все-равно, насколько коаксиальный кабель консервативен по отношению к нашему времени.

Как насчет HCNA - http://www.rus.dynamix.ua/prod/hpna/3-1/Dynamix-HP-51M.htm Вроде масштабируемость неплохая, со скоростью замечательно, стоимость низкая, проверено местными КТВшниками по существующей коаксиальной сети в многоэтажках (волокно в здание, потом HCNA в квартиру). Тяните кокс, ставьте заранее ответвители через промежутки. Хочу сам попробовать в котеджном поселке, руки чешутся.

Видел в продаже готовые миниатюрные решения DC-DC инвертора с входом 12-48v и выходом 5v, размером меньше спичечного коробка, ток на выходе около 1-1.5А. У нас КТВшники ставят по питанию конверторов. Если вам очен-очень сильно надо, я могу проезжая мимо радиорынка, узнать у продавца модель устройства.

Инет через PPP ?

Надоело повторять: жалобы на неправильную фрагментацию будут, тогда, когда МТУ будет несогласовано сторонами. Вы наверно не понимаете о чем говорите и поэтому решаете проблему костылем clamp-mss-to-pmtu.

Специально для Вас: Пока стояло наявно указано MTU на BRASe, были рассогласования с абонентскими устройствами. Сейчас все отлично, никаких MTU 1500. Даже не переубеждайте. Проверено временем. И кстати, MTU 1500 на PPP - это скорее всего результаты эксперементов пользователя, всякие тюнеры сетевого стека. П.С. Проверил clamp-mss-to-pmtu - мне тоже показалось, что скорость стала еще хуже, особенно в торентах

Проблема нашлась имеено в Win XP. Поставил драйвер PPPoE стороннего производителя ( http://www.raspppoe.com ) И... Торрент, флешевые тесты ожили! Пошел проверил работу на штатном PPP адаптере в Win 7, плясок с бубном непотребовалось. Тест флешем и торентом показал такой-же замечательный результат. Вообщем - привет мелкомягким. Всем спасибо за внимание! 2 Ivan Rostovikov: Устанавливать жестко MTU на BRASe я бы все-таки не стал на вашем месте. Будут жалобы в духе - Mail.ru не открывается и т.д.

Стояло. Куча проблем. Во многих абонентских устройствах MTU выставлено по-умолчанию не в автоматическом режиме. Начинает "плавится" телефон у тех. поддержки.

Всем привет! Столкнулся с проблемой и не могу найти решения. Есть PPPoE (ядерный rp-pppoe.so) BRAS на базе Linux Debian. На нем крутится NAT и шейпинг. 1) При подключение с Win XP клиента (ДАЖЕ без шейпинга интерфейса, без ната) скорость передачи данных к клиенту не поднимается выше 30-50Мбит, соединение между ними 100base-T. Измерения скорости проводились торентами и флешевыми тестами. 2) При подключении того-же Win XP клиента через роутер (D-Link DIR-615) + оконечивание PPPoE на этом же роутере, проблема счезает. Даже флешевые тесты показывают скорость в обе стороны приближенную к канальной ~ 97 Мбит/сек. 3) При подключении Linux клиента к BRAS через PPPoE - проблема исчезает, скорость максимально возможная. В настройках сервера PPPoE, параметр MTU установлен в автоматическом режиме. Полез смотреть в сторону TCP MSS. Запустил tcpdump на вэб-сервере и зашел на страницу: При подключении из Win XP - MTU на обеих сторонах 1480, рассогласований нет: 13:50:00.195943 IP CLIENT_IP.3536 > WEB_SERV_IP.www: S 1746232114:1746232114(0) win 65535 <mss 1440,nop,wscale 2,nop,nop,sackOK> 13:50:00.195981 IP WEB_SERV_IP.www > CLIENT_IP.3536: S 4040982219:4040982219(0) ack 1746232115 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 7> 13:50:00.207458 IP CLIENT_IP.3536 > WEB_SERV_IP.www: . ack 1 win 65340 13:50:00.207664 IP CLIENT_IP.3536 > WEB_SERV_IP.www: P 1:458(457) ack 1 win 65340 13:50:00.207695 IP WEB_SERV_IP.www > CLIENT_IP.3536: . ack 458 win 54 13:50:00.233633 IP WEB_SERV_IP.www > CLIENT_IP.3536: P 1:492(491) ack 458 win 54 13:50:00.233698 IP WEB_SERV_IP.www > CLIENT_IP.3536: F 492:492(0) ack 458 win 54 13:50:00.238783 IP CLIENT_IP.3536 > WEB_SERV_IP.www: . ack 493 win 65217 13:50:00.239080 IP CLIENT_IP.3536 > WEB_SERV_IP.www: F 458:458(0) ack 493 win 65217 13:50:00.239096 IP WEB_SERV_IP.www > CLIENT_IP.3536: . ack 459 win 54 При подключении Win XP через DIR-615 - MTU на обеих сторонах 1492, рассогласований нет. 13:58:45.950662 IP CLIENT_IP.3048 > WEB_SERV_IP.www: S 3816467849:3816467849(0) win 65535 <mss 1452,nop,wscale 3,nop,nop,timestamp 0 0,nop,nop,sackOK> 13:58:45.950695 IP WEB_SERV_IP.www > CLIENT_IP.3048: S 3692826051:3692826051(0) ack 3816467850 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 7> 13:58:45.951712 IP CLIENT_IP.3048 > WEB_SERV_IP.www: . ack 1 win 32768 13:58:45.952016 IP CLIENT_IP.3048 > WEB_SERV_IP.www: P 1:274(273) ack 1 win 32768 13:58:45.952043 IP WEB_SERV_IP.www > CLIENT_IP.3048: . ack 274 win 54 13:58:45.953054 IP WEB_SERV_IP.www > CLIENT_IP.3048: P 1:1395(1394) ack 274 win 54 13:58:45.953127 IP WEB_SERV_IP.www > CLIENT_IP.3048: F 1395:1395(0) ack 274 win 54 13:58:45.954486 IP CLIENT_IP.3048 > WEB_SERV_IP.www: . ack 1396 win 32593 13:58:45.958107 IP CLIENT_IP.3048 > WEB_SERV_IP.www: F 274:274(0) ack 1396 win 32593 13:58:45.958122 IP WEB_SERV_IP.www > CLIENT_IP.3048: . ack 275 win 54 Немного теории: Параметр MTU (Maximum Transmit Unit) отвечает за максимальный размер передаваемого пакета. Если размер пакета будет больше, чем может пропустить маршрутизатор, то он будет разделен, что сразу скажется на скорости и пропускной способности. Если параметр не указать принудительно, значение будет выставлено автоматически и, увы, не всегда рационально. Рассчитывать его следует так. Максимальный размер фрейма Ethernet – 1518 байт, из них 14 – заголовок и 4 – контроль (то есть полезная нагрузка равна 1500 байт). Далее PPPoE отбирает еще 6 байт, а PPP – 2. В итоге значение MTU для PPPoE должно составлять не более 1492. При установлении TCP соединения каждая сторона выставляет параметр Maximum Segment Size (MSS), определяющий максимальный размер TCP сегмента на всем пути. По умолчанию его значение берется, как MTU для исходящего интерфейса минус размер заголовков TCP и IP (40). Исходя из этого, максимальное значение MSS для Ethernet будет равняться 1460, а для PPPoE – 1452. Вопрос по результатам: Почему MSS ack не равен MSS syn ? Хотя в случае через роутер по идее тоже должны быть проблемы, но их нет.... В чем может быть проблема? П.С. Пробовал выставить на BRASe "iptables -A FORWARD -i ppp{NUM} -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1430" но это не изменило значений

ТСР понятно. А вот UDP как??