1.1, Bocha (??), 14:33, 12/12/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
nuclight, привет и спасибо тебе и Ивану за скрипт. Не хочу показаться невежливым, но может вам помочь перевести фразы на нормальный английский, а то пока читал - рыдал, но это никак не умаляет качества самого скрипта, разумеется.
| |
|
|
3.9, Bocha (??), 07:49, 15/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
Собственно, вам надо три строчки заменить:
- # This script create bridge between two network interfaces
+ # This script creates bridge between two network interfaces
- # only packets with multicast dst mac addr forwarded trouth bridge and (!) not pass to network stack
+ # only packets with multicast destination mac address are forwarded through the bridge and (!) are not passed to network stack
- echo "This create bridge beetwen two IFs for IGMP, and UDP from upstreamIF to downstreamIF1"
+ echo "This will create bridge between two interfaces for IGMP, and UDP from upstreamIF to downstreamIF1"
| |
|
|
1.3, dvg (??), 19:40, 12/12/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
nuclight, ты как обычно нереально крут! Даже мысли не было что это можно реализовать на нетграфе, казалось там все очень сложно.
| |
1.5, 34567 (?), 11:35, 13/12/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Красиво, но, собственно, вопрос - а как быть с подпиской? multicast join пакеты будут уходить с src-адресом в downstream подсети до которой в ПИМ нет маршрута.
| |
|
2.7, Ivan_83 (?), 15:52, 14/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
PIM в деталях не знаю.
У меня ситуация такая: на внешнем интерфейсе ip нет (арп зафильтрован тоже), инет по PPPoE, порт.сек. пропускает через порт только один мак. Поэтому у меня ng_ether на внешнем интерфейсе подставляет свой мак, вместо маков с локалки.
Если требуется чтобы на внешку улетал определённый src-ip то можно подключить ng_patch двумя хуками к ng_bpf и перенаправить пакеты в upstream через него, а в нём по оффсету менять 4 байта=ip-src, и ещё нужно выставить CSUM_IP (и CSUM_UDP?), если сетевуха поддерживает аппаратно их расчёт и/или если на принимающей стороне не проверяется контрольная сумма ip пакетов то всё будет работать и пакеты будут валится провайдеру не только с одного мак адреса но и с одного ip.
В моём случае прову пофик с какого IP летят пакеты, поскольку они могут лететь только на мультикаст адреса, а для мультикаста арп не нужен, там просто 4 байта IP адреса помешаются в старшие 4 байта MAC адреса.
| |
|
3.12, 34567 (?), 12:34, 15/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
Хм... про патч, честно говоря, не думал... Я как-то пробовал нечто подобное когда сидел на корбилайне (мост с бпф), входящий мультикаст с видео проходил нормально, но подписка от плеера не работала, работало только если ручками mtest'ом цепляться к группе с роутера. А потом и пчелайн нешифрованое ТВ вырубил и я прова сменил. С патчем поэкспериментирую, спасибо.
| |
|
2.14, FK (?), 14:05, 15/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
Вот-вот! Если по обе стороны Фри разные подсети, то без изменения IGMP-пакетов не обойтись. Суть igmpproxy, mrouted и проч. в том, что они ловят запросы подписки на внутренней подсети а поймав - подписывают уже роутер (Фрю) у аплинка. А вот приходящий мультикаст уже да, уже можно пробрасывать.
| |
|
3.15, Ivan_83 (?), 19:57, 15/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
Это IP мания от не знания L2 :)
Мультикаст это L2. На какой интерфейс пришёл запрос подписки на тот и начинают лить мультикаст, на принадлежность IP к сетям не смотрит. Те IP адрес клиента в данном случае также "важен/нужен" как хостнейм в локалке.
У меня вообще один физ интерфейс, два влана между которыми я и бриджую мультикаст. Провайдер фильтрует ARP у себя, поэтому нет никакой разницы какой src-ip у меня будет, он не узнает мак куда слать, и не должен знать, а должен слать на мультикаст мак.
Суть mrouted в том, чтобы обеспечить функционал типа igmp snooping либо туннелирование мультикаста на другой такой же роутер но юникастом (там ещё протокол маршрутизации есть, но это когда несколько mrouted между собой общаются). Те mrouted знает где источники мультикаста, и где и какие потребители, и гоняет только нужный трафик через нужные интерфейсы. В случае с двумя интерфейсами принципиальной разницы не будет. Более того, mrouted заставит прописать хотя бы фейковые IP на интерфейсах.
Тут есть примеры:
http://www.netup.tv/ru-RU/configuring-igmp-in-lan-for-managing-multicast-iptv
но клиентские IP там только для отчёту, как хостнейм в логах.
| |
|
4.19, 34567 (?), 22:42, 16/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
Нет уж, сударь, позвольте...
Мультикаст L2 и мультикаст L3 это разные вещи, каждый на своем уровне. Мультикаст ip пакеты маршрутизируются также как и обычные ip unicast (ну почти так же). Они должны проходить сквозь роутеры на 3м уровне и роутеры должны поддерживать таблицы групмемберов. Для этого есть свои протоколы PIM-DM и PIM-SM, аналогично как для уникаста оспф. И также как и с уникастом если в АС нет пути до подсети источника/назначения, то "обратный" трафик не бегает. А роутеры обмениваются информацией только с тем кому доверяют (со своими). (Вы ведь не будите принимать оспф-анонсы c customer-подсетей? Поэтому им приходся ставить или прокси или роутер с НАТом, который прячет домашнюю подсеть. igmproxy для l3 играет роль НАТа если очень уж грубо выразиться. Он ловит игмп джоин на одном интерфейсе и ретранслирует джоин на туже группу со свого дургого интерфейса, со своим адресом источника. "Пропихивание" мультикаста сквозь бридж также не заменяет маршрутизации на 3м уровне как и "пропихивание" сквозь бридж ip-уникаста. Да, сниффером можно будет ловить пакеты соседних подсетей с "той стороны роутера", но с ними нельзя полноценно общаться. Фича мультикаста в том что "снифинга" собственно и достаточно чтобы получать то что тебе нужно от видео-потока.
Ситуция с вашим провом весьма интересна, возможно он просто не маршрутизирует мкаст трафик на 3м уровне и источник потока и подписчики (клиенты) находятся в одном Л2 бродкаст домене.
С пчелайна я ушел - сейчас поэкспериментировать "на живую" не на чем, разве что свою лабу сделать если времечко выйдет.
| |
|
5.20, Ivan_83 (?), 21:29, 18/12/2011 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален На уровне провайдера L3 - излишество Проще мультикаст в... большой текст свёрнут, показать | |
|
|
|
|
1.10, unscrubber (?), 08:27, 15/12/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Авторам решения - спасибо, но с наскоку не получилось (хотя модули есть соответствующие):
у меня на freebsd 7 (PF firewall) при попытке запуска сваливается шелл-процесс с сообщением что не хватило свопа, а свопа в сам деле нет ибо система на flash/ssd в r/o и /tmp+/var на рамдиске (256MB), оперативки достаточно много (1 ГБ, свободно обычно >600 МБ) - в каком направлении копать? На каких версиях freebsd проверялась работоспособность решения (6/7/8)? Насколько понимаю опции сборки ядра вряд-ли важны .. если важны - то хотелось бы знать какие :-)
Заранее спасибо за ответы, позже на 8ке повторю, но хотелось бы и с 7кой разобраться.
| |
|
2.11, Ivan_83 (?), 11:28, 15/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
У меня 8.2 х64, но это не должно иметь значения. Памяти там требуется не много, совсем не во время работы. Возможно проблема с либами которые преобразуют выражения для фильтра с помощью tcpdump в код для bpf.
Попробуйте в консоле: tcpdump -s 65535 -ddd 'ether[0] & 1 = 1 and (ether[0:4] != 0xffffffff or ether[4:2] != 0xffff) and ip[9] = 2'
(это выдало одинаковый код на 8.2 со всеми апдейтами и 7.3 которой года полтора, а на арм железке с 32мб озу, без свопа и флешкой рв получил ошибку 1)
У обоих сильно порезанное от лишнего, нетграф везде модулями, единственное BFP у обоих в ядре, чего вроде в генерике нет.
В качестве решения можно сгенерить этот код на любой машине, и подправить скрипт чтобы не вызывал tcpdump (написать аналогично PASSTROUTH). PASSTROUTH = я руками правил вывод tcpdump -ddd чтобы получить NotMatch всегда.
У меня оно так как есть, потому что ошибок я не словил, и править условия для фильтров было легко, кроме того мост легко переделать под что угодно просто поигравшись с tcpdump фильтрами. К тому же это отличный пример практического использования ng_bpf, с кодами была бы сплошная магия, а так понятно что откуда и для чего.
| |
|
3.23, unscrubber (?), 21:14, 24/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
наконец то удалось найти время для экспериментов
> У меня 8.2 х64, но это не должно иметь значения. Памяти там
> требуется не много, совсем не во время работы. Возможно проблема с
> либами которые преобразуют выражения для фильтра с помощью tcpdump в код
..
> Попробуйте в консоле: tcpdump -s 65535 -ddd 'ether[0] & 1 = 1
> and (ether[0:4] != 0xffffffff or ether[4:2] != 0xffff) and ip[9] =
> 2'
...
запустил в консоли, потом посмотрел вывод, почитал маны, понял что вроде валидный вывод, сделал вспомогательный подскриптик как часть с инициализацией BPFPROG_MCAST_IGMP (я так понимаю по логике это достаточно статичный массив если провайдер не меняет настройки вещания) чтоб не руками набивать, скинул в текстовые файлы. сделал "лениво-отладочную" версию скрипта с жестко прошитыми интерфейсами и выводом по эхо номеров строк скрипта выполненых, вобщем ошибок не было, модифицировал ваш скрипт заменив подпрограмку с использованием вызова tcpdump на bpfprog из файлов в которые заранее сохранял - запустил - и о чудо работает черт подери !!! :D сижу смотрю наконец бридж-тв... мтс на кабельном отрубили его.. пришлось ip-tv подключать
рад очень, странно что исходная версия подвисала, но главно чтотеперь работает, решение изящное, не надо пересобирать после обновлений этот порт igmpproxy ... он коненчо служил верой и правдой мне пару лет но через bpf еще интересней и универсальней получается.
| |
|
4.24, michaeladm (ok), 09:40, 26/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
> unscrubber
> ....
> коненчо служил верой и правдой мне пару лет но через bpf
> еще интересней и универсальней получается.
а можно поподробней
| |
|
5.26, unscrubber (?), 14:22, 28/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
объясняю коряво и быстро (как могу),
при настройке igmp.conf надо знать (например запуская бинарник igmpproxy с ключём -d, помоему я так делал при первой настройке, сам провайдер нифига не говорит обычно о этих деталях - им проще когда абоненты дылинк-коробки покупают, на форумах не факт что свежая инфа найдется) с каких мультикаст сетей/адресов вещает провайдер чтобы вбить их в altnet на upstream интерфейсе в конфиге.. соответственно при изменениях - надо снова как то вычислять и сохранять конфиг,
и вторая половина - настройка файрвола, если эти подсети были в таблицах перечислены то обновлять.
на igmpproxy примерно год работал ip-tv, но потом в виду наличия тв-тюнер карты и взымания платы за ip-tv выключил (был еще отмечен какой то несанкционированный паразитный траффик входящий порядка 5-100КБ/с, даже если во внутренней сети все клиенты поотключались), а когда мне спустя полтора года снова потребовалось задействовать ранее настраивавшийся и успешно работавший igmpproxy (при отключении просто закоментированы были правила в pf.conf igmpproxy_enabled="NO" в rc.conf) - во первых не заработало со старыми настройками (во внутренней сети клиенты не получили потока), во вторых не заработало с новыми настройками и даже с альтнетами 0.0.0.0 не было успеха. Не исключаю что я делал диагностику не правильно, попозже приобщу фрагменты конфигов которые "не взлетели" - там имхо изобретать особо нечего.
Резюме:
плюсы от использования решения с ng_bpf вижу в том что меньше конфигов править при изменениях, и эти модули по идее есть всегда под рукой, и они написаны на высоком "ядерном" уровне качества - не надо ставить дополнительные порты (например igmpproxy или udpxy). Хотя если честно для меня все это так и осталось магией - я еще не осознал саму ng_bpf технику что используется скриптом :)
| |
|
6.29, Ivan_83 (?), 22:01, 29/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Резюме:
> плюсы от использования решения с ng_bpf вижу в том что меньше конфигов
> править при изменениях, и эти модули по идее есть всегда под
> рукой, и они написаны на высоком "ядерном" уровне качества - не
> надо ставить дополнительные порты (например igmpproxy или udpxy). Хотя если честно
> для меня все это так и осталось магией - я еще
> не осознал саму ng_bpf технику что используется скриптом :)
На каждый хук, подключённый к ng_bpf можно назначить программу, результатом которой может быть пересылка пакета на один из двух указанных в программе хуков. Можно пересылать пакет не целиком а обрезать.
upper - это хуки на которых трафик от самой системы/в систему
lower - драйвер сетевухи
Всё что идёт с upper пересылается на lower без раздумий.
Если с lower идёт что то, что подпадает под условия мультикаста, то оно пересылается на lower другой сетевухи, остальное на upper этой же сетевухи.
bpf реализует простенький ассемблер, уровня: загрузить 1/2/4 байт с такого то смещения, сравнить, да - переход на XXX строку, нет - переход на YYY строку. Если возвращается 0 - то не совпало, если больше нуля - то столько бат переслать на хук match.
tcpdump -d "выражение" - прекрасно это иллюстрирует.
Более подробно или у нюклайта (постера новости) в блоге или в исходниках/манах.
| |
|
|
4.25, Ivan_83 (?), 21:05, 26/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
> рад очень, странно что исходная версия подвисала, но главно чтотеперь работает, решение
> изящное, не надо пересобирать после обновлений этот порт igmpproxy ... он
> коненчо служил верой и правдой мне пару лет но через bpf
> еще интересней и универсальней получается.
В вашем случае почему то не хватало памяти для компиляции правил в бпф ассемблер, у меня такой же результат был на арм коробочке с 32 мб озу.
На работе самого нетграфа/бпф это не отражается.
Рад что у вас всё получилось.
| |
4.30, unscrubber (?), 06:20, 30/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
>...и о чудо
> работает черт подери !!! ..
счастье было недолгим, даже при использовании сохраненных в файл паттернов/шаблонов для bpf (PATTERN_MCAST_IGMP и тп) опять при запуске ng_ctl наблюдаю out of swap ошибки, после праздников поразбираюсь.
P.S.
не сразу нашел блог нуклайта о котором Иван пишет - на всякий случай пишу тут ссылочку, http://nuclight.livejournal.com/
| |
|
5.31, unscrubber (?), 09:43, 03/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
> счастье было ...
счастье есть :)
убрал из автостарта скрипт, если руками запускать то работает.
возможно разница в том как я строку-массив (программу для bpf) из файла загружал, в оригинале было PATTERN..= $ ( <some commands> )
я заменил PATTERN..= $ ( cat bpfprog_igmp.txt )
на PATTERN..='cat bpfprog_igmp.txt'
P.S. с переключением каналов все хорошо на компе, хоть с winXP хоть с GNU/Linux
| |
|
|
|
|
1.17, michaeladm (ok), 21:32, 15/12/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Огромное спасибо за реализацию нормального "мультикаст-моста". Но присутствует один глюк причем такой-же как и у igmpproxy, а именно, если в домашней сети смотреть с двух точек (например приставка Dlink DIB-120 и компьютер) один и тот-же канал, а потом, например компьютер, переключается на другой канал, то на приставке на ~100 секунд этот канал повисает (замирает изображение и нет звука). По прошествии 100 секунд на приставке само все начинает работать.
Система FreeBSD 8.2 RELENG_8, ядро и мир обновлялись недавно. Имеется возможность присвоить алиас или несколько алиасов в сторону провайдера (10.100.90.8, 10.100.90.9 и т.д.) если это может помоч в разрешении проблемы.
| |
|
2.18, Ivan_83 (?), 09:36, 16/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
Подозреваю что дело в реализации мультикаста в Dlink DIB-120: после отписки компа должен посылается лив пакет, в ответ приходит запрос на членство в группе, которые приставка походу игнорирует. Через 100 секунд она снова посылает джоин по своему таймеру и начинает получать данные.
Я специально у себя проверял такую же ситуацию ещё на первых рабочих версиях, но у меня 3 компьютера с IPTvPlayer, и взаимного влияния у меня нет.
Мосту вообще нет дела до IP адресов на интерфейсах фряхи.
| |
|
1.21, xrensgory (?), 16:55, 19/12/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Спасибо, добрый человек! Как-раз бьюсь с igmpproxy на FreeBSD и xbox360 в качестве клиента. Вечером буду пробовать
| |
1.22, Piter_Ring (ok), 21:10, 20/12/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Не, мужики, нетграф - это сила !
и те кто им пользуются - так же не слабого десятка :).
В свое время на опеннете была статейка (мож и щас жива) Сага о биллинге. Так вот на ее основе была собрана система биллинга небольшого прова. Жива до сихпор. нетграф-вертушку (как ее назвали) пересилили на сторону "маршрутизаторов" на базе m0n0.ch (в народе моновол). Пришлось немножко пересобрать его образ. Ну а сам биллинг съехал на линукс. При том что трафик снимается чуть ли не каждые пару сек - нагрузка на систему совсем незаметная.
| |
1.27, xrensgory (?), 17:08, 28/12/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
интересно... внимательно поизучал сей скрипт, включил promisc mode на интерфейсе, который смотрит в сторону провайдера и IPTV через igmpproxy таки пошел. Думаю дело не в том, что igmpproxy не работает, а в том что ядро кладет на igmp, пока ему на скажешь
| |
|
2.33, Ivan_83 (?), 14:07, 11/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Ivan_83, на netgraph-интерфейсах (mpd) не должно работать?
ngX - это совсем другие интерфейсы, у них нет ng_ether хуков.
Если вам оч нужно, то придётся переписывать выражение фильтра, чтобы остался только L3, менять все матчи с маков на IP адреса.
Цепляться оно будет в разрыв, между ngX и остальными нодами от mpd.
Но сделать можно.
| |
|
3.34, michaeladm (ok), 14:31, 11/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Ivan_83, на netgraph-интерфейсах (mpd) не должно работать?
> ngX - это совсем другие интерфейсы, у них нет ng_ether хуков.
> Если вам оч нужно, то придётся переписывать выражение фильтра, чтобы остался только
> L3, менять все матчи с маков на IP адреса.
> Цепляться оно будет в разрыв, между ngX и остальными нодами от mpd.
> Но сделать можно.
Кстати, это было-бы очень интересно. Т. к. многие не петрят вообще в ng..., в том числе и я, то может кто накрапает чтото работоспособное.
| |
|
|
1.35, michaeladm (ok), 15:18, 11/01/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
И еще заметил, правдо, может и не важно, но.
При попытке остановить выдаются такие сообщения:
stop bridging beetwen re1 and re0
ngctl: shutdown: No such file or directory
| |
1.36, inox (?), 20:03, 12/01/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Все бы хорошо, скрипт работает, но почему во время его работы вырубается updxy никто не подскажет? То есть запускается он нормально, но не вещает ничего ни на одном канале.
| |
|
2.37, The_Q (?), 22:36, 12/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
А должен? Вы же мультикаст сбриджевали вовнутрь. Там его и ищите.
| |
|
3.38, inox (?), 23:24, 12/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
Так udpxy ж сам умеет подписываться на мультикаст-группы. Просто нужно организовать работу iptv по проводам с помощью данного скрипта и udpxy через вафлю. Udpxy начинает работать только тогда, когда я останавливаю проброс с этого скрипта.
И как тогда искать мультикаст с udpxy внутри? Просто указать мультикастовый интерфейс внутренний (т.е. НА который идет проброс)?
| |
|
4.39, Ivan_83 (?), 15:23, 13/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Так udpxy ж сам умеет подписываться на мультикаст-группы. Просто нужно организовать работу
> iptv по проводам с помощью данного скрипта и udpxy через вафлю.
> Udpxy начинает работать только тогда, когда я останавливаю проброс с этого
> скрипта.
> И как тогда искать мультикаст с udpxy внутри? Просто указать мультикастовый интерфейс
> внутренний (т.е. НА который идет проброс)?
Потому что мультикаст пакеты с внешнего=источника интерфейса не попадают в стёк, а улетают сразу в сеть.
Если вам нужно чтобы оно работало - пересобирайте граф так, чтобы копия пакетов улетала и в сетевой стёк. Вроде right2left ноды подцепленной к интерфейсам и бпф, в качестве прослойки должно хватит.
| |
|
5.40, inox (?), 16:53, 16/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
А можно поподробнее как-нить объяснить? Просто я пока только фрю начал изучать досконально, и таких тонкостей настойки нетграфа к сожалению не знаю...
| |
|
6.41, Ivan_83 (?), 14:06, 17/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
> А можно поподробнее как-нить объяснить? Просто я пока только фрю начал изучать
> досконально, и таких тонкостей настойки нетграфа к сожалению не знаю...
нода ng_ether подключена интерфейсу, у неё есть хуки:
lower - со стороны самой железки, те все полученные пакеты из сети здесь, если сюда что то подключено
upper - это со стороны ядра фри, здесь все пакеты которые вышли из сетевого стёка фри (которые она сама сгенерировала, например ссш, веб сервер и которые идут через неё транзитом в виде маршрутизации (роутинг) или нат)
Если к хукам ничего не подключено, нода ведёт себя так как будто одни соединены - те пакеты из сети прямиком идут в сетевой стёк, а пакеты из сетевого стёка идут в сеть.
Когда мы подключаем бпф, то настраиваем её так, чтобы все пакеты от upper хуков всегда уходили в lower хуки той же ноды.
А пакеты с lower хука попадают в upper хук той же ноды только если они не мультикаст, если же они мультикаст то мы их пересылаем на lower хук другой ноды, и в сетевой стёк они не попадают вообще.
Мультикаст определяется по установленному младшему биту в первом байте адреса назначения ethernet заголовка, так же введены дополнительные провеки: эзернет пакет должен содержать в себе IPv4 пакет, IPv4 должен содержать IGMP либо UPD, юдп мултикаст пересылается только в внешнего интерфейса на внутренний, игмп в обе стороны - там две немного разных программы для bpf.
| |
|
5.42, AlexighTower (?), 18:04, 18/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
Поддерживаю вопрос, может кто из понимающих в нетграфе найдёт пяток минут сделать такие изменения, чтобы мультикаст бриджевался, но и uxpdy работал?
Было бы очень здорово и приятно...
| |
|
|
|
2.44, Ivan_83 (?), 21:10, 01/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Все бы хорошо, скрипт работает, но почему во время его работы вырубается
> updxy никто не подскажет? То есть запускается он нормально, но не
> вещает ничего ни на одном канале.
После долгих раздумий таки придумал как сделать граф чтобы и пакеты ходили ещё в ядро и лишние пакеты не создавались и не уничтожались.
Возьмите обновлённую версию у меня с сайта и запустите добавив ещё один ключ, например так:
mcastbr2.sh start vlan886 vlan777 enable
С этим ключём он будет также и в ядро слать траффик, как было бы без моста.
| |
|
1.43, michaeladm (ok), 18:08, 27/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
...и еще один глупый вопрос. А чем может грозить promisc режим сетевых карт? Это может влиять както на безопасность или производительность сетевых карт?
| |
|
2.45, Ivan_83 (?), 21:16, 01/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> ...и еще один глупый вопрос. А чем может грозить promisc режим сетевых
> карт? Это может влиять както на безопасность или производительность сетевых карт?
Если свич тупой/игмп снупинг не включён то мультикаст будет лететь во все порты такого свича, а поскольку адаптер в промиске то он будет их принимать и они будут дропаться уже где то в ядре фри.
Если бы промиск был выключен то сетевой адаптер сам бы их подропал или аппаратно или гдето внутри драйвера.
По сути промиск это отключения фильтра в сетевом адаптере. Этот фильтр пропускает только пакеты у которых DST MAC в белом списке адаптера. Список этот обычно не большой (4 - 32 записи), и при подписке на множество мультикаст групп адаптер либо переключится в промиск либо подписка закончится не удачей / трафик не пойдёт в ядро.
| |
|
1.46, michaeladm (ok), 14:16, 18/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Для создания аналогичного по функционалу моста, в котором будет несколько
сетевых интерфейсов...
Ктонибудь уже сделал? подскажите пожалуйста.
Ничего не получается сделать на два интерфейса (две подсети дома) re1 и wlan0.
| |
|
2.47, Ivan_83 (?), 21:28, 18/03/2012 [^] [^^] [^^^] [ответить] | +/– | В обновлённой версии добавлен ещё один параметр, включающий форвад мультикста в ... большой текст свёрнут, показать | |
|
3.48, michaeladm (ok), 12:40, 19/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> + ngctl msg ${BR_NAME}-bpf: setprogram { thisHook=\"${IF_DOWNSTREAM1}-lower\" ifMatch=\"${IF_DOWNSTREAM1}-h0\" ifNotMatch=\"${IF_DOWNSTREAM1}-upper\" ${BPFPROG_MCAST_IGMP} }
> + ngctl msg ${BR_NAME}-bpf: setprogram { thisHook=\"${IF_DOWNSTREAM1}-h1\" ifMatch=\"\" ifNotMatch=\"${IF_DOWNSTREAM1}-upper\" ${BPFPROG_PASSTROUTH} }
> + ngctl msg ${BR_NAME}-bpf: setprogram { thisHook=\"${IF_DOWNSTREAM1}-h2\" ifMatch=\"\" ifNotMatch=\"${IF_UPSTREAM}-lower\" ${BPFPROG_PASSTROUTH} }
на этих коммандах ругается:
ngctl: send msg: No such file or directory
ngctl: send msg: No such file or directory
ngctl: send msg: No such file or directory
...похоже, что чегото не хватает
| |
|
|
1.49, lexx (??), 06:04, 20/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
помогите !! как к этому скрипту прикрутить такой тунель... что бы отправить iptv в другую сетку
ngctl mkpeer switch: ksocket link3 inet/dgram/udp
ngctl name switch:link3 switch_socket
ngctl msg switch_socket: bind inet/${self}:${port}
ngctl msg switch_socket: connect inet/${peer}:${port}
| |
|
2.50, Ivan_83 (?), 00:28, 25/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> помогите !! как к этому скрипту прикрутить такой тунель... что бы отправить
> iptv в другую сетку
> ngctl mkpeer switch: ksocket link3 inet/dgram/udp
> ngctl name switch:link3 switch_socket
> ngctl msg switch_socket: bind inet/${self}:${port}
> ngctl msg switch_socket: connect inet/${peer}:${port}
Вместо lower хука одного из интерфейсов подключается юдп сокет (см пример с туннелирование эзернета в юдп, в гугле).
Я так себе с работы мультикаст забирал.
| |
|
1.51, aydnep (?), 12:49, 09/11/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
помогите плз как заменить src-ip а то моему провайдеру не все равно какой src-ip посылает запрос
| |
1.52, Imhoil (ok), 22:00, 10/04/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Странно, имею от провайдера 2 физических подключения.
em1 - интернет + IPTV (100мбит)
em2 - только IPTV (100мбит)
em0 - локальный интерфейс
vlan101 - vlan для IPTV (vlandev em0)
Так как на домашний свич заведен гигабит, захотелось немножко сбалансировать нагрузку. То есть, скриптом вешаю мост с em2 на vlan101. Но при нагрузке на em1 более 70 мбит (качаю популярный торрент), получаю тормоза при просмотре IPTV и сообщения в лог такого типа:
kernel: Limiting closed port RST response from 469 to 200 packets/sec
kernel: Limiting open port RST response from 524 to 200 packets/sec
atop кажет такое
NET | em1 98% | pcki 9051 | pcko 5993 | si 98 Mbps | so 9591 Kbps
NET | em2 10% | pcki 932 | pcko 0 | si 10 Mbps | so 0 Kbps
NET | em0 1% | pcki 5 | pcko 922 | si 9 Kbps | so 10 Mbps
NET | vlan101 0% | pcki 3 | pcko 920 | si 9 Kbps | so 9994 Kbps
| |
|