IPTV igmp non promiscuous mode magical bug
-
Добрый.
Вкл. сниффинг пакетов на интерфейсе (прямо в вебке пф) и посмотрите, что в нем при работающем и неработающим канале. -
werter, я и включал снифинг изначально - так и определил с каким костылем все работает как должно.
Просто снифинг показывает отсутствие igmp запросов.
Снифинг с галочкой промиск мод показывает igmp запросы и все работает.Т.е. включение packet capture + promiscuous mode в веб-интерфейсе pfsense
автоматически нейтрализует проблему и все каналы показывают нормально. -
Добрый.
Сетевые пробовал менять местами, с разных клиентов - все абсолютно также.
Попробуйте сменить (на время) сетевые на что-то приличное\поновее.
P.s. Отпишите в англоветку. Там разрабы сидят. Может и подскажут - баг это или фича.
-
что за мода на садо мазо?
снимайте поток до входа в маршрутер!!!!!! это делается на L2 коммутаторе. -
derwin, вы рофлите? я должен добыть ключи от чердака дома и от шкафа свитчей провайдера и прикрутить себе дополнительный кабель? если будет свободный порт? а еще найти дополнительный IP мимо договора с провайдером?
Там стоит DES-1228/ME (хотя по хорошему я, как клиент, вообще этого знать не должен)
Или вы хотите, чтобы я у себя дома поставил L2 свитч до pfsense? Допустим так, но мне нужен на tv-box не что-то одно из интернета и iptv, а и то и другое, а порт там, естественно, один.
И вообще, с какой целью мне "снимать поток до входа в маршрутер!!!!!!", если этот поток нужно закинуть в домашнюю сеть?
Может я что-то неправильно понял?P.S. с работой pfsense igmp proxy и IPTV сейчас проблем нет (с костылем), но есть проблема с ее качеством.
А именно, при канале в 100 Мбит/с, при минимальной потоковой загрузке (например twitch.tv) IPTV начинает моросить, т.е. происходит дроп пакетов хз в каком месте. Как с этим бороться я не знаю, точнее предполагаю, что нужно задавать приоритет UDP трафику от источника, но мне не удалось никак это реализовать в pfsense. Точнее ни один из вариантов не приводит к заметному результату.
Самый жирный HD канал берет около 13 Мбит/с. С чего вообще могут возникать лаги/дропы при свободной большей части канала я не понимаю. -
товарищ, если тебе нужно отдиагностировать проблему IPTV, то рекомендую начать с гугления по слову tsreader (это провайдерский инструментарий для таких случаев, но если позвоните провайдеру - скорее всего, он вас завернет в лес на поляну за грибами). Это программа- анализатор мультикаста. Выявляет битые последовательности (при перегруженном ретрансляторе или плохом канале), ошибки декодирования, ошибки контрольной суммы кодека и т.д.
Да, я предлагаю L2 снимать до входа в маршрутер. Кабель от провайдера перетягивать не обязательно, можно это сделать в метре от pfsense. L2 коммутаторы в простом исполнении по цене доступны, но могут не потянуть потоковое вещание (это ресурсоёмкая операция для чипа, нужно предварительно проверять). И да, чтобы закинуть поток в локалку - его нужно его прогнать на L2 до конечных потребителей, нужны минимальные знания сетевого инжиниринга, хотя бы в области VLAN и принципов коммутации/маршрутизации мультикаста.
Допустим так, но мне нужен на tv-box не что-то одно из интернета и iptv
а как вам провайдер подаёт услуги в кабель? там ведь и интернет, и IPTV. Вы почитайте хотя бы про адресацию в мультике, никакой проблемы тут нет.
-
мой вам совет. Если вам всё нужно и без ничего - купите себе домой зиксель кинетик лайт. Всё работает из коробки.
PS: DES-1228/ME - глючное д****о -
вот вам ещё http://www.dlink.ru/r/faq/58/266.html
кстати может стоять ограничение на кол-во каналов с порта у провайдера. -
derwin, спасибо за ответы,
много всего перепробовал - pfsense, open-wrt/lede, routeros, в итоге заказал MikroTik hEX lite - думаю его возможностей и мощности хватит для решения задачи.
маловероятно, что лаги iptv связаны с работой оборудования провайдера и нагрузка на свитч далеко не максимальная
по вашей схеме получается, что кабель от провайдера идет сначала в мой L2 роутер, который занимается мультикастом, затем в роутер/pfsense для раздачи интернета, и они соединены по lan портам, чтобы конечные потребители получали все вместе
-
MikroTik hEX lite - думаю его возможностей и мощности хватит для решения задачи.
Применительно именно к IPTV через мультикаст (многие провайдеры перешли на OTT\HLS,)
https://ru.wikipedia.org/wiki/OTT
https://ru.wikipedia.org/wiki/HLS
Микротик может и не лучший выбор. Многие роутеры-мыльницы с мультикастом справляются лучше.
Вероятно понадобится (обычно отсутствует в списке установленных) доп. пакет multicast-*.npk. Берется из Extra packages для для вашей архитектуры\версии ROS
https://mikrotik.com/download -
да вы чего, микротик и мультикаст вообще несовместимые вещи. Тупо чит не умеет, а проца не хватает на софтовую обработку.
-
Отлично работает IGMP Proxy на RB951G и на приставке и на компе показывает.
-
Отлично работает IGMP Proxy на RB951G и на приставке и на компе показывает.
вот именно, это PROXY, причём совтовое
-
вот именно, это PROXY, причём совтовое
А где он не софтовый? Коммутаторы тоже имеют софт. Данные ведь никто не перепаковывает, только заголовки пакетов.
-
Лолшта?
Если вы пропускаете пакет через ЦПУ - это всё софт.
Если ЦПУ делегирует обработку чипу - это хард.нужно пояснять чем плоха обработка пакетов в ЦПУ ? там есть такие слова как "шина данных, ширина шины данных, частота ЦПУ, операции с плавающей точкой, как сформировать 1 пакет на все порты вместо по пакету на каждый порт"
PS: у нормальных коммутаторов ЦПУ идёт только для загрузки ПО, которое программирует чипы после загрузки. Это прослойка юзер/чип
-
Я не отрицаю (более того я знаю о них) наличие аппаратного решения и его преимущества, но это уже совсем другой уровень железа (цен). Думаю для дома избыточный. RB951G имея на борту 600МГц RISC процессор нагружается на несколько процентов при просмотре одного потока.
-
одного - да. При попытке запустить 2-3 устройства увидите кубики на всех устройствах и крайне медленный интернет
-
pigbrother, спасибо, микротик настроил с доп. пакетом igmp proxy
derwin, да, есть некоторые лаги в iptv при одновременно работающих стримах на других устройствах домашней сети. Пока не понял/не разбирался в каком именно месте это возникает.
Ради теоретического интереса хотелось бы узнать конкретную минимальную рекомендацию железа, аппаратно работающего с мультикастом.
В домашней сети - PC Win10, Android tv-box, wi-fi не используется, но в перспективе может.Процессор hex lite работает на частоте 850МГц, можно поднять до 1000МГц (MIPSBE QCA9533).
Вообще, работа через CPU плоха определенными задержками и сомнительной мультизадачностью, но рассылка одного-двух UDP потоков пакетов (к тому же со снупингом) - задача достаточно тривиальная, тут узкое место - качество софта и правильность настройки.Если рассуждать логически - то UDP-поток iptv в принципе не может забивать канал, т.к. источник передает видео/аудио определенного битрейта (или определенного максимального битрейта), а забивать роутер могут только пакеты других типов, где у источника четких ограничений на скорость отдачи нет. Т.е. даже просто открывая обычный (но достаточно объемный по размеру) сайт можно получить тонну tcp пакетов, желающих как можно скорее дойти до адресата, какая бурст-атака вероятно плохо влияет на работу протоколов с негарантированной доставкой.
Даже обычный http видео-стрим с ютуба/твича или других ресурсов кешируется, а значит может ко мне приходить не плавно по своему битрейту, а большими кусками, конкурирующими за обработку роутером с другими пакетами.
Качество работы трафик-шейперов (и биллинговых костылей) между источником и моим роутером - вообще отдельная история… -
если вас всё устраивает и всё работает - чего мудрить то? ну пусть и дальше работает.
про количество стейтов и пакетов не переживайте, современные роутеры всё умеют и справляются(известное мне большинство). Проблема была актуальна лет 15 назад.В профессиональной среде сам использую микротики, в качестве роутера удалённого оффиса. Но сам отношусь с явным недоверием и считаю микротик "школьной поделкой". Убеждался в этом неоднократно, в том числе уже в этом году.
-
Меня бы устроило полное отсутствие искажений IPTV в плеерах при одновременной нагрузке на канал не более 90% от его ширины.
И даже при 100% загрузке канала хотелось бы иметь устойчивое изображение без квадратиков и прерываний звука.
В идеале - даже при speedtest-атаке.
И я верю, что есть способ этого достичь.Т.к. ни на одном уровне не удалось обнаружить дропов пакетов, делаю вывод, что искажения вызваны задержками в пересылке IPTV UDP пакетов, когда канал забивают пакеты других сервисов.
Попытки повышать приоритет пакетов и настройка очередей в роутере эффекта не дали, значит есть вероятность, что приоритеты нужно настраивать на стороне провайдера.RX Frames TX Frames --------- --------- CRC Error 0 Excessive Deferral 0 Undersize 0 CRC Error 0 Oversize 0 Late Collision 0 Fragment 0 Excessive Collision 0 Jabber 0 Single Collision 0 Drop Pkts 0 Collision 0 DES-1228/ME