Ace Stream и uPnP

Добавьте пожалуйста в настройки выключение uPnP

Хотелось бы увидеть это дополнение как можно скорее, т.к. на некоторых компьютерах наблюдается проблема с программами использующих uPnP в том числе и с ts player.

Если много раз перезапускать engine, то вот что получается с miniupnpd.
Может лучше сперва проверять существует ли уже редирект, прежде чем запрашивать новый ?

TCP:8621:192.168.4.2:8621:0:AceStream port 8621 -> 8621
TCP:8622:192.168.4.2:8621:0:AceStream port 8621 -> 8622
TCP:8623:192.168.4.2:8621:0:AceStream port 8621 -> 8623
TCP:8624:192.168.4.2:8621:0:AceStream port 8621 -> 8624
TCP:8625:192.168.4.2:8621:0:AceStream port 8621 -> 8625
TCP:8626:192.168.4.2:8621:0:AceStream port 8621 -> 8626
TCP:8627:192.168.4.2:8621:0:AceStream port 8621 -> 8627
TCP:8628:192.168.4.2:8621:0:AceStream port 8621 -> 8628
TCP:8629:192.168.4.2:8621:0:AceStream port 8621 -> 8629
TCP:8630:192.168.4.2:8621:0:AceStream port 8621 -> 8630

“Перезапускать” корректно, или же после падения/насильственного убиения процесса? В первом случае движок всегда отписывается UPNP серверу - “я закончил, редирект можно убрать”, т.е подобного быть не должно.

Во втором случае не все так просто, и конктретно для miniupnpd есть смысл посмотреть на его параметры “clean_ruleset_threshold” и “clean_ruleset_interval”.

Да, ваша правда. В ходе экспериментов много раз убивал его киллом.
Но может все-таки сохранять информацию,необходимую для управления лизом в файл ?

Столкнулся с такой проблемой, в версии для андройд 3.1.24.2 не срабатывает upnp, на роутере TPlink 1043 upnp включен, другие программы(Flud, Elementum для kodi), его активно юзают, а acestream постоянно выбрасывает в лог

[details=Spoiler]2018-01-30 20:28:38,708|Thread-18|acestream.upnp|forward: found 1 devices
2018-01-30 20:28:38,707|Thread-28|acestream.coreapp|get_default_destdir: get from config: /storage/48471B4248519A7F/Android/data/org.acestream.media/files/.acestream_cache
2018-01-30 20:28:38,710|Timer-Thread-27|acestream.BGInstanceConnection|write: not ready: data=SHUTDOWN

2018-01-30 20:28:38,711|Thread-18|acestream.upnp|forward: failed to get external ip
2018-01-30 20:28:38,716|Timer-Thread-24|acestream|ga::send_request: success: http://www.google-analytics.com/__utm.gif?utme=5(client*startup*3.1.24)&utmac=UA-24039434-6&utmwv=4.3&utmn=2105203904&utmcc=__utma%3D397569292.355870639.1517336918.1517336918.1517336918.1%3B&utmt=event
2018-01-30 20:28:38,719|Thread-28|acestream.coreapp|set_playerconfig: key=download_dir value=/storage/48471B4248519A7F/Android/data/org.acestream.media/files/.acestream_cache old=/storage/48471B4248519A7F/Android/data/org.acestream.media/files/.acestream_cache
2018-01-30 20:28:38,720|Timer-Thread-27|acestream.BGInstanceConnection|send NOTREADY
2018-01-30 20:28:38,727|Timer-Thread-27|acestream.BGInstanceConnection|close
2018-01-30 20:28:38,728|Timer-Thread-27|acestream.coreapp|connection_lost: ip=127.0.0.1 port=57846
2018-01-30 20:28:38,730|Timer-Thread-27|acestream.coreapp|bg::connection_lost: socket key error
2018-01-30 20:28:38,725|Thread-28|acestream.coreapp|get_default_destdir: return: return_user_path=True dest_dir=/storage/48471B4248519A7F/Android/data/org.acestream.media/files/.acestream_cache retval=/storage/48471B4248519A7F/Android/data/org.acestream.media/files
2018-01-30 20:28:38,734|Thread-28|acestream.httpserver|acquire_inputstream: got response from mapper: streaminfo={‘mimetype’: ‘application/json; charset=utf-8’, ‘length’: 730, ‘stream’: <cStringIO.StringI object at 0xf4651350>, ‘statuscode’: 200} mapper=<ACEStream.WebUI.WebUI.WebIFPathMapper instance at 0xf1a523c8>
2018-01-30 20:28:38,735|Thread-18|acestream.upnp|forward: selectigd() returned http://192.168.1.1:1900/ipc
2018-01-30 20:28:38,737|Thread-28|acestream.httpserver|get: not range request: close_stream=True
2018-01-30 20:28:38,743|Thread-28|acestream.httpserver|get: write done: bytes=730 time=0.000229835510254 total=730
2018-01-30 20:28:38,753|Thread-28|acestream.httpserver|get: request finished: time=0.0573320388794 bytes_sent=730
2018-01-30 20:28:38,754|Thread-18|acestream.upnp|Unable to create Port Forward. Error:Action Failed[/details]
Я понимаю, что можно пробросить порт в ручную, но хотелось бы автоматики.
Есть решение этой проблеме? Роутер менять не буду! :slight_smile:

