LINUX.ORG.RU

Лор не открывается с мобилки ERR_TIMED_OUT

 , , ,


0

1

UDP: Причина в MTU или чём то косвенно/явно с этим связанным. ЯННП. Path MTU Discovering Black Hole причина вроде.

UDP2: Да это оно

This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interface’s MTU minus 40 for IPv4 or 60 for IPv6, respectively). Of course, it can only be used in conjunction with -p tcp. It is only valid in the mangle table. This target is used to overcome criminally braindead ISPs or servers which block "ICMP Fragmentation Needed" or "ICMPv6 Packet Too Big" packets. The symptoms of this problem are that everything works fine from your Linux firewall/router, but machines behind it can never exchange large packets:
1) Web browsers connect, then hang with no data received.
2) Small mail works fine, but large emails hang.
3) ssh works fine, but scp hangs after initial handshaking.
Workaround: activate this option and add a rule to your firewall configuration like:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu

--set-mss value
Explicitly set MSS option to specified value.

--clamp-mss-to-pmtu
Automatically clamp MSS value to (path_MTU - 40 for IPv4; -60 for IPv6).

Установил пока MSS на минимально возможный

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Скорость закачки норм.

Testing download speed................................................................................
Download: 85.27 Mbit/s
Testing upload speed......................................................................................................
Upload: 93.89 Mbit/s

И это при 30 Mbit/s который мне провайдер предоставляет, он же виноват в проблеме. Ко мне не приходят IMCP пакеты с требованием о фрагментации пров их режет на кой то хер, ну я так понял ибо я их не вижу в tcpdump. (вижу, но не те). Ладно может кому пригодится. Фух. Хоть теперь относительно понятно.


В чём может быть причина? Пк->wifi свисток->мобилка. Из termux linux.org.ru пингуется. Но с браузера не заходит. Да, другие сайты работают. Опенннет например и прочие гуглы. wget в termux останавливается на connected. Что-то не то с сертификатами? Lynx тоже не открывает из termux. С основного пк, вот сейчас пишу всё нормально.

Межсетевые экраны отключены. nftables,iptables чистые.

★★★★★

Последнее исправление: LINUX-ORG-RU (всего исправлений: 5)

Что-то не то с сертификатами?

вряд ли

но на всякий случай попробуй

openssl s_client -connect linux.org.ru:443
Harald ★★★★★
()
Ответ на: комментарий от Harald
$ umame -a
No command umame found, did you mean:
 Command uname in package coreutils
$ uname -a
Linux localhost 3.18.19+ #1 SMP PREEMPT Wed Apr 3 19:36:11 KST 2019 armv7l Android
$ openssl s_client -connect linux.org.ru:443
CONNECTED(00000003)

И всё висит, дальше ничего.

Я слыхал что какая то трабла с корневыми сертификатами была и старые дроиды типа 2,3 не могут половину интернета отрывать ибо в трабле замешан letsencrypt. Но у меня 6,0 андрюшка

$ termux-info 
Packages CPU architecture:
arm
Subscribed repositories:
# sources.list
deb https://termux.net stable main
# game-repo (sources.list.d/game.list)
deb https://dl.bintray.com/grimler/game-packages-21 games stable
# science-repo (sources.list.d/science.list)
deb https://dl.bintray.com/grimler/science-packages-21 science stable
Updatable packages:
All packages up to date
Android version:
6.0
Kernel build information:
Linux localhost 3.18.19+ #1 SMP PREEMPT Wed Apr 3 19:36:11 KST 2019 armv7l Android
Device manufacturer:
LGE
Device model:
LG-K350
$ 

Вот что в tcpdump по wifi интерфейсу и адресу телефончика во время выполненияopenssl s_client -connect linux.org.ru:443

