[Abdul99Aziz]

все не сохранял) все решилось сменой браузера)

В таком случае в каком браузере отказывалось работать?

в хроме не работал.. в мозиле все норм пошло.

[sfstudio]

Вот только что под хромом настраивал девайс. Трабл не замечено. Всяко какая-нить баннерорезалка иль другая неведомая зверушка лезет руками в рожу вот и тараканит.

[dini]

в хроме не работал.. в мозиле все норм пошло.

Странно, но основным браузером у меня используется хром. Т.е. в первую очередь как раз на нём и прогоняется. Скорее всего что-то с настройками самого хрома, либо настройки антивируса.

[tux-tm]

Столкнулся с проблемой отказа в работе протокола Miracast (беспроводной экран) в диапазоне 2.4Гц. Работает оно насколько я понял без IP-адресов, чисто на уровне L2, т.е. по коммутации и наверняка там обнаружение девайса на броадкасте реализовано.

 

Причем обнаружил это при замене старого роутера TP-Link на черненький SNR-CPE-MD1, я так понимаю это MT7610-1T1R-5GHZ ?

C TP-Link всё работало нормально, а после замены на SNR подключиться не получается.

Что интересно, при попытке подключиться смартфон кратковременно подключается к Miracast и сразу же связь разрывается. Но если перед подключением обесточить WiFi-роутер SNR-CPE-MD1 - то связь устанавливается и работает несмотря на то что телефон Google Nexus5 и девайс с Miracast изначально подключены как клиенты к WiFi точке доступа - всё как по шпаргалке к девайсу.

 

Игрался разными параметрами WiFi - ничего не помогает, ни смена канала, ни стандарт WiFi - b,g,n

Не могу сказать баг ли это или требуется какая-то тонкая настройка, но точно знаю что не работает именно с MT7610-1T1R. Совместно с MT7620 2.4GHZ не проверял т.к. пока нет под рукой.

С роутером на OpenWRT тоже не замечено проблем.

 

Готов предоставить удаленный доступ к роутеру, или другую посильную помощь.

 

В Сети тезисно описана работа этого протокола так:

Используя Wi-Fi direct, устройства находят друг друга (обычно — источник видео-данных находит устройство отображения)

Используя ту или иную форму аутентификации (в нашем случае — pbc) устройства объединяются в P2P-группу

Одно из устройств получает IP-адрес по DHCP (в нашем случае — это источник видео-данных)

На источнике данных на порту 7236 запускается RTSP-сервер

Клиент подключается к RTSP-серверу, и запрашивает некий предопределенный URL (/wfd1.0/streamid=0)

RTSP-сервер начинает передавать видео (и, возможно, аудио) данные в форме MPEG-TS упакованных в RTP-пакеты.

Клиент распаковывает данные и отображает их на устройстве вывода.

 

Может быть связано с конфликтом/блокировкой DHCP-пакетов Miracast и WiFi-роутера ?

[sfstudio]

В MD-1 2.4 MT7620 во весь рост в нём 2.4ГГц радио, 5ГГц реализуется 7610. Что хочет миракаст ХЗ.

 

WiFi-Direct работает мимо роутера. Роутер вообще ничего не знает миракаст там или не миракаст.

 

А RTSP вобще нифига не L2.

 

Удалённый доступ мне ничем не поможет, устройств с поддержкой этого дела у меня нет. Судя по https://ru.wikipedia.org/wiki/Miracast оно работает сугубо через wifidirect, который в зависимости от реализации на клиенте работает либо как второй интерфейс либо же вообще отключается коннект до роутера (на нексусе как я понимаю первый вариант) т.е. роутер тут вообще сбоку.

 

Единственное предположение, что для wifi директ сети гугл решил выделить пересекающийся с роутерной сетью диапазон, и пакетики миракаста вместо того что бы бежать через wifi-direct пытаются бежать в dgw смотрящий в роутерную подсеть. Так что могу предложить разве что перенести роутер куда-нить в 10.222.111.0/24 подсеть (ну что бы уж точно не совпало).

 

Больше ничего предполагать не берусь. Роутер в этом процессе вообще не участвует. Так что косвенно других мест пересечения не вижу.

 

P.S. ни WLAN<=>WLAN, ни WLAN<=>LAN, не LAN<=>LAN в роутере никак не фильтруются ессно если не включена изоляция. Они тупо в бридже. Так что... Хотя один фиг не вижу связи роутера и wifi-direct, оно на то и direct что мимо роутера работает. И DHCP там свой внутри соедиеннеия юзается (ну насколько я когда-то код видел ведроидный на эту тему, да и щас лёгкий гуглинг говорит тоже самое). Так что разбирайтесь, потом расскажете.

[sfstudio]

Столкнулся с проблемой отказа в работе протокола Miracast (беспроводной экран) в диапазоне 2.4Гц. Работает оно насколько я понял без IP-адресов, чисто на уровне L2, т.е. по коммутации и наверняка там обнаружение девайса на броадкасте реализовано.

 

Не верно.

 

