Jump to content

Cha-Cha

Forum Members
  • Content count

    49
  • Joined

  • Last visited

  • Days Won

    1

Cha-Cha last won the day on September 15 2016

Cha-Cha had the most liked content!

Community Reputation

10 Good

About Cha-Cha

  • Rank
    Member

Equipment

  • Keenetic
    Zyxel Keenetic Giga III
  1. Дело НЕ в приводе, пробовал 3 варианта, поведение одинаково: ultra iso, Power dvd, Daemon tools. Вылетает далеко не сразу, через час с лишним просмотра. То есть после половину с чем-то от самого iso файла.
  2. 3d рипы не есть хорошо, мне нужна полная стереопара, так что не вариант, тем более по dlna они не очень и идут. И рипы смотреть на телевизоре 4к не очень, только ремуксы если.
  3. Я часто большие файлы гоняю по smb, iso образы правда только большие(>=30gb), dvd не пробовал. Ну там собственно на роутере что-то нехорошее летит, в логах это есть(в скрытом сообщении), да и в вырезке(в первом) тоже. Можно конечно попробовать, но смысл... Вылетает кстати всегда, на разных iso в разное время, но из последних 3х раз на всех 3х так фильм в bd3d досмотреть и не удалось
  4. Он же монтируется в виртуальный привод и к нему идёт обращение как к обычному, то есть посекторно в случае Blu-Ray Video. Поэтому кеш здесь только в самом плеере и smb для чтения iso с роутера, но он минимален. Меня больше удивляет, что диск вообще вываливается из привода, но наверное это защита драйвера в случае exception при чтении.
  5. Имею проблему. Воспроизводится стабильно. Есть флешка в ntfs, на которой расположен большой iso файл ~ 30 GB. Флешка как windows сетевой диск подключена на клиентском ПК, который монтирует iso диск для воспроизведения. В некоторых местах при чтении файла(blu ray с фильмом) диск отваливается, причем так, что вываливается из виртуального привода. Грешил на программу, но дело видимо не в ней, потому что тот же файл напрямую с подключенной флешки(также смонтированный) нормально работает. Может быть что-то в windows самой, но посмотрите Логи в следующем сообщении. Кажется вот где падает: (+там какие-то ошибки в dhcp клиенте есть(он рестартует), не знаю связано или нет).
  6. исправлено

    Наверное, сложно сказать. Тут вылет при двух и более http proxy стабильный.
  7. исправлено

    Добрый день. В новой сборке перестало работать. Селф-тест + логи ниже прикрепил.
  8. Добрый день. Подскажите откуда берётся хеш, который хранится в конфиге для пароля пользователя: password md5 <HASH> В документации написано - md5 от строки вида "Пользователь:ndm:Пароль" Проверял - не оно. Для ntlm значения соответствует, правда там хеш берется от просто пароля. Скажите как оно на самом деле и в доках по возможности обновите, пожалуйста.
  9. Ок, спасибо. Так действительно логичнее. А в чем проблема при прямом доступе не разбирались?
  10. Добавил, как указано там.
  11. Светить не хочется всем логи в открытую, хоть и без паролей. Работает.
  12. Давайте и правда по делу), хватит наездов обоюдных. P. S. Не моя работа проводить диагностику стороннего продукта. Хотя я таки это и сделал, о чем есть информация выше. Все, что запросят разработчики ещё - будет предоставлено. Ошибка идёт именно при обращении с wan provider ip-> wan provider ip при работе через облако. При остальных сценариях, будь то local ip - > wan provider ip, local ip -> local dns name keenetic проблемы нет. С чем тут сложно не согласиться, так это только с тем, что ошибку выдаёт nginx скорее всего, error_log могут крутануть для transmission только разработчики. P. P. S. Хотя 400 ошибка не дефолтная для nginx, внизу нет его подписи, либо её разработчики сами кастамизировали. Может быть и transmission все же. P. P. S. Ну и напоследок для вас. Чтобы успокоился. Все что можно я посмотрел, но ничего, что говорит о причине там нет,поэтому и смысла что-то добавлять в тему тоже нет.
  13. надо бы на 400-й и дамп пакетов с wan Ваша цитата. Давайте тащите и декодируйте налету. ой, или вы это предполагали, ай-ай-ай, недописали, а ещё наверное вы хотели сказать про tcpdump в entware, где можно посмотреть и wan, и local сразу. Комментарии излишни. Такой смешной ВЫ ей богу, я вам сам пишу про udp, а вы мне это повторяете. Хорошо, что загуглили, похвально. Дальше давайте по делу. tcpdump к слову уже на entware на всех интерфейсах говорит о том, что запросы одинаковые(почти, да и при одинаковых тоже самое, проверялось). На локальный ip - ответ transmission нормальный. На ip провайдера(при облачном режиме обращение идёт также с этого ip провайдера) - 400, и я очень сомневаюсь, что это отвечает сам трансмиссион, потому что в его логах ошибок нет, хотя на порту больше никто вроде бы не висит 8090, но тогда это ещё страннее.
  14. При случае работы с облаком будет виден только udp трафик. Никаких запросов в открытом виде там не будет. К слову на трансмиссион он в итоге так и не попадает, так что затык именно в облаке. Если бы в чём-то другом, без ваших познаний в прокси уже бы давно обошлись) Учите матчасть, хотя бы изучите как работает в случае с keendns через облако и как напрямую, и какой трафик вы увидите на интерфейсе.
  15. Вам же написали bad request 400 возвращается. При локальном заходе такой проблемы нет, какие тут запросы, причём тут это, блин пишите по делу, я неплохой сетевик, и вашу пургу читать не хочется. Что вы собираетесь в pcap увидеть? В self-test к слову ничего нет с намеком на ошибки.
×