dron@gnu:~$ sudo tcpdump -i wlx6466b318bace host 10.42.0.233
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlx6466b318bace, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:12:01.896617 IP gnu.56520 > 10.42.0.233.8022: Flags [P.], seq 1405699504:1405699548, ack 2639997470, win 501, options [nop,nop,TS val 4178311266 ecr 24445794], length 44
20:12:02.000155 IP 10.42.0.233.8022 > gnu.56520: Flags [P.], seq 1:85, ack 44, win 407, options [nop,nop,TS val 24446144 ecr 4178311266], length 84
20:12:02.000211 IP gnu.56520 > 10.42.0.233.8022: Flags [.], ack 85, win 501, options [nop,nop,TS val 4178311369 ecr 24446144], length 0
20:12:02.178103 IP 10.42.0.233.45108 > 178.248.233.6.https: Flags [F.], seq 584274208, ack 1445175619, win 352, options [nop,nop,TS val 24446162 ecr 3641194222,nop,nop,sack 1 {2897:4184}], length 0
20:12:03.756012 IP gnu > 10.42.0.233: ICMP echo request, id 48015, seq 1, length 64
20:12:03.833659 IP 10.42.0.233 > gnu: ICMP echo reply, id 48015, seq 1, length 64
20:12:03.863380 IP 10.42.0.233.43036 > lq-in-f94.1e100.net.https: Flags [FP.], seq 1442454837:1442454868, ack 3252403628, win 399, options [nop,nop,TS val 24446218 ecr 1300489796], length 31
20:12:03.944535 IP gnu.56520 > 10.42.0.233.8022: Flags [P.], seq 44:80, ack 85, win 501, options [nop,nop,TS val 4178313314 ecr 24446144], length 36
20:12:03.947127 IP 10.42.0.233.8022 > gnu.56520: Flags [P.], seq 85:121, ack 80, win 407, options [nop,nop,TS val 24446226 ecr 4178313314], length 36
20:12:03.947181 IP gnu.56520 > 10.42.0.233.8022: Flags [.], ack 121, win 501, options [nop,nop,TS val 4178313316 ecr 24446226], length 0
20:12:04.887004 IP 10.42.0.233.45109 > 178.248.233.6.https: Flags [S], seq 4115025353, win 65535, options [mss 1460,sackOK,TS val 24446253 ecr 0,nop,wscale 8], length 0
20:12:04.896673 IP 178.248.233.6.https > 10.42.0.233.45109: Flags [S.], seq 238156078, ack 4115025354, win 5792, options [mss 1460,nop,wscale 9,sackOK,TS val 3641249083 ecr 24446253], length 0
20:12:04.897881 IP 10.42.0.233.45109 > 178.248.233.6.https: Flags [.], ack 1, win 343, options [nop,nop,TS val 24446256 ecr 3641249083], length 0
20:12:04.898104 IP 10.42.0.233.8022 > gnu.56520: Flags [P.], seq 121:181, ack 80, win 407, options [nop,nop,TS val 24446256 ecr 4178313316], length 60
20:12:04.898161 IP gnu.56520 > 10.42.0.233.8022: Flags [.], ack 181, win 501, options [nop,nop,TS val 4178314267 ecr 24446256], length 0
20:12:04.899229 IP 10.42.0.233.45109 > 178.248.233.6.https: Flags [P.], seq 1:315, ack 1, win 343, options [nop,nop,TS val 24446256 ecr 3641249083], length 314
20:12:05.902407 IP 10.42.0.233.45109 > 178.248.233.6.https: Flags [P.], seq 1:315, ack 1, win 343, options [nop,nop,TS val 24446279 ecr 3641249083], length 314
20:12:05.913286 IP 178.248.233.6.https > 10.42.0.233.45109: Flags [.], ack 315, win 60, options [nop,nop,TS val 3641250123 ecr 24446279,nop,nop,sack 1 {1:315}], length 0
20:12:08.759328 IP gnu > 10.42.0.233: ICMP echo request, id 39301, seq 1, length 64
20:12:08.953521 IP 10.42.0.233 > gnu: ICMP echo reply, id 39301, seq 1, length 64
20:12:09.907281 IP 178.248.233.6.https > 10.42.0.233.45109: Flags [F.], seq 4184, ack 315, win 60, options [nop,nop,TS val 3641254118 ecr 24446279], length 0
20:12:09.914847 IP 10.42.0.233.45109 > 178.248.233.6.https: Flags [.], ack 1, win 343, options [nop,nop,TS val 24446355 ecr 3641249083,nop,nop,sack 1 {4184:4185}], length 0
20:12:13.766003 IP gnu > 10.42.0.233: ICMP echo request, id 4897, seq 1, length 64
20:12:13.867988 IP 10.42.0.233 > gnu: ICMP echo reply, id 4897, seq 1, length 64
20:12:18.758371 IP gnu > 10.42.0.233: ICMP echo request, id 5151, seq 1, length 64
20:12:18.988841 IP 10.42.0.233 > gnu: ICMP echo reply, id 5151, seq 1, length 64
20:12:23.757116 IP gnu > 10.42.0.233: ICMP echo request, id 13910, seq 1, length 64
20:12:23.903611 IP 10.42.0.233 > gnu: ICMP echo reply, id 13910, seq 1, length 64
20:12:24.063844 IP 10.42.0.233.45108 > 178.248.233.6.https: Flags [F.], seq 0, ack 1, win 352, options [nop,nop,TS val 24446531 ecr 3641194222,nop,nop,sack 1 {2897:4184}], length 0
20:12:24.274316 IP 10.42.0.233.54869 > 203.247.157.116.47005: Flags [F.], seq 3066917628, ack 2157411799, win 65535, length 0
20:12:24.938978 IP 10.42.0.233.43036 > lq-in-f94.1e100.net.https: Flags [FP.], seq 0:31, ack 1, win 399, options [nop,nop,TS val 24446587 ecr 1300489796], length 31
20:12:28.760356 IP gnu > 10.42.0.233: ICMP echo request, id 62684, seq 1, length 64
20:12:29.022967 IP 10.42.0.233 > gnu: ICMP echo reply, id 62684, seq 1, length 64
20:12:30.248680 IP gnu.56520 > 10.42.0.233.8022: Flags [P.], seq 80:116, ack 181, win 501, options [nop,nop,TS val 4178339618 ecr 24446256], length 36
20:12:30.473792 IP 10.42.0.233.8022 > gnu.56520: Flags [P.], seq 181:217, ack 116, win 407, options [nop,nop,TS val 24446693 ecr 4178339618], length 36
20:12:30.473855 IP gnu.56520 > 10.42.0.233.8022: Flags [.], ack 217, win 501, options [nop,nop,TS val 4178339843 ecr 24446693], length 0
20:12:30.474873 IP 10.42.0.233.45109 > 178.248.233.6.https: Flags [F.], seq 315, ack 1, win 343, options [nop,nop,TS val 24446693 ecr 3641249083,nop,nop,sack 1 {4184:4185}], length 0
20:12:30.475747 IP 10.42.0.233.8022 > gnu.56520: Flags [P.], seq 217:261, ack 116, win 407, options [nop,nop,TS val 24446693 ecr 4178339843], length 44
20:12:30.475786 IP gnu.56520 > 10.42.0.233.8022: Flags [.], ack 261, win 501, options [nop,nop,TS val 4178339845 ecr 24446693], length 0
20:12:31.700334 IP 10.42.0.233.45109 > 178.248.233.6.https: Flags [F.], seq 315, ack 1, win 343, options [nop,nop,TS val 24446739 ecr 3641249083,nop,nop,sack 1 {4184:4185}], length 0
20:12:32.439385 IP 10.42.0.233.45109 > 178.248.233.6.https: Flags [F.], seq 315, ack 1, win 343, options [nop,nop,TS val 24446785 ecr 3641249083,nop,nop,sack 1 {4184:4185}], length 0
^C
41 packets captured
41 packets received by filter
0 packets dropped by kernel
dron@gnu:~$ 

