[alibek]

Делаю стриминг IP-камер в IPTV следующим образом.

Есть сервер, на котором запускается VLC следующим образом:

cvlc --vlm-conf=iptv.conf --ttl 5

где файл iptv.conf выглядит примерно так:

new CH-102 broadcast enabled loop
setup CH-102 input rtsp://usr:pwd@10.102.1.2/live/ch00_0
setup CH-102 output #std{access=udp,dst=239.0.1.2:1234}
control CH-102 play

То есть берется RTSP с камеры и направляется в мультикаст-группу.

Чтобы направлялось куда надо, добавлен статический маршрут:

$ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
...
10.1.127.0      0.0.0.0         255.255.255.0   U         0 0          0 eth1
239.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 eth1
...

eth1 это интерфейс, подключенный в порт коммутатора, который является igmp querier, интерфейс сервера выглядит так:

# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 94:de:80:a1:9c:b1  
          inet addr:10.1.127.250  Bcast:10.1.127.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:20 Memory:f0500000-f0520000 

Поломка выглядит так (график с порта igmp querier):

 

Что-то произошло вчера примерно в 12 часов, потом стрим лихорадило примерно до 22 часов, потом трафик сильно упал, но стабилизировался, а потом примерно в 04:30 вообще пропал.

И с тех пор сервер не стримит IPTV.

 

Запускаю VLC с одним каналом CH-102, в логах самого VLC ошибок нет (изредка проскакивает ES_OUT_RESET_PCR, но для IP-камер это нормально).

Если смотреть утилизацию интерфейсов с помощью утилиты iftop, то на входящем интерфейсе (по которому забираю RTSP) все нормально, трафик с камеры вижу.

А вот на eth1 трафик вообще отсутствует, ни одного пакета. То есть поток с камеры забирается, куда-то отдается, но не могу найти — куда.

Если смотреть статистику на порту коммутатора (igmp querier), то на input там так же нули.

Вообщем трафик сервера вообще не идет в eth1, tcpdump даже случайных пакетов не показывает.

Проверял файрвол, даже сервер перегрузил, когда фантазия кончилась, но ничего не поменялось.

Такое впечатление, что сетевая плата просто сдохла, но причин для этого никаких не было и статус линка (при отключении патчкорда) меняется.

 

Не посоветуете, что еще проверить?

[Ivan_83]

12 часов назад, alibek сказал:

239.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1

Я бы посоветовал не страдать хернёй, а отрыть вики и использовать правильные адреса.

Сейчас у тебя игмп сломан, прочитаешь про сети мультикаста и игмп - сам поймёшь почему.

 

В добавок rp фильтр отключи в линухе.

[myth]

rp filter же только прием ломает

[alibek]

Вообщем прояснилось, это сетевая плата померла таким хитрым образом.

Сейчас все восстановил, заменил сетевую.

 

12 часов назад, Ivan_83 сказал:

а отрыть вики и использовать правильные адреса

Правильные мультикаст-адреса? Так ведь 239/8 и выделен для частного использования, разве нет?

 

12 часов назад, Ivan_83 сказал:

прочитаешь про сети мультикаста и игмп - сам поймёшь почему

Пока что не понял. Не подскажешь, что именно не так?

Сам сервер-стример про IGMP ничего не знает, он тупо льет все потоки по мультикасту в порт.

IGMP Querier работает на порту коммутатора (каталист), в который этот сервер подключен.

 

12 часов назад, Ivan_83 сказал:

В добавок rp фильтр отключи в линухе.

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

[Ivan_83]

Стыдно должно быть.

224.0.0.0/4

IGMP и многие службы как раз используют адреса из 224/24, так что игмп у тебя мог куда нибудь не туда запросы на присоединение к группе слать.

RP препятствует не отправке запросов а получению трафика.

[alibek]

Про 224/24 я знаю, но я ведь на этом участке не использую IGMP. Сервер просто льет поток в порт.

[GrandPr1de]

Rp фильтр ещё как влияет 

[alibek]

Я понимаю, что он влияет в случае маршрутизации.

Но у меня то ее нет, я просто забираю поток с одного интерфейса (успешно) и отправляю в другой интерфейс (после смены сетевой платы — тоже успешно).

[s.lobanov]

4 часа назад, Ivan_83 сказал:

Стыдно должно быть.

224.0.0.0/4

IGMP и многие службы как раз используют адреса из 224/24, так что игмп у тебя мог куда нибудь не туда запросы на присоединение к группе слать.

наркоман чтоле? он забирает по unicast-у, вещает по мультикасту. зачем ему igmp-запросы отправлять? он тупо гадит мультикастом в интерфейс. маршрут до 224/24 не нужен, нужен только один маршрут "ip ro add MCAST_GROUP/32 dev ethX"

[Ivan_83]

2 часа назад, s.lobanov сказал:

наркоман чтоле? он забирает по unicast-у, вещает по мультикасту.

Да, пардон, просмотрел что там на входе юникаст.

 

2 часа назад, s.lobanov сказал:

зачем ему igmp-запросы отправлять?

Как минимум затем, что раз интерфейс используется для мультикаста то логично чтобы там IGMP тоже работал.

[s.lobanov]

5 минут назад, Ivan_83 сказал:

Как минимум затем, что раз интерфейс используется для мультикаста то логично чтобы там IGMP тоже работал.

что значит работал? что именно сервер должен посылать/принимать-обрабатывать по igmp и зачем это делать? это ПРОСТО СТРИМЕР, его задача тупо стримить в интерфейс не смотря ни на что. при чем здесь igmp?

может быть на стой стороне стоит роутер, на котором IGMP не настроен от слова совсем, а настроен только PIM (вообщем-то почти всегда в крупных сетях так оно и есть - стример плюётся в роутер с настроенным PIM/NG-MVPN)