Спасибо за информацию.
На роутере прошивка заводская или альтернативная (dd-wrt и подобные)? И насколько она свежая в обоих случаях (версия)?

Есть предположение, что движок “не дружит” с последними версиями miniupnpd, но для однозначного ответа нужны дополнительные тесты.

Прошивка на роутере почти родная (из русифицированных) 3.13.11 Build 121102 Rel.51321n, свежей её не назовешь, но вроде обновлений на эту модель уже часто не выускают. В свое время было протестировано много прошивок и эта оказалась наиболее стабильная и безглючная на моём девайсе. Тут дело в том, что сам роутер не вызывает нареканий при работе с upnp с другими приложениями, вот сейчас три машины в локалке получили свои пробросы для utorrent, как выше писал Flud и Elementum с приставки на которой AceStream тоже получают пробросы нормально.
Правда Elementum (anacrolix/torrent) создает много открытых портов, но у них как я понял эта функция только запустилась и находится в бете.
Из тестов которые я еще проводил, это запускал на стационарнике подсоедененом к тому же роутеру, снифер wareshark, и в нем виден широковещательный запрос от acestream на поиск upnp, но ответ как вы понимаете я в этом случае не вижу, т.к. он уже адресуется от роутера на андройд приставку и на этом интерфейсе не слышен. Ещё обратил внимание, что другие программы шлют несколько подобных широковещательных запросов, а acestream только один, читал гдето, что некоторые роутеры не отправляют ответ при первом запросе, но отправка нескольких запросов даёт им пинка, может это мой вариант, но повторюсь, что с другим софтом, я с этой проблемой не встречался.
В общем, если что-то нужно потестировать, без глобальных перепрошивок, то я готов помочь.

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

В сети только одно устройство с Ace Stream?
Да одно. И в админке роутера не чего не светится в upnp пробросах по этому 8621 порту.

Судя по этой строке
acestream.upnp|forward: selectigd() returned http://192.168.1.1:1900/ipc
на сколько я понимаю, движок не получает xml от роутера…
А можно как то увидеть в логах более подробно обмен пакетами, или это только нужно что то ставить на приставку для снифа?

“Пакетами” нет, но можно увидеть более развернутый дебаг-лог если перезаписать оригинальный конф-файл этим в каталоге движка - http://dl.acestream.media/utils/configs/debug/android/acestream.conf

Более расширенный лог дополнительной информации не дал.
Все что есть по upnp

Spoiler

2018-01-31 21:59:26,859|MainThread|acestream.coreapp|init: set preference from persistent config: upnp_enabled=True


2018-01-31 21:59:27,052|Thread-18|acestream.upnp|start __retry_discover()


2018-01-31 21:59:29,092|Thread-18|acestream.upnp|forward: found 1 devices
2018-01-31 21:59:29,104|Thread-18|acestream.upnp|forward: failed to get external ip
2018-01-31 21:59:29,124|Thread-18|acestream.upnp|forward: selectigd() returned http://192.168.1.1:1900/ipc
2018-01-31 21:59:29,132|Thread-18|acestream.upnp|Unable to create Port Forward. Error:Action Failed

Понимать бы ещё на каком этапе какой лог выкидывает… вот например, found 1 devices, говрорит ли о том, что движок получил какой либо ответ от роутера? Скорее всего да… значит путь к xml тоже получить должен…
В общем постараюсь завтра какой нибудь снифер прикрутить и послушать что там они друг другу говорят.
Если будут какие то рекомендации с вашей стороны, пишите.

Войти-выйти, по колесам постучать? =)

Пока “серьезных” рекомендаций нет - все сплошные банальности вроде перезагрузить роутер, сменить порт в приложении на отличный от дефолтного, откатиться на прежнюю версию (последнее врядли поможет, т.к upnp в движке пару лет минимум как не трогали - но вдруг). Виндовая/линуксовая версия нормально через upnp пробрасывает порты с этим роутером?

На текущий момент все /повторяемые/ траблы с upnp были буквально пару раз - в одном случае нестандартная конфигурация сети (когда в ней более 1 роутера анонсят себя по SSDP), во втором - свежая самосборная версия miniupnpd. Все, в остальных случаях оно “просто работает”.

И снова здрасте. решил проверить как себя будет вести виндовый движок - ситуация такаяже как и на андройдовском - upnp не работает. Допускаю, что проблема частично лежит на роутере, но учитывая, что с другими прогами роблем нет, решил поизучать доскональней.