Перед рукопожатием должен же вроде маленький файлик скачатся как там его я забыл название и на основе него выполнятся соединение. Но len=0 https://www.youtube.com/watch?v=LWOPpqm5LMA

LINUX-ORG-RU ★★★★★
() автор топика
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)
Ответ на: комментарий от x86-

Да вот я и думаю что что-то с CA сертификатами на устройстве не так. Одни сайты работают другие (кроме лора вроде всё) не работают. Ты на какое устройство lineage накатывала. Сама или брала готовое.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

Убедитесь что в хранилище сертификатов у вас лежит ISRG Root X1 который есть в цепочке на linux.org.ru

openssl s_client -showcerts -connect linux.org.ru:443 </dev/null

slowpony ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Не просто какой-то ISRG Root X1, а конкретно вот тот, который сейчас отдается по https. Их там, вроде как, два разных - один старый, подписанный протухшим DST Root CA X3, а второй - новый, самоподписанный, но отсутствующий в хранилищах на старых устройствах.

slowpony ★★★★★
()
Ответ на: комментарий от slowpony

Так же висит

openssl s_client -showcerts -connect linux.org.ru:443 </dev/null
CONNECTED(00000003)
^C
$ 

Не просто какой-то ISRG Root X1, а конкретно вот тот, который сейчас отдается по https. Их там, вроде как, два разных - один старый, подписанный протухшим DST Root CA X3, а второй - новый, самоподписанный, но отсутствующий в хранилищах на старых устройствах.

