[sisyphus] IPTV multicast и Сизиф

[sisyphus] IPTV multicast и Сизиф

[Вячеслав Диконов]

Задаю вопрос сюда, так как нужно знание тонкостей.

Мой комп подключен к Корбине и может ловить IPTV (UDP multicasting).
Смотреть можно с помощью mplayer, VLC, VDR-iptv и т.п.

Три дня назад на Сизифе с ядром std-up-2.6.16-alt9 я поставил VLC и
попробовал смотреть. Все работало, и на ТВ выводилось (через карту SS1).
Показывало даже качественнее спутника на одинаковых каналах (Вести,
Russia Today). Однако. через несколько часов на середине передачи все
оборвалось. С тех пор любые проигрыватели просто не начинают принимать
UDP мультикаст.  Во время звонка в техподдержку Корбины было некоторое
мерцание ("Первый канал" вдруг заработал, и опять потух через минут 5). 

Разбирательство с техподдержкой привело к тому, что проблема связана с
системой так как:

1) Мультикасты в мой провод идут исправно, а мои соседи-виндузятники все
смотрят стабильно через виндовый VLC.
2) Уникаст запрос на присоединение к мультикаст группе от меня уходит и
Корбина его видит.
3) У меня VLC и все аналоги работали и отключились синхронно.
4) dist-upgrade в промежутке не делал, с маршрутами все в порядке.
5) iptables отключены.
6) Ноутбук с Сизифом, но ядром 2.6.18-wks-smp ведет себя также.
7) Диагноз - прием идущих ко мне мультикаст пакетов не начинается.
8) Мне сказали, что _моя_ машина не посылает _некоторых_ необходимых
пакетов "igmp_snooping group".
9) Поскольку я пользовался 2 разными проигрывателями и не менял
настроек, то валить на собственно VLC не получается.

Как можно исключить из подозреваемых ядро и библиотеки?
Как проверить локально, не режет ли что-то эти самые igmp пакеты до
выхода в сеть, и посылаются ли они действительно?

У кого есть опыт IPTV вещания/приема?