Но если перед подключением обесточить WiFi-роутер SNR-CPE-MD1 - то связь устанавливается и работает несмотря на то что телефон Google Nexus5 и девайс с Miracast изначально подключены как клиенты к WiFi точке доступа - всё как по шпаргалке к девайсу.

 

Что косвенно подтверждает мою догадку, т.е. стэйт в таблице трэкинга и route cache смарта и телевизора уже добавлен и пакетики бегут по старому пути даже после того как второй интерфейс достучался до роутера и получил ту же подсеть на себя по dhcp.

 

Тут гуглу репортить надо, что бы осиливали подсеть проверять на основном ифэйсе и для wifi директ выбирать что-то свободное. И уж точно не из 192.168/16 диапазона.

[sfstudio]

Пришёл в голову ещё возможный нюанс. Интерфейс wifi direct является вирутальным, т.е. не может работать с другими параметрами линка нежели основной. Т.е. если вы законнектитесь в 5ГГц АП, а ТВ к 2.4ГГц (например не поддерживает оно 2.4) работать ничего не будет. Если соединение установлено до включения роутера то ессно основное соединение уже пройдёт с одинаковыми для обоих линков параметрами заданными при подключении wifidirect (кто первый встал того и тапки).

 

P.S. И будьте добры когда говорите TP-Link или роутер на OpenWRT называть модель. Если вы развлекались с однодиапазонниками а перешли на 2х диапазонный, при этом нексус упал в 5Ггц, а ТВ в 2.4ГГц (к примеру) то будет то что имеете. Что-то мне подсказывает что отрубание 5ГГц диапазона на роутере разом решит проблему. Ну так для проверки.

[tux-tm]

Тестировал всё в одном диапазоне - 2.4Гц, хотя конечно пробовал и в разных диапазонах Miracast - на 2.4GHZ, Nexus5 - на 5GHZ. Разницы никакой - точно так же Miracast сначала определяется, но после кратковременного коннекта сразу же отваливается.

 

IP адресация была одинаковой как на старом роутере TP-Link WR1043ND HW ver1.0 , так и на D-Link DIR-620 (оба прошиты в OpenWRT 15.03) - подсеть везде одна и та же 192.168.10.0/24. Так что дело точно не в этом.

 

И еще когда оно работает, то и Miracast (в виде HDMI-свистка в телевизоре) и Nexus одновременно имеют доступ в Интернет через роутер (TP-Link WR1043ND).

 

То что этот протокол на стадии старта реализован через L2 и броадкаст - какие сомнения? ведь оно работает без внешнего DHCP-сервера. Там же сами устройства выступают в качестве DHCP-сервера, а DHCP-протокол как известно начинает свою работу c обмена броадкастовыми пакетами DHCP-Discover, DHCP-Offer.

К тому же на стадии обнаружения Miracast устройств в сети IP-адреса WiFi-роутера точно не используются.

 

Для WiFi-роутера весь этот трафик уж точно не является L3, но как-то же его присутствие в качестве AP эту связь нарушает.

 

Попробую на время отключить DHCP-сервис на SNR-CPE, а не всю AP.

Если причина в DHCP - это сработает.

[sfstudio]

Тестировал всё в одном диапазоне - 2.4Гц, хотя конечно пробовал и в разных диапазонах Miracast - на 2.4GHZ, Nexus5 - на 5GHZ. Разницы никакой - точно так же Miracast сначала определяется, но после кратковременного коннекта сразу же отваливается.

 

IP адресация была одинаковой как на старом роутере TP-Link WR1043ND HW ver1.0 , так и на D-Link DIR-620 (оба прошиты в OpenWRT 15.03) - подсеть везде одна и та же 192.168.10.0/24. Так что дело точно не в этом.

 

И еще когда оно работает, то и Miracast (в виде HDMI-свистка в телевизоре) и Nexus одновременно имеют доступ в Интернет через роутер (TP-Link WR1043ND).

 

Ну тогда жду устройств (точнее не жду ибо к роутеру сиё отношения не имеет увы, там свой транспорт). Ещё раз грю, передача картинки идёт через wifi-direct. Да и вообще всё взаимодествие. Так что влияние может быть только косвенным, а проблему нужно в любом случае лечить на клиентах. Почему оно вылезло именно в паре с SNR? Ну напрмер может потому что он что-то умеет чего не умеет один из клиентов, например GreenAP или широкую полосу или ещё что. Т.е. просто wifi-direct подняться не может (ну эт ещё на тему гаданий по миракасту).

 

То что этот протокол на стадии старта реализован через L2 и броадкаст - какие сомнения? ведь оно работает без внешнего DHCP-сервера. Там же сами устройства выступают в качестве DHCP-сервера, а DHCP-протокол как известно начинает свою работу c обмена броадкастовыми пакетами DHCP-Discover, DHCP-Offer.

К тому же на стадии обнаружения Miracast устройств в сети IP-адреса WiFi-роутера точно не используются.

 