Сразу уточню, что в сетевых протоколах и пакетах не проффи, поэтому мои умозаключения могут быть не корректны, разбираюсь с этим на лету при помощи гугла, хабра и других источников.
Эксперемент проводится снифом пакетов на виндовой машине при запуске acestream и utorrent (который проброс получает).
Разница в запросах, начинается еще на этапе посылки широковещательного M-SEARCH заголовок MX: у acestream -2 utorrent -3, но как я понимаю это тайм аут ожидания ответа и он здесь не причем, потому что ответ мы получаем и в первом и во втором случае одинаковый в котором находится локейшен куда стучаться дальше http://192.168.1.1:1900/igd.xml
В следующем запросе GET по высше указанному адрессу, различия в userAgent
acestream - MSWindows/6.1.7601, UPnP/1.0, MiniUPnPc/1.8
utorrent - Microsoft-Windows/6.1 UPnP/1.0
и что то сдаётся мне причина может быть гдето здесь, т.к. после этого ответы роутера уже отличаются.
в случае с айсом приходит ответ с статусом 200 , тоесть как бы ОК но тела в нем нету, а у торента приходит ответ с XML кой в которой указан новый путь куда долбиться в данном случае /13f.xml, куда он потом и совершает GET, а айсстрим же идет на http://192.168.1.1:1900/ipc с тем же UA и в ответах xml опять не получает, только статус 200.
Можноли самостоятельно, где то в конфиг файлах подправить UA для эксперемента?

Ещё заметил, что при запросе отсутствует заголовок Accept: text/xml, application/xml
И это может быть даже более вероятной причиной пустого ответа.

Не исключено, что проблема обратная - на роутере слишком старая версия (mini)upnpd. Проще всего, конечно, просто обновить прошивку роутера (кстати, я на сайте ТР-Линка “3.13.11 Build 121102” версии софта не нашел - возможно, что совсем старые версии они убрали из загрузок).

Эта версия в своё время была взята с форума тех поддержки этого роутера, в официальных релизах её возможно и не было. Но я повторюсь, она стабильна. Если бы эта проблема была с другим софтом, я бы даже не писал сюда, а разбирался бы сначала с железкой.
А на сколько проблематично добавить заголовок Accept: text/xml, application/xml в первый запрос после search запроса? Насколько я понимаю этот заголовок сообщает серверу с чем клиент хочет работать.
Я к стати нашёл файл (miniupnpc.pyd) в котором проскакивает инфа о заголовках, насколько понимаю, это питоновский скомпиленный файл, следовательно просто в него этот заголовок не забъешь.

Да к стати, если я сильно занудил этот вопрос :), вы скажите… останусь тогда на ручном варианте. :slight_smile:

Все правильно, но вопрос больше не в том, что “не забьешь”, а в том, что мы используем готовую (miniupnpc) библиотеку - т.е как ее автор решил, такие заголовки она и шлет.

В целом мы заинтересованы в том, чтобы с upnp было как можно меньше проблем, но если пользователь сознательно использует софт старых версий (в котором именно с upnp могут быть проблемы), то тут мы врядли чем поможем.
Для проверки можно попробовать файл из вложения - это upnp клиент, собранный из свежих исходников (проще всего проверять в виндовой версии, остановив движок и заменив в “lib” оригинальный файл).


С новой версией библиотеки miniupnpc.pyd изменений нет, но их и не может быть, т.к. там используются все те же заголовки, что и на предыдущей.
Benny, я вам в личку скинул сообщение.

Benny, вопрос почти решился. Правда, проблема оказалась, таки не в заголовке, но его добавление помогло выявить истинную причину. Проблема кроется в ошибке парсера xml на роутере, а происходит эта ошибка из за поля (его шлет miniupnp когда договаривается с роутером) в этом поле лежит значение “AceStream port 8651 -> 8651” и из за стрелочки а точнее из за “>” парсер сходит с ума видимо думая что тег закрылся. Я правда еще не успел разобраться, вы это значение передаете через API или библиотека формирует, если нужно завтра добью, но пока в файле upnpccommands.c (line:373) и miniupnpc-libevent.c(line:1012) убрал переменные в условном операторе оставив только стринг по умолчанию и все завелось.

ЗЫ.
Я ж говорил что я дотошный :slight_smile:

Ну вроде разобрался окончательно.
Строка таки передается вашим движком, при вызове методов UPNP_*. Я бы посоветовал использовать для символов - html сущности.
Например красиво выглядит так


"AceStream port 8621 &rArr; 8621" 

AceStream port 8621 ⇒ 8621 - в таком варианте ошибок возникать не будет (ну или не должно :slight_smile: )

И да под виндой библиотеку таки не собрал пока, делал под убунтой, долго искал откуда она распаковывается при запуске движка…
Осталось разобраться как это теперь под андройд сделать, на тут случай если у вас правок не предвидится в ближайшее время.