iptv igmp multicast
Пошли слухи, что провайдер предоставляет iptv. Слил плейлист, а там адреса вида: udp://@234.5.2.1:20000, udp://@234.5.2.2:20000 и т.д.
Если подключить напрямую к winxp, то vlc кажет тв.
Хочется раздать это дело через самосборный роутер на домашнюю сеть. Поставил igmpproxy.
Провайдер на eth0 c сетью 192.168.1.0/24. Интернет через pppoe — ppp0 и там статический ip. Домашняя сеть eth1 с 10.0.0.0/24.
iptraf при прослушивании eth1 говорит следующее:
Что мне стоит попробовать или сделать, чтобы заработало?
FreeBSD 8.0 поддерживает мультироутинг «из коробки». IP-TV завёл без проблем, ничего никуда не прописывая, разрешив IGMP-трафик в PF.
Как здорово! Но очень не хочется только из-за iptv ставить freebsd.
Странно, но на роутере вообще не получается получить доступ к iptv. Ни через mplayer, ни через vlc. Выходит, что проблема скорее всего не в igmpproxy.
FreeBSD 8.0 поддерживает мультироутинг «из коробки». IP-TV завёл без проблем, ничего никуда не прописывая, разрешив IGMP-трафик в PF.
А еще FreeBSD 8.0 падает на роутинге да. С большим количеством маршрутов.
ПоGoogle на тему параметров ipv4:
rp_filter
force_igmp_version
У меня vlc стал показывать, когда я установил параметр
force_igmp_version=2
echo «2» > /proc/sys/net/ipv4/conf/default/force_igmp_version
либо на конкретном интерфейсе
echo «2» > /proc/sys/net/ipv4/conf/eth0/force_igmp_version
Возможно в твоем случае дополнительно прийдется установить
rp_filter=0
Но ни mplayer, ни vlc не работают.
ТС, загляни в соседний трэд, там вроде советы и тебе подходят.
@sda00 Благодарю, но ничего не помогло =(
mrouted тоже не запустился.
ничего не могу понять. вроде запросы идут. если при поднятом igmpproxy:
но телевидения нет =(
помни, что твой роутинг может управлять только исходищими пакетами. потом настрой простой конфиг igmpproxy:
Не знаю, что там внутри (исходники не смотрел), но репортаж о первом полёте ПАКФА записал именно с IP TV на FreeBSD:
http://izen.dev.juga.ru/image/vlc-iptv-record-T-50.jpg
Не знаю, что там внутри (исходники не смотрел), но репортаж о первом полёте ПАКФА записал именно с IP TV на FreeBSD
Не работает multicast linux после авторизации pppoe
PPPoe, multicast IPTV и роутинг.
Нужна помощь в найтройке роутинга, чтобы multicast IPTV работал совместно с PPPoe.
Вот что происходит:
ip r add default dev eth0 — IPTV работает.
ip r add default dev ppp0 — IPTV не работает.
В обоих случаах: ip route get 233.7.70.2
multicast 233.7.70.2 via 10.24.238.31 dev eth0 src 10.24.238.37 cache mtu 1500 advmss 1460 hoplimit 64
Объясните пожалуйста чего не хватает? И что мне нужно прописать, чтобы заработало?
Добавь маршрут для мультикаста и будет тебе счастье 🙂
> Добавь маршрут для мультикаста и будет тебе счастье 🙂
Не, не будет. Эту очевидную штуку сзделал первым делом. О чем и говорит вот это:
multicast 233.7.70.2 via 10.24.238.31 dev eth0 src 10.24.238.37
Не знаю. К вартире подходит кабель.
Ну правильно, что ты хотел для мультикаста не нужен шлюз. а тут
multicast 233.7.70.2 via 10.24.238.31 dev eth0 src 10.24.238.37
показано что ты его указал
удаляй все маршруты для мультикаста и забивай правильно
ip route del 224.0.0.0/4
ip route add 224.0.0.0/4 dev eth0
поле этого у тебя должно быть
ip route get 233.7.70.2
multicast 233.7.70.2 dev eth0 src 10.24.238.37
> ip route del 224.0.0.0/4
Всё равно не работает. 🙁
Советую осилить udpxy. Мультикаст лучше завернуть в tcp.
с udpxy работает только если dev eth0 как default. Ели ppp0 — не работает.
Ну раз так, попробуй поиграться с метриками
ip route add default via 10.24.238.31 dev eth0 metric 1
А вообще очень мало информации нужен вывод
ip route до и после запуска pppoe
> с udpxy работает только если dev eth0 как default. Ели ppp0 — не работает.
udpxy пофигу, какие там маршруты прописаны. Если в указанном ему интерфейсе есть мультикаст, он его забирает. Выглядит так:
192.168.1.2 — IP интерфейса, на котором сидит мультикаст. В твоем случае это некий локальный IP, который скорее всего надо прописывать руками. Какой именно — зависит от конкретного провайдера. В моем случае это алиас на WAN, смотрящий в DSL-модем, который в свою очередь имеет адрес 192.168.1.1. PPPoE при этом поднимается там же, где и udpxy, модем играет роль бриджа.
172.16.111.1 — адрес интерфейса, на котором поднимается udpxy, то есть внутренний адрес роутера.
82 — порт, на котором поднимается udpxy
Стоит помнить, что адреса каналов будут выглядеть примерно так:
unixforum.org
Форум для пользователей UNIX-подобных систем
Решено: Соединение pppoe не работает. (Соединение с Интернетом через ADSL-модем (PPPoE). )
Решено: Соединение pppoe не работает.
Сообщение ppavel » 25.09.2008 23:12
Я новичек в Debian, до этого стояла ALT Linux, вот решил пересесть на Debian. Для начала нужно настроить соединение с Интернетом, но что-то у меня не выходит.
Интернет у меня через ADSL подключается, т.е. через pppoe, установил пакеты pppoe и pppoeconf, запустил
Ответил на все вопросы «Да», ввел логин и пароль, все вроде бы успешно, но доступа к Интернету нет. Уже и выключал-включал соединение несколько раз (pon dsl-provider и poff), и перезагружался, но работать не хочет.
Debian 4.0r0.
Скажите, текст каких файлов и комманд выложить, а то я не знаю что нужно.
Еще скажите пожалуйста, как на этом форуме сделать, что бы все сообщения отображались друг за другом, а то у меня почему-то в виде «дерева» отображается, нужно щелкать по ссылкам все время, что бы прочитать сообщения.
Re: Решено: Соединение pppoe не работает.
Сообщение Aectann » 25.09.2008 23:20
web-страницы не открываются или что? Пробовали выполнять ping до каких-нибудь внешних серверов? Что в /etc/resolv.conf (после попытки поднятия соединения)?
Net-Labs.in
Network, ISP
Маршрутизация multicast в Linux
В современных реалиях, скорее всего, нет смысла заниматься маршрутизацией(репликацией) multicast-трафика с помощью софтроутеров(будь то ядро Linux или что-то иное). Причина довольно простая – даже дешёвые свитчи умеют L2/L3-multicast(хоть и с ограничениями по количеству групп/маршрутов, но всё же это делается в asic-ах). Однако, существует ряд задач, которые могут быть не решены в “железе” (нет поддержки со стороны ПО/невозможно реализовать ввиду возможностей asic), например ренамберинг(изменение destination ip), внесение случайных задержек(перемешивание), отправка multicast в тунель, резервирование источника по произвольному критерию.
Зачем может потребоваться ренамберинг мультикаст группы? Во-первых, маппинг IP-mac неодназначен(например, группам 238.1.1.1 и 239.1.1.1 соответствует один и тот же mac-адрес), что может вызвать проблемы в L2-сегменте. Конечно, такая коллизия маловероятна, однако возможна, когда вы берёте multicast из разных внешних источников(в принципе, IP-адреса могут даже полностью совпасть). Во-вторых, вы можете захотеть скрыть свой источник, изменив и destination и source адрес. В destination может быть “спрятан” номер AS источника(RFC3180), по source тоже можно догадаться об источнике, если он не серый. В третьих, перенумеровать группу может потребоваться для избежания коллизии на оборудовании, где заканчивается TCAM под multicast (как временное решение до замены оборудования/изменения схемы сети). И наконец, вы решили зарезервировать ТВ-каналы путём их получения из разных источников(т.е. вливать на сервер 2 разных группы(но одинаковых по контенту) и забирать из него одну, результирующую(работающую))
Внести случайную задержку(reordering) или потери может потребоваться для проверки поведения используемых STB/soft-плееров. Например, вам интересно, как будет выглядеть картинка, если где-то на сети мультикаст пройдёт через per-packet балансировку и не зависнет ли плеер при наличии потери пакетов, будут ли издаваться неприятные скрипящие звуки или же просто квадратики и тишина.
При написании этой заметки использовался Ubuntu Linux 14.04 LTS (ядро 3.13.0-24-generic), но применимо для большинства современных дистрибутивов, однако необходимо проверить поддержку IPv4 multicast в ядре:
В отличии от unicast роутинга, утилиты ip недостаточно даже для статической (S, G) маршрутизации, не говоря уже про динамическую. Для формирования таблицы мультикаст-репликации требуются “сторонние” userspace-утилиты. Например, для статических маршрутов это smcroute, для построения таблицы по igmp-запросам с даунлинк-интерфейсов – igmpproxy(маршрут добавляется в ядро тогда, когда “снизу” приходит igmp-запрос), для работы с PIM-SM сигнализацией – pimd(требуется поддержка PIMSM_V2 со стороны ядра).
Статическая маршрутизация multicast
Рассмотрим следующую задачу: осуществить репликацию мультикаст-трафика (*, 233.251.240.1) с интерфейса eth1 на интерфейсы eth2 и eth3, при этом на eth1 эта группа приходит только по igmpv2-запросу.
Конфигурация интерфейсов выглядет следующим образом:
К сожаленью, smcroute в ubuntu 14.04 не поддерживает (*, G)-форму, поэтому придётся скомпилировать из исходников:
Прежде чем запускать маршрутизацию(инсталлировать маршруты в ядро), нужно отключить RPF на интерфейсе eth1(поскольку по условию задачи считаем, что source ip multicast-группы может быть произвольным):
Кроме того, устанавливаем явным образом режим работы igmp на интерфейсе eth1:
Теперь переходим к конфигурации smcroute(/etc/smcroute.conf):
(необходим перевод строки в конце конфигурации)
Первая строчка – подключить группу по протоколу igmp(залить эту информацию в ядро), вторая – собственно мультикаст-маршрут.
Запускаем smcroute:
(логи пишутся в syslog)
Проверяем таблицу igmp:
Всё верно, 01F0FBE9 это наша группа 233.251.240.1.
До того, как в eth1 польётся мультикаст, таблица маршрутизации в ядре будет выглядеть таким образом:
Затем примет такой вид:
Проверяем работу репликации:
Ренамберинг мультикаст групп
Для того, чтобы изменить IP multicast группы используем DNAT. Например, мы хотим изменить 233.251.240.1 на 233.251.250.5:
/etc/smcroute.conf будет выглядеть следующим образом:
(в маршруте фигурирует новый адрес по причине того, что DNAT делается в PREROUTING-е)
Как нетрудно догадаться, чтобы подменить ещё и source ip, будем использовать SNAT:
Прочее
С помощью iptables и tc можно ещё что-нибудь сделать с трафиком(внести задержки и потери, например). При желании, можно организовать резервирование ТВ-канала путём переключения источника вещания с помощью скриптов(smcroute-ом можно управлять “извне”), придумав произвольные критерии выбора лучшего источника(подобные решения для операторов существуют и стоят больших денег)
Не работает интернет, но есть соединение по локальной сети
Всем доброго дня! Не пинайте сильно, в линуксе я полный новичек, но добросовестно весь вечер гуглил свою проблему и ничего не нагуглил 🙁 Суть проблемы такова: в линуксе настраиваю сетевое соединение (что вручную, что DHCP — все одна беда). Пробую пинговать компьютеры в локальной сети и внутрений интерфейс роутера — все отлично пингуется. Но интернета нет. Пробую «ping http://www.google.com», он находит IP гугла по имени (т.е. проблема не в DNS), но пинг не проходит. Сразу после попытки пингануть гугл смотрю лог на роутере — там появляется строчка вида „Dropped packet from 0.0.0.0 to X.X.X.X (IP protocol 1) as unable to create new session“, где X.X.X.X — IP гугла. С виндовыми клиентами (что по проводу, что по WiFi), и с андроидами подобных проблем с роутером не было. Роутер перегружать пробовал. Эта же проблема с различными сборками линукса, и как с виртуальными машинами, так и с живыми компьютерами.
http://www.google.com не существует, он давно на https. И команда ping пинется проще:
Это сути дела не меняет — на виндовой машине тот же гугль нормально пингуется, а на линуксах — нет.
ping в Linux не умеет редирект с http на https. Пробуй
Попробовал и ping google.com — не пашет. И тупо в браузере попробовал открыть google.com, не работает, та же ошибка в роутере при попытке открыть из браузера: «Dropped packet from 0.0.0.0 to 64.233.164.100 (IP protocol 6) as unable to create new session», где 64.233.164.100 — гугль. В то же время веб-интерфейс роутера без проблем открывается в браузере.
Dropped packet from 0.0.0.0 to 64.233.164.100
Стоп. А какого хрена у тебя IP 0.0.0.0?
Дак вот в том-то и проблема, что он никакой не 0.0.0.0 У линукса IP = 169.254.185.97, внутренний интерфейс роутера 169.254.185.200. Есть виндовая машина 169.254.185.1. Для интереса, чтобы убедиться, что линукс на самом деле не 0.0.0.0 я поробовал с винды его пингануть по 169.254.185.97 — пинг проходит, все ОК. Ума не приложу, чего роутер с ума сходит и про какой-то 0.0.0.0 пишет.
Не работает multicast linux после авторизации pppoe
Note: the plog script can only be used by root or another system admin‐istrator in group «adm», due to security reasons
Ага, и кроме того «просто добавь путь»:
$ /sbin/ifconfig ppp0
ppp0: error fetching interface information: Device not found
$ /sbin/ifconfig lo
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2341306 errors:0 dropped:0 overruns:0 frame:0
TX packets:2341306 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2061096919 (1.9 GiB) TX bytes:2061096919 (1.9 GiB)
$ _
>-rwsr-xr— 1 root dip 277352 2009-02-20 20:25 /usr/sbin/pppd
>dip:x:30:username
>system admin‐istrator in group «adm», due to security reasons
Да-да-да, помню дома для pppoe какие-то группы «давал» пользователям. Но 🙁 не помню, какие.
PPPoe, multicast IPTV и роутинг.
Нужна помощь в найтройке роутинга, чтобы multicast IPTV работал совместно с PPPoe.
Вот что происходит:
В обоих случаах: ip route get 233.7.70.2
multicast 233.7.70.2 via 10.24.238.31 dev eth0 src 10.24.238.37 cache mtu 1500 advmss 1460 hoplimit 64
Объясните пожалуйста чего не хватает? И что мне нужно прописать, чтобы заработало?
Добавь маршрут для мультикаста и будет тебе счастье 🙂
> Добавь маршрут для мультикаста и будет тебе счастье 🙂
Не, не будет. Эту очевидную штуку сзделал первым делом. О чем и говорит вот это:
multicast 233.7.70.2 via 10.24.238.31 dev eth0 src 10.24.238.37
Не знаю. К вартире подходит кабель.
Ну правильно, что ты хотел для мультикаста не нужен шлюз. а тут
multicast 233.7.70.2 via 10.24.238.31 dev eth0 src 10.24.238.37
показано что ты его указал
удаляй все маршруты для мультикаста и забивай правильно
ip route del 224.0.0.0/4
ip route add 224.0.0.0/4 dev eth0
поле этого у тебя должно быть
ip route get 233.7.70.2
multicast 233.7.70.2 dev eth0 src 10.24.238.37
> ip route del 224.0.0.0/4
Всё равно не работает. 🙁
Советую осилить udpxy. Мультикаст лучше завернуть в tcp.
Ну раз так, попробуй поиграться с метриками
ip route add default via 10.24.238.31 dev eth0 metric 1
А вообще очень мало информации нужен вывод
ip route до и после запуска pppoe
udpxy пофигу, какие там маршруты прописаны. Если в указанном ему интерфейсе есть мультикаст, он его забирает. Выглядит так:
Стоит помнить, что адреса каналов будут выглядеть примерно так:
Net-Labs.in
Network, ISP
Маршрутизация multicast в Linux
В современных реалиях, скорее всего, нет смысла заниматься маршрутизацией(репликацией) multicast-трафика с помощью софтроутеров(будь то ядро Linux или что-то иное). Причина довольно простая – даже дешёвые свитчи умеют L2/L3-multicast(хоть и с ограничениями по количеству групп/маршрутов, но всё же это делается в asic-ах). Однако, существует ряд задач, которые могут быть не решены в “железе” (нет поддержки со стороны ПО/невозможно реализовать ввиду возможностей asic), например ренамберинг(изменение destination ip), внесение случайных задержек(перемешивание), отправка multicast в тунель, резервирование источника по произвольному критерию.
Зачем может потребоваться ренамберинг мультикаст группы? Во-первых, маппинг IP-mac неодназначен(например, группам 238.1.1.1 и 239.1.1.1 соответствует один и тот же mac-адрес), что может вызвать проблемы в L2-сегменте. Конечно, такая коллизия маловероятна, однако возможна, когда вы берёте multicast из разных внешних источников(в принципе, IP-адреса могут даже полностью совпасть). Во-вторых, вы можете захотеть скрыть свой источник, изменив и destination и source адрес. В destination может быть “спрятан” номер AS источника(RFC3180), по source тоже можно догадаться об источнике, если он не серый. В третьих, перенумеровать группу может потребоваться для избежания коллизии на оборудовании, где заканчивается TCAM под multicast (как временное решение до замены оборудования/изменения схемы сети). И наконец, вы решили зарезервировать ТВ-каналы путём их получения из разных источников(т.е. вливать на сервер 2 разных группы(но одинаковых по контенту) и забирать из него одну, результирующую(работающую))
Внести случайную задержку(reordering) или потери может потребоваться для проверки поведения используемых STB/soft-плееров. Например, вам интересно, как будет выглядеть картинка, если где-то на сети мультикаст пройдёт через per-packet балансировку и не зависнет ли плеер при наличии потери пакетов, будут ли издаваться неприятные скрипящие звуки или же просто квадратики и тишина.
При написании этой заметки использовался Ubuntu Linux 14.04 LTS (ядро 3.13.0-24-generic), но применимо для большинства современных дистрибутивов, однако необходимо проверить поддержку IPv4 multicast в ядре:
В отличии от unicast роутинга, утилиты ip недостаточно даже для статической (S, G) маршрутизации, не говоря уже про динамическую. Для формирования таблицы мультикаст-репликации требуются “сторонние” userspace-утилиты. Например, для статических маршрутов это smcroute, для построения таблицы по igmp-запросам с даунлинк-интерфейсов – igmpproxy(маршрут добавляется в ядро тогда, когда “снизу” приходит igmp-запрос), для работы с PIM-SM сигнализацией – pimd(требуется поддержка PIMSM_V2 со стороны ядра).
Статическая маршрутизация multicast
Рассмотрим следующую задачу: осуществить репликацию мультикаст-трафика (*, 233.251.240.1) с интерфейса eth1 на интерфейсы eth2 и eth3, при этом на eth1 эта группа приходит только по igmpv2-запросу.
Конфигурация интерфейсов выглядет следующим образом:
К сожаленью, smcroute в ubuntu 14.04 не поддерживает (*, G)-форму, поэтому придётся скомпилировать из исходников:
Прежде чем запускать маршрутизацию(инсталлировать маршруты в ядро), нужно отключить RPF на интерфейсе eth1(поскольку по условию задачи считаем, что source ip multicast-группы может быть произвольным):
Кроме того, устанавливаем явным образом режим работы igmp на интерфейсе eth1:
Теперь переходим к конфигурации smcroute(/etc/smcroute.conf):
(необходим перевод строки в конце конфигурации)
Первая строчка – подключить группу по протоколу igmp(залить эту информацию в ядро), вторая – собственно мультикаст-маршрут.
Запускаем smcroute:
(логи пишутся в syslog)
Проверяем таблицу igmp:
Всё верно, 01F0FBE9 это наша группа 233.251.240.1.
До того, как в eth1 польётся мультикаст, таблица маршрутизации в ядре будет выглядеть таким образом:
Затем примет такой вид:
Проверяем работу репликации:
Ренамберинг мультикаст групп
Для того, чтобы изменить IP multicast группы используем DNAT. Например, мы хотим изменить 233.251.240.1 на 233.251.250.5:
/etc/smcroute.conf будет выглядеть следующим образом:
(в маршруте фигурирует новый адрес по причине того, что DNAT делается в PREROUTING-е)
Как нетрудно догадаться, чтобы подменить ещё и source ip, будем использовать SNAT:
Прочее
С помощью iptables и tc можно ещё что-нибудь сделать с трафиком(внести задержки и потери, например). При желании, можно организовать резервирование ТВ-канала путём переключения источника вещания с помощью скриптов(smcroute-ом можно управлять “извне”), придумав произвольные критерии выбора лучшего источника(подобные решения для операторов существуют и стоят больших денег)
unixforum.org
Форум для пользователей UNIX-подобных систем
Решено: Соединение pppoe не работает. (Соединение с Интернетом через ADSL-модем (PPPoE). )
Решено: Соединение pppoe не работает.
Сообщение ppavel » 25.09.2008 23:12
Я новичек в Debian, до этого стояла ALT Linux, вот решил пересесть на Debian. Для начала нужно настроить соединение с Интернетом, но что-то у меня не выходит.
Интернет у меня через ADSL подключается, т.е. через pppoe, установил пакеты pppoe и pppoeconf, запустил
Ответил на все вопросы «Да», ввел логин и пароль, все вроде бы успешно, но доступа к Интернету нет. Уже и выключал-включал соединение несколько раз (pon dsl-provider и poff), и перезагружался, но работать не хочет.
Debian 4.0r0.
Скажите, текст каких файлов и комманд выложить, а то я не знаю что нужно.
Еще скажите пожалуйста, как на этом форуме сделать, что бы все сообщения отображались друг за другом, а то у меня почему-то в виде «дерева» отображается, нужно щелкать по ссылкам все время, что бы прочитать сообщения.
Re: Решено: Соединение pppoe не работает.
Сообщение Aectann » 25.09.2008 23:20
web-страницы не открываются или что? Пробовали выполнять ping до каких-нибудь внешних серверов? Что в /etc/resolv.conf (после попытки поднятия соединения)?