А ещё оно работает через L1 т.к. поднимает свой линк, а т.к. работает через радио то оно реализуется по средствам модуляции исходного сигнала. Наличие DHCP уже говорит что выше будет самый обычный или необычный бутерброд. DHCP тут нужен свой именно что бы внутри p2p соединения адреса на концы назначить, и это костылина которая нафиг не нужна при реализации сразу поверх L2, но поверх L2 без прослойки RSTP не натянуть, и как обычно вышел костылизм. В итоге судя по описанию там бегает самый обычный RTSP коротый сроду не L2.

 

Я больше скажу судя по нагугленному сеть роутера вообще не используется никаким местом. Там свой линк через wifidirect свой DHCP и после назначения адресов самая обычная клиент-серверная реализация.

 

Для WiFi-роутера весь этот трафик уж точно не является L3, но как-то же его присутствие в качестве AP эту связь нарушает.

 

Через роутер этот трафик вообще не идёт. Ещё раз грю. С обоих сторон поднимается второй VIF для радио P2P соединения и весь процессинг идёт уже в нём. Т.е. транспорт для миракаста это wifidirect а не сеть роутера. Все свои догадки я расписал.

 

Попробую на время отключить DHCP-сервис на SNR-CPE, а не всю AP.

Если причина в DHCP - это сработает.

 

И вы надеюсь отрепортите в гугл ибо это не проблема роутера.

[sfstudio]

В общем глянул ещё разок на это всё безобразие. Вывод Miracast это нахлабучка поверх Wifi Direct. У MTK она завётся WDF, ессно только в STA режиме. Как и грил при параллельном подключении к AP и к ТВ собсно через сеть AP никаких данных миракаста ходить не должно и эта сеть никак влиять на работу миракаста не должна, кроме как в выше описанных потенциально проблемных случаях. Вся коммуникайция и передача потока осуществляется внутри Wifi Direct соединения.

 

А вот ChromeCast уже юзает AP сеть как транспорт и управление. Как и EZCast/SmartCast и прочие аналоги. Хотя они вроде как тоже умеют использовать WiFi Direct.

 

В общем чем вам помочь не представляю. Роутер в этом процессе (в случае с миракастом) не учавствует вовсе, он просто дырку в инет предоставляет. Его вообще может не быть. Явно какой-то косяк либо в клиенте либо в донгле который проявился после смены роутера. А вот что именно послужило переключателем после которого вылезла трабла это вопрос.

[Kirill Vasilyev]

tux-tm, пришлите текущую конфигурацию при которой miracast не работает

[sfstudio]

tux-tm, пришлите текущую конфигурацию при которой miracast не работает

 

Кирил? Зачем? Хоть одну причину и что это тебе даст скажи? Ну не юзает миракаст роутер, т.е. вообще не юзает.

[tux-tm]

Коллеги, скорее всего у меня не чистый Миракаст, почитал и понял что там такой зоопарк в этих донглах - EzCast, AnyCast, MiraScreen(у меня такой) и т.д.

Так что пока не напрягайтесь, сначала я помучаю сам девайс, комбинации настроек и т.п.

[sfstudio]

Если не чистый миракаст то возможно придётся отрубить m2u и igmpproxy ибо часть этих каках пытается юзать группы незарезервированные для своих нужд, а их гарантированно поймает снупинг и igmpproxy и попытается получить их извне.

[tux-tm]

Если не чистый миракаст то возможно придётся отрубить m2u и igmpproxy ибо часть этих каках пытается юзать группы незарезервированные для своих нужд, а их гарантированно поймает снупинг и igmpproxy и попытается получить их извне.

Спасибо, это и было причиной. Замотался и некогда было проверить.

Девайсы отлично заработали после отключения мультикастовой обработки на CPE.

[sfstudio]

Пишите производителям и объясняйте что для локального мультикаста есть диапазоны для этого предназначенные иначе будут косяки со снупингом на очень многих железках. Отключать m2u для WLAN крайне не хорошая идея.

[tux-tm]

Писать почти бесполезно. Это чистый Китай.

[taf_321]

Клиент пожаловался, что спустя некоторое время после начала активного использования сети (HD тв, серфинг, скайпы и все такое), начинает глючить связь. То пропадает WiFi, то резко падает скорость как по радио, так и по проводам. И так далее. Игры с настройками и перебором прошивок не помогли, доходило до того, что роутер переставал реагировать на ssh и веб. Коробку принесли в офис на вскрытие. Вскрытие показало, что радиатор приклеен к SoC самым краешком. Переклеили радиатор суперклеем на всю поверхность, третью неделю полет нормальный. (SNR-CPE-W4N rev.M)

[sfstudio]

А можно было его и вовсе оторвать и выкинуть. Полёт был бы не хуже. MT7620N не требует доп охлаждения вообще. Даже в печке при 40 градусах при полной нагрузке гонялся в лабе не одни сутки. Так что возможно он краешком коротил чего-нить или фиг знает. Но дело не в перегреве (не если конечно опять таки не в печке стоял). У меня ни на одном из сэмплов с которыми работаю и на которых отлаживаю ПО нет радиатора - не первый год полёт нормальный.