Это лог VLC при подключении к Первому каналу
---------------------------------------------------------
main debug: creating new input thread
main debug: waiting for thread completion
main debug: thread 3019971472 (input) created at priority 0
(input/input.c:265)
main debug: `udp://@233.32.240.115:5050' gives access `udp' demux `'
path `@233.32.240.115:5050'
main debug: creating demux: access='udp' demux=''
path='@233.32.240.115:5050'
main debug: looking for access_demux module: 0 candidates
main warning: no access_demux module matched "udp"
main debug: creating access 'udp' path='@233.32.240.115:5050'
main debug: looking for access2 module: 7 candidates
access_udp debug: opening server=:0 local=233.32.240.115:5050
main debug: net: connecting to '[]:0@[233.32.240.115]:5050'
main debug: looking for network module: 1 candidate
ipv6 debug: 233.32.240.115: Семейство адресов не поддерживатся для
данного имени хоста
main debug: using network module "ipv6"
main debug: removing module "ipv6"
main debug: looking for network module: 1 candidate
ipv4 debug: resolving 233.32.240.115:5050...
ipv4 debug: resolving :0...
ipv4 debug: IP_ADD_MEMBERSHIP multicast request
main debug: using network module "ipv4"
main debug: removing module "ipv4"
main debug: using access2 module "access_udp"
main debug: pre buffering

Re: [sisyphus] IPTV multicast и Сизиф

[Pavlov Konstantin]

[-- Attachment #1: Type: text/plain, Size: 3671 bytes --]

On Tue, Dec 11, 2007 at 02:17:05PM +0300, Вячеслав Диконов wrote:
> Задаю вопрос сюда, так как нужно знание тонкостей.
> 
> Мой комп подключен к Корбине и может ловить IPTV (UDP multicasting).
> Смотреть можно с помощью mplayer, VLC, VDR-iptv и т.п.
> 
> Три дня назад на Сизифе с ядром std-up-2.6.16-alt9 я поставил VLC и
> попробовал смотреть. Все работало, и на ТВ выводилось (через карту SS1).
> Показывало даже качественнее спутника на одинаковых каналах (Вести,
> Russia Today). Однако. через несколько часов на середине передачи все
> оборвалось. С тех пор любые проигрыватели просто не начинают принимать
> UDP мультикаст.  Во время звонка в техподдержку Корбины было некоторое
> мерцание ("Первый канал" вдруг заработал, и опять потух через минут 5). 
> 
> Разбирательство с техподдержкой привело к тому, что проблема связана с
> системой так как:
> 
> 1) Мультикасты в мой провод идут исправно, а мои соседи-виндузятники все
> смотрят стабильно через виндовый VLC.
> 2) Уникаст запрос на присоединение к мультикаст группе от меня уходит и
> Корбина его видит.
> 3) У меня VLC и все аналоги работали и отключились синхронно.
> 4) dist-upgrade в промежутке не делал, с маршрутами все в порядке.
> 5) iptables отключены.
> 6) Ноутбук с Сизифом, но ядром 2.6.18-wks-smp ведет себя также.
> 7) Диагноз - прием идущих ко мне мультикаст пакетов не начинается.
> 8) Мне сказали, что _моя_ машина не посылает _некоторых_ необходимых
> пакетов "igmp_snooping group".
> 9) Поскольку я пользовался 2 разными проигрывателями и не менял
> настроек, то валить на собственно VLC не получается.

Учитывая, что мультикастом управляет ОС, а не плеер, дело явно не в
последнем.

> Как можно исключить из подозреваемых ядро и библиотеки?
> Как проверить локально, не режет ли что-то эти самые igmp пакеты до
> выхода в сеть, и посылаются ли они действительно?

tcpdump'ом.

> У кого есть опыт IPTV вещания/приема?
> 
> 
> 
> 
> 
> Это лог VLC при подключении к Первому каналу
> ---------------------------------------------------------
> main debug: creating new input thread
> main debug: waiting for thread completion
> main debug: thread 3019971472 (input) created at priority 0
> (input/input.c:265)
> main debug: `udp://@233.32.240.115:5050' gives access `udp' demux `'
> path `@233.32.240.115:5050'
> main debug: creating demux: access='udp' demux=''
> path='@233.32.240.115:5050'
> main debug: looking for access_demux module: 0 candidates
> main warning: no access_demux module matched "udp"
> main debug: creating access 'udp' path='@233.32.240.115:5050'
> main debug: looking for access2 module: 7 candidates
> access_udp debug: opening server=:0 local=233.32.240.115:5050
> main debug: net: connecting to '[]:0@[233.32.240.115]:5050'
> main debug: looking for network module: 1 candidate
> ipv6 debug: 233.32.240.115: Семейство адресов не поддерживатся для
> данного имени хоста
> main debug: using network module "ipv6"
> main debug: removing module "ipv6"
> main debug: looking for network module: 1 candidate
> ipv4 debug: resolving 233.32.240.115:5050...
> ipv4 debug: resolving :0...
> ipv4 debug: IP_ADD_MEMBERSHIP multicast request
> main debug: using network module "ipv4"
> main debug: removing module "ipv4"
> main debug: using access2 module "access_udp"
> main debug: pre buffering

Похоже, джойн в мультикаст-группу не проходит. Такое ощущение, что
проблема в Корбине.

-- 
<bad_max2k> помнится, профессор Преображенский из "собачье сердце" советовал не
            читать с утра советских газет
<bad_max2k> хочется добавить, что не стоит также и править iptables с утра :-)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] IPTV multicast и Сизиф

[Peter V. Saveliev]

В сообщении от Tuesday 11 December 2007 14:17:05 Вячеслав Диконов написал(а):
> Задаю вопрос сюда, так как нужно знание тонкостей.
<skip />

$ strace -e trace=network -f vlc
$ sudo tcpdump -nnli any ip proto \\igmp

?

-- 
Peter V. Saveliev

Re: [sisyphus] IPTV multicast и Сизиф

[Вячеслав Диконов]

В Втр, 11/12/2007 в 16:32 +0300, Peter V. Saveliev пишет:
> В сообщении от Tuesday 11 December 2007 14:17:05 Вячеслав Диконов написал(а):
> > Задаю вопрос сюда, так как нужно знание тонкостей.
> <skip />
> 
> $ strace -e trace=network -f vlc
---------------------------------------

$ strace -e trace=network -f vlc udp://@233.32.240.115:5050
VLC media player 0.8.6d Janus
socket(PF_FILE, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1
ENOENT (No such file or directory)
socket(PF_FILE, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1
ENOENT (No such file or directory)
socket(PF_FILE, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_FILE, path="/var/run/dbus/system_bus_socket"},
33) = 0
Process 6737 attached
Process 6738 attached
Process 6739 attached
Process 6740 attached
Process 6745 attached
[pid  6736] socket(PF_FILE, SOCK_STREAM, 0) = 6
[pid  6736] connect(6, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"},
110) = 0
[pid  6736] getpeername(6, {sa_family=AF_FILE,
path=@"/tmp/.X11-unix/X0"}, [110]) = 0
/home/slava/.gtkrc-2.0:2: Не удалось найти подключаемый файл:
".gtkrc-2.0-scrollbar_cog"

** (.:6736): CRITICAL **: gtk_pizza_set_size: assertion `pizza != NULL'
failed
Process 6750 attached
[pid  6750] socket(PF_NETLINK, SOCK_RAW, 0) = 7
[pid  6750] bind(7, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12)
= 0
[pid  6750] getsockname(7, {sa_family=AF_NETLINK, pid=6736,
groups=00000000}, [12]) = 0
[pid  6750] sendto(7, "\24\0\0\0\26\0\1\3\206\231^G\0\0\0\0\0\0\0\0",
20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20
[pid  6750] recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000}, msg_iov(1)=[{"<\0\0\0\24\0\2\0\206\231^GP\32\0\0\2\10
\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0,
msg_flags=0}, 0) = 316
[pid  6750] recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\206\231^GP\32\0\0\0\0
\0\0\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0,
msg_flags=0}, 0) = 20
[pid  6750] socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 7
[pid  6750] setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
[pid  6750] setsockopt(7, SOL_SOCKET, SO_RCVBUF, [524288], 4) = 0
[pid  6750] setsockopt(7, SOL_SOCKET, SO_SNDBUF, [524288], 4) = 0
[pid  6750] bind(7, {sa_family=AF_INET, sin_port=htons(5050),
sin_addr=inet_addr("233.32.240.115")}, 16) = 0
[pid  6750] setsockopt(7, SOL_IP, IP_ADD_MEMBERSHIP, "\351 \360s\0\0\0
\0", 8) = 0
[pid  6750] shutdown(7, 1 /* send */)   = -1 ENOTCONN (Transport
endpoint is not connected)

---------------------------------------
и далее молчит, показывая "main debug: pre buffering"


> $ sudo tcpdump -nnli any ip proto \\igmp
> 
---------------------------------------

$ sudo tcpdump -nnli any ip proto \\igmp
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96
bytes
17:09:38.432562 IP 10.179.42.158 > 224.0.0.22: igmp v3 report, 1 group
record(s)
17:09:46.217018 IP 10.179.42.158 > 224.0.0.22: igmp v3 report, 1 group
record(s)
17:10:46.650447 IP 10.6.49.127 > 224.0.0.1: igmp query v2
17:10:51.653752 IP 172.1.1.1 > 224.0.0.1: igmp query v2

---------------------------------------

Изредка появляются новые сообщения tcpdump