Тест с curl показывает результаты.
На всех устройствах видео нормально показывает минут 5-8
UDP порты заблокированы
Openwrt routerich
Помогите кто чем может
Команда NFQWS_OPT_DESYNC=“–dpi-desync=fake,split2 --dpi-desync-autottl=1:1-10 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin”
И
Учитывая, что все ваши стратегии дают одинаковый результат, возможно проблема не в них?
У меня было нечто похожее - сервера провайдера тормозили. Проблем на канале между мной и ими не было, а вот между ними и внешней сетью - были. В итоге они не кэшировали видео нормально. Помогло заблочить их через юблок тупо.
Посмотрите куда у вас коннектится ютуб через f12 - сеть. Какая там группа серверов от вашего провайдера - ту попробуйте заблочить временно.
Для предварительного эксперимента можете сделать так. Зайдите на https://redirector.googlevideo.com/report_mapping?di=no. Там будет название вашего кластера, типа rostelekom-abc1. Потом пробейте пингом его айпи вот так rr1.названиекластера.googlevideo.com. Потом дальше rr2 rr3 и т.д. пока не упретесь в ошибки. А потом просто заблочьте все эти айпи для теста и гляньте что будет.
Видимо это связано с очередным изменением правил. У меня сегодня сработало разделение комбоправила на два отдельных:
–dpi-desync=split2 --dpi-desync-split-pos=1 --dpi-desync-fooling=md5sig --hostlist=/opt/zapret/youtube.txt --new --dpi-desync=split2 --dpi-desync-split-seqovl=1 --dpi-desync-fooling=badsum --hostlist=/opt/zapret/googlevideo.txt
то что до --new отвечает за морду ютуба, а то что после --new - это правило для самого видео и в файле googlevideo.txt только домен googlevideo.com
Установил youtubeunblock и опять тоже самое 5-10 минут и зависает.
Не встречалось ли кому такое поведение ТСПУ?
Или не может это быть хардверный косяк роутера? (сбоит проц/память/ святой дух)?
