Tpws не помогает решить проблему со смарт тв LG, Samsung (не Android)

[ghost]

^subj. Удалено ибо проблему решать видимо никто не хочет.

[bol-van]

tpws --socks
by default it runs in transparent mode and cant be used as proxy
in transparent mode it needs iptables with dnat redirect or tproxy

[bol-van]

нельзя использовать прозрачный режим как явный прокси
там совершенно разная логика

[bol-van]

--debug пишет только в консоль
с --daemon он бесполезен

на счет копирования. можно прямо в опт гит клонировать
копирования не будет. оно сделано чтобы скопировать из tmpfs только минимум
такова особенность опенврт. мало места на диске. гит не влезет

а насчет философии. если сделать инструкцию пошаговой, то это снизит порог входа
но окажется что юзера совершенно беспомощны при любой нештатной ситуации
и специфика вопроса такова, что сделать пошагово не понимая вопроса может не получиться
мне за это не платят чтобы сидеть целый день и отвечать на глупые вопросы

потому я принял решение писать в понятийном варианте
не нажмите вот тут , а сделайте осмысленное действие
поймите зачем и что оно дает

это отсеивает нежелательную для меня аудиторию
кому интересен сам вопрос , с тем мне обычно интересно пообщаться
а с нажимателями нет

[bol-van]

про та многие пишут, что не работает. мне не на чем проверить
если тпвс вообще без дурения запустить, тв работает ?

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

[bol-van]

service есть в openwrt
но можно и через /etc/init.d/zapret stop|start

[EgorKin]

pws не работает с UDP. есть ли действительно quic можно посмотреть в tcpdump
udp port 443

снял дамп, UPD 443 и 80 были не заблочены. Интерфейс офф клиента youtube не грузится. (с их DROP через iptables тоже не грузится). запущен tpws --daemon --bind-addr 192.168.1.10 --port 999 --tlsrec=sni --hostspell=HOsT --split-http-req=method --split-pos=2 --hostlist=/etc/tpws-hostlist.txt --pidfile $PIDFILE

на него силами iptables редиректятся tcp 80 и 443

ну и судя по дампу UPD 443 все таки используется:

19:51:04.086276 IP 192.168.1.219.56423 > arn11s12-in-f10.1e100.net.https: UDP, length 1250 19:51:04.086470 IP 10.255.59.190.56423 > arn11s12-in-f10.1e100.net.https: UDP, length 1250 19:51:04.086568 IP 192.168.1.219.56423 > arn11s12-in-f10.1e100.net.https: UDP, length 1250 19:51:04.086767 IP 192.168.1.219.33446 > arn11s12-in-f10.1e100.net.https: Flags [S], seq 3306626556, win 65535, options [mss 1460,sackOK,TS val 481826279 ecr 0,nop,wscale 6], length 0 19:51:04.086847 IP 192.168.1.219.33446 > arn11s12-in-f10.1e100.net.https: Flags [S], seq 3306626556, win 65535, options [mss 1460,sackOK,TS val 481826279 ecr 0,nop,wscale 6], length 0 19:51:04.087099 IP arn11s12-in-f10.1e100.net.https > 192.168.1.219.33446: Flags [S.], seq 2095017534, ack 3306626557, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 0], length 0 19:51:04.087183 IP arn11s12-in-f10.1e100.net.https > 192.168.1.219.33446: Flags [S.], seq 2095017534, ack 3306626557, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 0], length 0

Я конечно совсем не сетевик и может тут как раз видно что по UDP оно не получило ответ и перешло на HTTPS по которому ответ получен?

Вот похоже запрос на проверку соединения
19:51:04.278192 IP 192.168.1.219.41130 > lr-in-f94.1e100.net.http: Flags [P.], seq 1004941572:1004941760, ack 3307604214, win 1024, length 188: HTTP: HEAD /generate_204 HTTP/1.1 E....T@[email protected].^...P;.1..&..P.......HEAD /generate_204 HTTP/1.1 Host: connectivitycheck.gstatic.com Connection: keep-alive User-Agent: CrKey/3.72.425634 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9