Ну значит всё, приехали. Надо рутовать и руками добавлять или перешивать вроде как для GL-K8 есть альтернативы https://www.cyanogenmods.org/forums/topic/lg-k8-lineage-os-15-android-oreo-rom/ но меня смещает то что цианоген вроде как умер. В смысле сайт не левый уже? Да и будет ли всё (или хоть что-то) работать хрен его знает.

Вот тебе и letsencrypt не даром они на халяву свой сервис дают, в следующий раз текущий сертификат им похерят кто и всё половина интернета не работает, вторая под MITM.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

андроид 6

Ну значит всё, приехали. Надо рутовать

А до этого ты как без рута жил на древнющем дырявом ведре?

Вот тебе и letsencrypt не даром они на халяву свой сервис дают, в следующий раз текущий сертификат им похерят

Вот тебе и лоровская аналитика — на дворе 2021 OpenSSL 3.0, у тебя 1.1.0 (даже не какая-нибудь древняя 1.1.1), а виновата, конечно же, абсолютно рандомная сущность.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

А до этого ты как без рута жил на древнющем дырявом ведре?

Никак, у меня кнопочный телефон для телефонных нужд. А лопату подарили. Она для всякого баловства, компиляния и steam guard. Рутовать себе дороже, если только сразу шить на то-то. Openssl у меня в termux 1.1.1b

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от slowpony

Точна? К слову я раньше не замечал, но в андроиде можно сертификат вручную из файла поставить, я взял новый установил, оно конечно ругается что мол вашу сеть могут прослеживать, но лор так и не открылся. Сертификат убрал.

у тебя сетевые проблемки уровнем пониже.

Я недавно удалял gufw и вычищал iptables/nftables от следов присуцтвия. С целью изучить nftables потихоньку. В этом не должно быть проблем. Там всё разрешительное сейчас. И да вчера дебъян обновлялся.

Ты что-то знаешь и хочешь меня пнуть в нужную сторону куда копать. Пни меня и буду копать.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от unicorne

