NetBSD: ошибка "connect: No route to host" для протокола SOCKS5
Closed this issue · 4 comments
Добрый!
Планирую использовать ciadpi с "качалкой" для ютуба yt-dlp https://github.com/yt-dlp/yt-dlp . Запуск строкой:
./ciadpi --split 1 --disorder 3+s --mod-http=h,d --auto=torst --tlsrec 1+s -p 10801 --debug 1
Сама ошибка(выдаётся в повторе 5-6 раз):
accept: fd=4
resolve: www.youtube.com
connect: No route to host
ss error: 65
close: fd=4 (pair=-1), recv: 0, rounds: 0
Тестовый пример:
yt-dlp "https://www.youtube.com/watch?v=9bZkp7q19f0" -F --proxy=socks5://127.0.0.1:10801
выдаёт несколько ошибок формата:
[youtube] Unable to download API page: <urlopen error [Errno 4] Host unreachable> (caused by ProxyError('<urlopen error [Errno 4] Host unreachable>'));
Если использовать протокол SOCKS4, то вроде бы всё работает:
yt-dlp "https://www.youtube.com/watch?v=9bZkp7q19f0" -F --proxy=socks4://127.0.0.1:10801
accept: fd=4
new conn: fd=5, addr=172.217.24.46:443
host: www.youtube.com (127)
split: pos=0-1 (1), m: DESYNC_SPLIT
split: pos=1-130 (129), m: DESYNC_DISORDER
send: pos=130-517
close: fd=5 (pair=4), recv: 251323, rounds: 2
close: fd=4 (pair=5), recv: 1059, rounds: 2
accept: fd=4
new conn: fd=5, addr=172.217.24.46:443
host: www.youtube.com (127)
split: pos=0-1 (1), m: DESYNC_SPLIT
split: pos=1-130 (129), m: DESYNC_DISORDER
send: pos=130-517
close: fd=5 (pair=4), recv: 23098, rounds: 2
close: fd=4 (pair=5), recv: 1860, rounds: 2
accept: fd=4
new conn: fd=5, addr=172.217.24.46:443
host: www.youtube.com (127)
split: pos=0-1 (1), m: DESYNC_SPLIT
split: pos=1-130 (129), m: DESYNC_DISORDER
send: pos=130-517
close: fd=5 (pair=4), recv: 7754, rounds: 2
close: fd=4 (pair=5), recv: 1729, rounds: 2
accept: fd=4
new conn: fd=5, addr=172.217.24.46:443
host: manifest.googlevideo.com (127)
split: pos=0-1 (1), m: DESYNC_SPLIT
split: pos=1-130 (129), m: DESYNC_DISORDER
send: pos=130-517
close: fd=5 (pair=4), recv: 10645, rounds: 2
close: fd=4 (pair=5), recv: 2074, rounds: 2
Скачивал дистрибьютивы ciadpi и yt-dlp для винды - там всё работает без ошибок.
Если брать видео с Vimeo, то для части хостов всё норм, для части нет:
yt-dlp "https://vimeo.com/55687625" -F --proxy=socks5://127.0.0.1:10801
accept: fd=4
resolve: vimeo.com
new conn: fd=7, addr=162.159.128.61:443
host: vimeo.com (127)
split: pos=0-1 (1), m: DESYNC_SPLIT
split: pos=1-130 (129), m: DESYNC_DISORDER
send: pos=130-517
close: fd=7 (pair=4), recv: 8089, rounds: 2
close: fd=4 (pair=7), recv: 1010, rounds: 2
accept: fd=4
resolve: vimeo.com
new conn: fd=7, addr=162.159.138.60:443
host: vimeo.com (127)
split: pos=0-1 (1), m: DESYNC_SPLIT
split: pos=1-130 (129), m: DESYNC_DISORDER
send: pos=130-517
close: fd=7 (pair=4), recv: 7069, rounds: 2
close: fd=4 (pair=7), recv: 1207, rounds: 2
accept: fd=4
resolve: api.vimeo.com
new conn: fd=7, addr=162.159.138.60:443
host: api.vimeo.com (127)
split: pos=0-1 (1), m: DESYNC_SPLIT
split: pos=1-130 (129), m: DESYNC_DISORDER
send: pos=130-517
close: fd=7 (pair=4), recv: 8124, rounds: 2
close: fd=4 (pair=7), recv: 1642, rounds: 2
accept: fd=4
resolve: api.vimeo.com
new conn: fd=7, addr=162.159.128.61:443
host: api.vimeo.com (127)
split: pos=0-1 (1), m: DESYNC_SPLIT
split: pos=1-130 (129), m: DESYNC_DISORDER
send: pos=130-517
close: fd=7 (pair=4), recv: 8106, rounds: 2
close: fd=4 (pair=7), recv: 1642, rounds: 2
accept: fd=4
resolve: player.vimeo.com
new conn: fd=7, addr=162.159.128.61:443
host: player.vimeo.com (127)
split: pos=0-1 (1), m: DESYNC_SPLIT
split: pos=1-130 (129), m: DESYNC_DISORDER
send: pos=130-517
close: fd=7 (pair=4), recv: 7376, rounds: 2
close: fd=4 (pair=7), recv: 1889, rounds: 2
accept: fd=4
resolve: vod-adaptive-ak.vimeocdn.comconnect: No route to host
ss error: 65
close: fd=4 (pair=-1), recv: 0, rounds: 0
accept: fd=4
resolve: skyfire.vimeocdn.com
new conn: fd=7, addr=151.101.28.217:443
host: skyfire.vimeocdn.com (127)
split: pos=0-1 (1), m: DESYNC_SPLIT
split: pos=1-130 (129), m: DESYNC_DISORDER
send: pos=130-517
close: fd=7 (pair=4), recv: 5302, rounds: 3
close: fd=4 (pair=7), recv: 1219, rounds: 3
accept: fd=4
resolve: vod-adaptive-ak.vimeocdn.comconnect: No route to host
ss error: 65
close: fd=4 (pair=-1), recv: 0, rounds: 0
accept: fd=4
resolve: skyfire.vimeocdn.com
new conn: fd=7, addr=151.101.28.217:443
host: skyfire.vimeocdn.com (127)
split: pos=0-1 (1), m: DESYNC_SPLIT
split: pos=1-130 (129), m: DESYNC_DISORDER
send: pos=130-517
close: fd=7 (pair=4), recv: 7247, rounds: 3
close: fd=4 (pair=7), recv: 1194, rounds: 3
dig для всех хостов с ошибкой выдаёт корректные данные, ping до них тоже работает. Сам по себе yt-dlp(без прокси через ciadpi) то же по чуть-чуть качает. Маршрутизация на хосте просто до роутера настроена, без всяких заумничеств. Пробовал обычную "качалку" curl, для ютуба такая же ситуация c ошибкой connect: No route to host, правда сообщение об ошибке выглядит почему-то иначе, без строчки resolve:
curl --proxy socks5://127.0.0.1:10801 "https://www.youtube.com/watch?v=9bZkp7q19f0" -o test
accept: fd=4
connect: No route to host
ss error: 65
close: fd=4 (pair=-1), recv: 0, rounds: 0
ошибка в самом curl
curl: (97) cannot complete SOCKS5 connection to www.youtube.com. (4)
Собирал из исходников для NetBSD 9.3(обновлена), крутящейся на RPI2, без ошибок и предупреждений. Cистема:
uname -a
NetBSD ppi 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug 4 15:30:37 UTC 2022 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/GENERIC evbarm
Думаю дело в IPv6. Он у вас работает? Попробуйте использовать curl с опцией -4. После последних коммитов программа показывает адрес в логах, перед вызовом connect, так что можете собрать программу с ними и посмотреть куда идет подключение.
@hufrea Нет, IPv6 адреса никак не настраивались, но для curl, действительно, использование опции -4 помогает, а для yt-dlp опция --force-ipv4 почему-то не работает, адрес действительно IPv6 используется
accept: fd=4
resolve: www.youtube.com
new conn: fd=7, pair=4, addr=2404:6800:4006:804::200e:443
connect: No route to host
ss error: 65
close: fd=4 (pair=-1), recv: 0, rounds: 0
Правильно понимаю, что это проблема самой yt-dlp?
Правильно понимаю, что это проблема самой yt-dlp?
Не совсем. Он пытается резолвить адрес через socks. Так что проблема в getaddrinfo (он почему-то возвращает IPv6 адрес, даже если машина к нему подключиться не может). В ciadpi есть опция --no-ipv6, как раз для подобных случаев.