Только я ответ не вижу, разве что это
19:51:04.284247 IP arn11s12-in-f10.1e100.net.https > 10.255.59.190.52016: Flags [.], ack 2035, win 268, length 0 E..(....z.__..J. .;....0^y.MP...P...?m..

Но попытки сделать запросы по UDP 443 он не бросил:
19:51:04.401923 IP 192.168.1.219.56423 > arn11s12-in-f10.1e100.net.https: UDP, length 1250

а вот ответов на UDP 443 запросы я не нашел
хотя к другим доменам по иным портам по UDP обмен идет успешно

Есть кстати что-то про UI youtube (что примечательно они идут по IP6):
19:51:04.134863 IP6 fe80::9ec5:6f14:9ee5:d28d.40556 > fe80::560d:f9ff:fed0:8ced.domain: 62319+ A? www.youtube.com. (33) 19:51:04.134968 IP6 fe80::9ec5:6f14:9ee5:d28d.40556 > fe80::560d:f9ff:fed0:8ced.domain: 62319+ A? www.youtube.com. (33) 19:51:04.135571 IP 10.255.59.190.45704 > ns1.xn--80aana1acrwhec.xn--p1ai.domain: 19710+ A? www.youtube.com. (33) 19:51:04.135958 IP 10.255.59.190.52016 > arn11s12-in-f10.1e100.net.https: Flags [P.], seq 3:549, ack 1, win 1700, length 546 19:51:04.137116 IP ns1.xn--80aana1acrwhec.xn--p1ai.domain > 10.255.59.190.45704: 19710 3/4/8 CNAME youtube-ui.l.google.com., CNAME wide-youtube.l.google.com., A 142.251.170.198 (358) 19:51:04.137855 IP6 fe80::560d:f9ff:fed0:8ced.domain > fe80::9ec5:6f14:9ee5:d28d.40556: 62319 3/4/8 CNAME youtube-ui.l.google.com., CNAME wide-youtube.l.google.com., A 142.251.170.198 (358) 19:51:04.137985 IP6 fe80::560d:f9ff:fed0:8ced.domain > fe80::9ec5:6f14:9ee5:d28d.40556: 62319 3/4/8 CNAME youtube-ui.l.google.com., CNAME wide-youtube.l.google.com., A 142.251.170.198 (358)
кажется это ответы:
19:51:09.131333 IP6 fe80::9ec5:6f14:9ee5:d28d > fe80::560d:f9ff:fed0:8ced: ICMP6, neighbor solicitation, who has fe80::560d:f9ff:fed0:8ced, length 32 19:51:09.131567 IP6 fe80::9ec5:6f14:9ee5:d28d > fe80::560d:f9ff:fed0:8ced: ICMP6, neighbor solicitation, who has fe80::560d:f9ff:fed0:8ced, length 32 19:51:09.132182 IP6 fe80::560d:f9ff:fed0:8ced > fe80::9ec5:6f14:9ee5:d28d: ICMP6, neighbor advertisement, tgt is fe80::560d:f9ff:fed0:8ced, length 24 19:51:09.132468 IP6 fe80::560d:f9ff:fed0:8ced > fe80::9ec5:6f14:9ee5:d28d: ICMP6, neighbor advertisement, tgt is fe80::560d:f9ff:fed0:8ced, length 24

В общем взглянуть бы Вам самим на AndroidTV что происходит, а я совсем не спец по сетям.

[bol-van]

у меня нет android tv.
чтобы оценить происходящее, нужен дамп с внутреннего и внешнего интерфейса с включенным tpws и лог tpws --debug=2
quic можно заблокировать средствами роутера (не сток). блок udp:443 на выход

[EgorKin]

iptables -A FORWARD -p udp --dport 443 -j DROP
iptables -A FORWARD -p udp --dport 80 -j DROP

не меняют ситуацию никак - на ТВ интерфейс YouTube также не грузится, на остальных устройствах в сети всё так же грузится и видео воспроизводится.
pktDump.cap дамп могу скинуть на почту, сделан через веб-интерфейс роутера (там есть вкладка для разработчиков с соотв. кнопкой) когда на нем был запущен tpws. tcpdump -r pktDump.cap его успешно обрабатывает. Дамп без tpws но с включенным VPN для прогрузки интерфейса YouTube сделать не могу т.к. VPN не на роутере, а через телефон. tpws --debug 2 сейчас нет т.к. он запускается в режиме --daemon.
Если нужен .cap - напишите на почту из моего профиля тут, вышлю в ответном сообщении.

[dkipkaev]

UPD: Поставил youtubeUnblock, отлично работает телевизор с параметрами из issue 59 Waujito/youtubeUnblock#59
Asus RT-N11P, OpenWRT 22.03.7. Старенький роутер, уже 10 лет ему, валялся без дела. Вроде попадает под предупреждение 4/32, но работает.
К Wi-Fi не подключиться, но он и не нужен. Просто от основного роутера стоит прокладкой перед телевизором по схеме: Роутер (основной) — кабель — роутер Asus — кабель — ТВ.