При подключении компа к шнурку провайдера напрямую работают каналы udp://@234.5.2.*:20000 и udp://@239.255.*.*:5500.
При подключении через данный роутер каналы udp://@234.5.2.*:20000 работают, а с udp://@239.255.*.*:5500 -картинки нет!
Для просмотра использую прогу IPTV-player, прошивка рутера последняя 1.03B4.
Почему не проходят udp://@239.255.*.*:5500 и возможно ли это исправить?

Огласите, всё-таки, полный адрес мультикаста, который "не проходит". Это абсолютно не секретные данные.

_________________
прежде чем орать "кАзлы" - прочтите, наконец, инструкцию.... (c)

Не проходят, например, udp://@239.255.0.97:5500, udp://@239.255.0.179:5500, udp://@239.255.2.64:5500, udp://@239.255.2.20:5500 и т. п. - короче все адреса на 239 и соответственно портом 5500.

По rfc 239.255.*.* зарезервированы и не могут использоваться во внешней сети. Именно поэтому устройство не поддерживает эти адреса.

_________________
Сообщения в PM игнорируются, задавайте вопросы на форуме.

почему бы тогда аналогично не запретить на WAN иметь адреса 10/8, 172.16/12, 192.168/16 ? Однако до такого маразма Ваши китайские программисты не дошли. А ведь суть 239/8 - та же самая...
.
Неужели предположить, что WAN сеть роутера может являться частной серой сетью провайдера - так сложно для китайского программиста и (тем более) для грамотного русского специалиста?

_________________
прежде чем орать "кАзлы" - прочтите, наконец, инструкцию.... (c)

Прошу прощения, можно полюбопытствовать, на основании какого rfc DIR-400 с igmp-proxy вообще возомнил себя *маршрутизатором* мультикаста? (Это если не вдаваться в тонкости разночтения самого rfc2365. Не уверен, что его вообще кто-либо читал, иначе не было бы "зарезервировано" и "не могут")

У меня DIR-655. Была прошивка 1.12WW 239.255 работало, обновился на 1.21WW B10 - перестало. На e-mail саппорт ответил тоже отсылкой к RFC.

Читаю RFC2365. Поправьте, если ошибаюсь.

Пункт 6.1. The IPv4 Local Scope -- 239.255.0.0/16.
Не вижу, где там написано, что через рутер его пропускать нельзя.
Максимум - что не могут пересекать scope boundary. Не только свою конкретную, но и любую.

Дополнительно об этом напоминается последнем абзаце пункта 7 (Topological Requirements for Administrative Boundaries).

При этом заниматься этим вопросом должен boundary router, который должен при этом иметь настройки, описанные в пункте 5. А конкретно:


Т.е. серия DIR позиционируется для использования в качестве boundary router? Сделайте тогда, пожалуйста, настройку scope boundary. per-interface. Чтобы по RFC.

И раз уж решили делать по RFC, в пункте 6.1.1 есть такое:

Тоже не пропускаете?

Или может быть рутеру не стоит решать, где у нас провайдер решил иметь boundary scope?

У меня Тоже не получается настроить IPTV на DIR-400

Честно говоря меня начинает раздражать такая политика компании, прошивку для роутера уже давно не обновляли (Russia PPTP) невозможно вписать Secondary DNS.
Обрадовался, что провайдер дает такую услугу давай смотреть и ничего не работает

Если так и дальше пойдет я перестану людям вообще DLINK ставить.

Молчание со стороны представителей компании, полагаю, вызвано последствиями пережитого шока от осознания того, что wannabe boundary router DIR-400 в 99.(9)% случаев эксплуатации вообще используется как "раздвоитель" одного абонентского подключения на два абонентских компьютера. Т.е. сугубо как нат + igmp-proxy.

Глумиться далее над ситуацией смысла особого нет. Отмечу, разве что, что с точки зрения домосетевого провайдера, вся абонентская сеть и есть этот самый "local scope". Каждое абонентское подключение является "оконечным", мультикаст никоим образом никуда дальше маршрутизироваться не должен и использование для этих целей блока 239.255.0.0/16 является как раз обоснованным. Или прикажете GLOP использовать? (это просто как "альтернативный взгляд на мир", в противовес позиции ДЛинка)

Очевидно, впрочем, что за всем этим следовала попытка закрыть утекание через igmp-proxy всякой мути, типа UPnP. Надеюсь, что изначально цель преследовалась именно эта.

Кстати, вопрос: а блок 239.192.0.0/14 тоже попал под "благие намерения"? В этом диапазоне живет мультикаст весьма популярного мю-торрента, например.

2 deimos20062006

Так всё-таки его можно заставить работать с IPTV?
Поставил тычку "Enable Multicast Streams".
Не работает. Кучу прошивок перепробовал. И 1.01 и 1.02 бету и 1.03 бету.

Каналы udp://@239.0.*.*

По LAN сети хождение igmp видно. Например query от роутера в 239.0.1.1. Но это изнутри. Ну и от клиентской машины report в 239.0.1.1
На WAN порту тишина.

Подскажите рабочую прошивку и где её взять?
Или что-то ещё в настройках надо сделать?
Другие адреса тоже пробовал. Типа 224.0.0.1.

У меня в сети вообще 239.0.0.0/8.
udp://@239.0.0.40:1234
udp://@239.0.1.130:1234
....
Поставил галочку "Enable Multicast Streams" - никакой реакции.
Когда вообще ожидать работы IPTV?

Поднимаю тему.

Разработчики прошивок дайте разъяснение. Когда DIR-400 заработает нормально с IPTV? То, что он не пропускает 239.*.*.* подсеть, мы это поняли, но он вообще не пропускает всю подсеть мультикаста. Мой провайдер уже поменял список на другие IP-multicast, но коробка как не пропускала, так этого и не делает сейчас. Зачем вы туда слабенький проц повесили, чтоб он мучался, или год-два назад не предполагали, что не будет IPTV и не будет скоростей больше 2МБ?

Присоединяюсь к обсуждению!!! Даёшь ИПТВ!!!

_________________
Ура! Ура! Ура! Мы - студенты МИРЭА!

Видел это чудо живьем. Из коробки был "1.00" от октября 2007-го. Пропускал igmp до провайдера, получал на вход от провайдера поток - но на этом и всё.
Вытащил "стабильную" прошивку с ftp.dlink.ru, 1.01 от апреля 2008-го, вроде как. Пропускает мультикаст - но страдает "манией величия" и не пропускает "локальные" 239-е адреса.

IPTV неплохо идет с прошивкой от DD-WRT, и русский веб интерфейс там есть. Вот если бы еще в эту прошивку UDP-to-HTTP proxy добавили, чтоб IPTV по воздуху не застревало, то вообще класс было бы...

А с прошивкой от D-Linka с IPTV у меня также глухо. Каналы тоже начинаются с udp://@239.255.....