Йяяяя ща не пояял чё эта была? Короче. Пошёл в роутер, понизил mtu до 1492 (дефолт был 1500). Погасил все сети. Удалил на ПК сетевые настройки. Включил роутер, дал Networkmanager`у самому подключится к сети проводной, поднял файлю и всё работает.

MTU на ПК автоматически выставилось в mtu 1280 в termux ip a выдаёт mtu 1500 на всё (кроме локалхоста где 65535).

Я не понял у меня на ПК что является gateway для мобилки MTU ниже чем у мобилки и ниже чем у мобилки и всё работает. Я бы понял если бы было бы наоборот.

Объясните пожалуйста что происходит я не вкуриваю.

PS. 1400 руками задавал, ничего не менялось.

UDP: Одновременно с тем что мобила стала уметь открывать linux.org.ru на ПК теперь не работает синхронизация сохранений в steam.

У меня вопрос господа. Что у меня не так то?

UDP2: 1400 снова задал теперь уже на роутере, дальше дал всему автоматом подняться и вафле и сетефому соединению к роутеру. Вроде всё ок.

Опять вопрос, почему уменьшение размера MTU такую карусель делает?

Нет не ок. При автоматических 1280 забугорные игровые сервера не отвечают. Оставил на роутере 1400 на ПК 1492. И они заработали… Чё бл***?!

LINUX-ORG-RU ★★★★★
() автор топика
Последнее исправление: LINUX-ORG-RU (всего исправлений: 4)
Ответ на: комментарий от LINUX-ORG-RU

Это уже другие вопросы.

А я дал ответ на конкретный вопрос: «В версии Android'а ли дело?».

Так вот, по ходу, не в ней и нужно смотреть дальше. Вот и смотрите, а я пошёл дальше.

saahriktu ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

почему уменьшение размера MTU такую карусель делает

Отвечу ещё на этот вопрос. Чем меньше MTU тем больше становится сетевых пакетов, размер которых подгоняется под заданный MTU.

Чем больше MTU тем крупнее пакеты и тем меньше их нужно для передачи данных, тем меньше расход ресурсов на обработку заголовков пакетов. Но более крупные пакеты могут не проходить там, где выставлен MTU меньше. Не говоря уже о том, что в ряде случаев они могут просто отбрасываться. Но могут и дробиться на более мелкие.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

Да, спасибо я уже читаю. Как хост1 MTU 1500 шлёт 1460 mss с флагом DF, а обратная сторона отклоняет пакет и шлёт обратно ICMP с размером нужного MTU после чего хост1 фрагментирует пакет и шлёт опять уже два три или сколько надо и всё должно работать, но как я полян есть ещё Path MTU тоесть минимально допустимый размер. И если в промежутке стоит железа где PMTU выше чем хост1 фрагментировал для хоста2 то промежуточный сервер их отбросит и снова пошлёт хосту1 IMCP уже с PMTU хост1 перепакует в пакеты большего размера и снова пошлёт, теперь они пройдут, но хост2 опять их отклонит ибо они больше чем его MTU и опять пошлёт ICMP на хост1. И всё рекурсия и «вечное» ожидание до таймаута. Я так понял. Только я не понял пока что мне делать, для работы лора (НГО ВЕДЬ РАНЬШЕ ВСЁ РАБОТАЛО ЖЕ ЛОЛ) надо MTU относительно меня (с учётом промкдуточных серверов моей сети провайдера и дельше) ставить 1400 и всё работает везде хорошо, но отваливаются забгорный игровые сервера valve которые работают только с 1492, но тогда не работет лор, но это же не правильно, всё должно работать бред какой то. Ой я запуталси!!1 =) Пойду дальше читать гугол

Я так понял надо на ПК как то пакеты перелопачивать идущие с мобилки. Ведь мой ПК это шлюз для неё. Ой запутаися в этих сетях, сложна.

LINUX-ORG-RU ★★★★★
() автор топика
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

А почему сервера стима перестают работать? Попробуй написать им в поддержку, может баг какой
минимальный mss/mtu с котрым всё должно ГАРАНТИРОВАННО работать 576 байт

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

Дело вероятно не в их серверах (отваливаются не все а только по штук 20 из https://gist.github.com/fedor-elizarov/772ed6751b58492db1bd83f746184ea5 чаще всего релейные сервера ), а промежуточных маршрутах моего провайдера или дальше. Я в сетях не особо секу, но понял так что где то стоит машинка с малым MTU, а моя машинка просто не получает от неё IMCP пакеты с просьбой их фрагментировать. Режутся пакеты где то до меня. Сейчас у меня MTU 1500 везде проставлено (провода эзернет), но в правилах стоит репак MSS до минимального MTU. При этом как я понял уже не важно стоит или нет DF флаг, любой сервер примет такой пакет и обработает и не будет мне обратно слать IMCP need fragmentation который до меня не доходит чмута. Если я правильно понял то всё так. Конечно можно позвонить провайдеру и сказать мол не режте идущие ко мне пакетики служебные. Или явно указывать окошко MSS постоянно увеличивая найдя оптимальный вариант при котором всё работает. Но мне лень + может я чего не так понял. Пока что всё работает. Роутер с возросшим количеством пакетов справляется вроде.

Я одно не понял, почему в tcpdump два сервера договариваются о mss 1460. А когда собсна начинается обмен данными и сервер шлёт 1300 байт к примеру то у второго MTU 1200 оказывается и он ICMP надофрагментировать обратно шлёт. Это я в опытах наблюдал. Оно же MSS это же данные MTU без служебных, сфигали при соединении он объявляется большим чем возможный MTU. Бред какой то. (или я чего попутал ночью ковыряясь)

LINUX-ORG-RU ★★★★★
() автор топика
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от Shulman

Всё так, а ещё это зависимость. Плюс тусовок окололинуксовых в одновременно и технических и неформальных кот наплакал.

LINUX-ORG-RU ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.