Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

Останавливается загрузка файлов с файловых хостингов

Здравствуйте

Загрузка с различных сервисов (keep2share, katfile, fileboom) идёт до 100% но не может завершиться (т.е. стоит на "103.4mb/103.4mb", например).
DUO-G, поставил только вчера, обновил-сбросил, прошивка 2.7.11.RU.25072020, какие-то настройки кроме PPPoE для дом.ру и пароля от сети пока не трогал.
Проверял разные браузеры (хром и фаерфокс, оба последние обновления); если интернет раздать с телефона закачка успешно завершится

  1. нужно приводить лог что бы я хоть мог видеть что там провайдер при подъёме сессии выдал
  2. такие проблемы (как и недооткрывающиеся местами сайты или недоступность части сайтов) чаще всего свидетельствуют о проблемах с MTU на VPN (PPPOE/PPTP/L2TP). Попробуйте в настройках VPN задать уменьшить MTU руками (для PPPOE 1492 и ниже пока проблема не уйдёт), мож брас ерунду выдаёт при согласовании параметров.
  3. Проверить закачку того же самого телефоном подключенным по wifi тоже не лишним будет. Т.к. иногда антивирусники дуреют и вот так себя ведут. Причём триггер что бы начали дуреть подобным образом ни разу выяснить не удалось. А связь с заменой роутера тут чисто совпадение.
  4. Так же если всё вышеописанное проверено для теста идём на kernel.org и скачиваем оттуда любую верисию ядра. Дабы исключить влияние каких-нить общих cdn используемых перечисленными вами серсиами. Наверняка где-то арендуют они пространство и запросто может быть в одном месте, а причина какие-то временные неполадки на их стороне или на уровне связности сети ЭР-Телеком и сетей в которые влючены cdn`ы этих хостеров. Так что проверяем на заведомо живом хостинге без чудес с нормальным резервированием типа kernel.org

В лоб больше причин не придумывается.

 

Для повторения можете дать ссылку Sadler. Он так же на ДОМ.РУ проверит. И я проверю с РТ ради интереса.

  1. Прикрепляю лог.
  2. пока опускал до 1400, потом ещё попробую. В интернете где-то видел что у дом.ру 1492 должно быть (его пробовал), но лично с техподдержкой ещё не связывался.
  3. проверил, с телефона на домашней сети то же самое. Ну и как я говорил, если скачивать по той же ссылке с мобильного интернета - всё хорошо. С этих хостингов периодически что-то качаю не первый год, кроме роутера за последнюю неделю я точно ничего не менял из железа или софта.
  4. В список хостингов можно добавить mexashare. Могу ещё отметить, что проблема встречается на разных файлах и разных сервисах, и реплицируется, но не всегда (один файл скачался таки с пятого раза. Другой пробовал трижды и ничего.). При этом какие-то другие файлы с этих же сервисов скачиваются нормально, с первого раза. Навскидку, ~10 пробовал качать, ~7 не загрузились.
    А с kernel.org скачивается без проблем. Как и с гугл-драйва. На днях так же успешно скачивал драйвера с двух разных сайтов, т.е. понятно что проблемы распространяются не на совсем все загрузки.

*вот лог

а вот пример файла

Не совсем понял как мне написать Sadler'у
Сделать в теме @ в его сторону?
@sadler

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..
Лог надо бы сразу после загрузки и появления инета.
Цитата: Mikadius от 29/07/2020, 00:03
  1. В список хостингов можно добавить mexashare. Могу ещё отметить, что проблема встречается на разных файлах и разных сервисах, и реплицируется, но не всегда (один файл скачался таки с пятого раза. Другой пробовал трижды и ничего.). При этом какие-то другие файлы с этих же сервисов скачиваются нормально, с первого раза. Навскидку, ~10 пробовал качать, ~7 не загрузились.
    А с kernel.org скачивается без проблем. Как и с гугл-драйва. На днях так же успешно скачивал драйвера с двух разных сайтов, т.е. понятно что проблемы распространяются не на совсем все загрузки.

Чую где-то на сети оператора проблемы или дальше со связностью. Я потыкал несколько ссылок с указанных хостингов - проблемы не увидел.

Писать отдельно Sadler не надо просто разместимте прям тут ссылки для пробы и потыкаем проверим. Однако скорее всего (99,999999%) роутер тут не причём.

Не нашёл сохраняется ли где-то лог с первого включения, так что вот лог после перезагрузки. Даже двух. На всякий случай отключал pppoe - выключал роутер - ждал 15 минут - включал роутер - включал pppoe - пробовал грузить файл. И делал два раза (потому что в первый отвлёкся и забыл сохранить весь лог), в 19 часов,а потом ещё раз в 21-с-чем-то и почему-то отметки в роутере не совсем одиноковые, так что кидаю всё с этого временного промежутка:

Спойлер
Извините, только авторизованные пользователи могут видеть спойлеры.

Строчки с Lease fail eth3  и sending discover немного странные, я не видел их в логах до этого (что подтверждается предыдущим логом который я кидал).

Ссылку кидал выше, вот она же и ещё одна, для примера:

https://katfile.com/yofy53aqcukb/V-HS2007037.part3.rar.html
https://k2s.cc/file/83d7755a041d0

Ближе к выходным попробую сравнить со старым роутером back-to-back, чтобы посмотреть насколько здесь причём или не причём новый роутер.

Хм, почитал на форуме "Lease fail eth3.".
Галка "Чистый PPPoE" у меня абсолютно точно стоит. И проблем с сетью в остальном не наблюдается

хоть с галкой хоть без неё, всё так же долбят эти сообщения...

Цитата: Mikadius от 29/07/2020, 22:51

Если что, у меня вторая ссылка без проблем докачалась. В первой ссылке в рекламе запутался.

 

Цитата: Plohish от 29/07/2020, 23:15

хоть с галкой хоть без неё, всё так же долбят эти сообщения...

Чудес не бывает. dhcp клиент при истом pppoe даже не запускается если что.

Цитата: Mikadius от 29/07/2020, 22:51
https://katfile.com/yofy53aqcukb/V-HS2007037.part3.rar.html
https://k2s.cc/file/83d7755a041d0
https://katfile.com/yofy53aqcukb/V-HS2007037.part3.rar.html
https://k2s.cc/file/83d7755a041d0

Ближе к выходным попробую сравнить со старым роутером back-to-back, чтобы посмотреть насколько здесь причём или не причём новый роутер.

Всё до чего удалось пробраться через рекламу и прочее всё скачалось и на РТ и на ТТК без вопросов.

 

Цитата: sfstudio от 30/07/2020, 06:23
Цитата: Plohish от 29/07/2020, 23:15

хоть с галкой хоть без неё, всё так же долбят эти сообщения...

Чудес не бывает. dhcp клиент при истом pppoe даже не запускается если что.

Я конечно попробую перегрузить роутер после установки галки чистого PPPoE но для чего тогда роутер 40 секунд делает вид что что то останавливает-запускает при нажатии кнопки "применить" ?

Всё что роутер делает в этот момент видно в логе. udhcpc ессно при настройке vpn убит уже не будет (хотя... н помню если честно надо посмотреть, это одна из самых старых частей логики наследумая из версии в весрию почти без изменений).

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

Как-то не встречались мне люди которые не делают этого просто хотя бы для самоуспокоения, что когда их не будет дома и моргнёт свет то всё не встанет колом.

Я не помню в деталях логику, запишу на полях - дойдут руки гляну.

Возможно кейз когда сброс - настройка с галкой без ребута в конце при PurePPPOE и оставляет за собой запущенный без дела udhcpc, благо ни на что кроме сообщений в логе это не влияет как таковое.

 

Так что, по логам ничего интересного не видно?

Видно, что они есть! Факт! Ну логи.

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

Цитата: Sadler от 30/07/2020, 19:53

>Файлы на бесплатных файлхостингах вообще имеют свойство недокачиваться

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

Я бы может и согласился бы с вами, но из личного опыта знаю что это не так. Есть менее дружелюбные обменники, uploaded, например. Вот у него недокачиваться может, и скорость режет сильно, собственно его обхожу стороной. А те что перечислил -  юзаю периодически уже последние ~3 года минимум. Юзал активно. Продолжал закачку даже после разрыва интернета по причине нестабильности сети (aka почему я купил новый роутер). Всё качалось успешно с вероятностью ошибки, ну, ~ 1 файл из 30 максимум. А замирание на 100/100 я точно ни разу не видел за это время, не то что у 7 файлов из 10.

К слову, я сегодня проверил на всё одном и том же пуле "проблемных" и у меня тоже успешно скачалось аж 3 файла подряд. Но 4й всё же замер. А хотелось бы чтобы всё, а не как повезёт, всё таки.

Что поделать. Видимо вам надо к провайдеру. Подтвердить не удалось в любом случае. Я уже молчу, о том, что нет причин роутеру по разному обрабатывать соединения с файлопомойками и тем же kernel.org. Но на всякий проверили.

Возможно где-то со связностью траблы. Бывает. Роутер тут не при делах. Либо подождать пока починят, либо репортить провайдеру. В общем этот тот случай, когда жиды и наличие в кране воды никак не связаны (образно).

А скиньте кто-нибудь на дом-ру скрин страницы настройки PPPoE, пожалуйста. На всякий.

@sadler ?

 

Цитата: sfstudio от 30/07/2020, 21:47

Что поделать. Видимо вам надо к провайдеру. Подтвердить не удалось в любом случае. Я уже молчу, о том, что нет причин роутеру по разному обрабатывать соединения с файлопомойками и тем же kernel.org. Но на всякий проверили.

Возможно где-то со связностью траблы. Бывает. Роутер тут не при делах. Либо подождать пока починят, либо репортить провайдеру. В общем этот тот случай, когда жиды и наличие в кране воды никак не связаны (образно).

И всё таки нет.

Эксперимент:
Утром файлы не грузились.
Вечером тоже.
Я воткнул старый роутер и,
о чудо:

Спойлер
Извините, только авторизованные пользователи могут видеть спойлеры.

4 из 4 "проблемных"!
Да ещё и ssh сессия на кластер перестала умирать каждые 10 минут! (до этого грешил на сам кластер, т.к. у других людей с ним раньше были проблемы).

Ну а если потом воткнуть duo-G обратно и повторить всё то же:

Спойлер
Извините, только авторизованные пользователи могут видеть спойлеры.

Плюс ssh сессии снова не держатся.
Вот такие вот жиды.
Надеюсь вы не станете говорить что неполадки, висевшие неделю, провайдер быстренько починил за те 10 минут что я достал и подключил старый роутер, а потом так же быстро разломал всё когда я воткнул обратно duo-G. И снова резко починил когда я ещё раз сменил роутер на следующий день, когда убедился, что лучше не стало. Я в такое точно не поверю =Р

Пока воткнул как ТД к старому роутеру, так как беспроводную связь этот чудо-девайс держит заметно лучше одноантенного роутера из 2013го (к слову, было бы здорово в краткую инструкцию или в интерфейс добавить про смену ip, а то минут 20 ушло чтобы понять почему ничего не работает). Но хотелось бы чтоб и в и-нет сам умел ходить.
На выходных свяжусь с тп провайдера, может они смогут подсказать что с этим делать.

Что я тут могу сказать. Повторяемости нет. Что лечить не ясно.

Могу предложить на пробу последний выстрел в небо.

Сброс, мин настройка (только VPN и пароль на радио) + отключение оффлоадов, всех. Крайне маловероятно, но всё же. Если повторяемость исчезнет придётся мне через свои каналы вызнавать что там за брас к которому вы подключены и как сконфигурирован для локального повторения и затыкания несовместимости на уровне PPE с конкретным брасом (ну раз у остальных повторов нет). Но что-то мне подсказывает, что дело тут не в бобине от слова совсем.

А уж рвущиеся ssh это вообще не научная фантастика. У нас вся инфраструктура бегает внутри ssh, причём узлы есть и на ДОМ.РУ и никаких проблем с сессиями. Да и с чего бы им взяться не ясно.

Хоть бы в логи openssh с обоих сторон бы привели, может оно бы подсказало куда копать.

Что там за одноантенный роутер из 2013 я фиг знает. Но мне известен только один набор логики с PPE от Ralink/MTK одностримный тех лет. Это RT3050(он же RT3350). Все остальные наборы логики тех лет, одностримные, (кроме риалтэков) не имели аппаратного оффлоада вообще.

Потому стоит проверить этот момент. Может PPE дуреет в конкретной связке с этим брасом. Но опять же роутер не знает что там в TCP завёрнуто, потому ему всё равно какой там сайт или какое приложение по tcp бегает и проблемы были бы со всеми прикладухами и всеми сайтами. Однако их нет.

Как следствие чисто на уровне "угадайки" (т.е. без логов со стороны сервера) проблема больше похоже на траблы с фрагментацией при неверно выбранных MTU в туннеле. Или же траблам связаности таки.

Цитата: Mikadius от 31/07/2020, 01:06

А скиньте кто-нибудь на дом-ру скрин страницы настройки PPPoE, пожалуйста. На всякий.

А чего скидывать-то? Логин/пароль+PurePPPOE. Вот и все настройки.

по одному из файлов косяк подтверждаю! Ждём второй

 

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

второй скачался

 

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

Если можете, попробуйте скачанный файл залить на любой другой хостинг, и скачать оттуда. Чтобы хоть как-то сузить круг поиска. В идеале -- на хостинг без ограничения скорости, чтобы не ждать два часа, пока оно дойдёт до 100%. Я тоже ткнул ещё раз на скачивание, мож со второго раза и у меня проявится.

Цитата: Sadler от 01/08/2020, 16:17

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

https://drive.google.com/file/d/15Qq5l5INEbIGQNtgyvQ8AZyiq16dmaGc/view?usp=sharing

Цитата: Plohish от 01/08/2020, 15:19

по одному из файлов косяк подтверждаю! Ждём второй

 

А повторяемость есть или раз от раза результат разный?

Если есть повторяемость проверяем с FF. Т.е. надо сократить зону поиска до минимума, или определиться как достигнуть повторяемости на нашей стороне. Тогда можно будет что-то думать/делать/дампить там или чего ещё. Пока не очень ясно куда копать, совсем.

Вспомниось, что HTTP3 как транспорт юзает UDP. У блока PPE аппаратного есть косячок с UDP (который у чела рядом с керио вылез). Благо для проявления оного нужны определённые условия и в подавляющем большинстве случаев с ним не сталкиваются совсем.

Если реализация HTTP3 треггерит этот косяк аппаратный, ну крайне плохо. Придётся костылить что бы его совсем не отключать. Для проверки достаточно снять калку UDP Offload в misc.

Плюс хотелось бы видеть что за "ошибка сети" по мнению хрома там произошла.

Плюс определиться что у вас общего по браузерам и оси. Версия и того и другого. Фаеры/антивирусники какие стоят и т.д.

Пока вижу что у обоих доступ PPPOE ?

Кстати гугл уже начал включать поддержку HTTP3 по дефолту? У них есть метода обкатки на кошечках, включают выборочно народу и смотрят будут маты или нет. Не тот ли случай? =)

второй раз оттуда же попробовал, снова встал на 100 процентах, более не стал пробовать

PPPoE, какая ошибка не знаю, где её посмотреть? Логи роутера чисты.

Браузер Хром последний, Win 7 x64, KIS

Хочу уточнить, Вы с драйва пробовали скачать, или только ссылку вывесили, а качаете с того же обменника? Это важно.

по ссылке сверху, по которой качается более часа, две попытки и обе неудачные

с ГуглДрайва без проблем

Такс. Вот что давайте попробуем. 2 команды (будет действовать до перезагрузки)

sysctl -w net.netfilter.nf_conntrack_generic_timeout=1200
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=2400

Есть подозрение что один из потоков передачи на долго дохнет и такой коннект флушиться в итоге из контрака по таймауту.

Вообще такие вещи должны приложения уметь обрабатывать.

В FF проверит кто-нить или забили и не надо уже никому решать проблему?

У меня интернет работает (через старый роутер), и последние несколько дней времени нет с ним возится. Ветку прошу не закрывать, ближе к концу недели или на следующей меня отпустит и тогда начну по порядку: играть MTU, искать как сделать логи ssh, запускать команды и прочее.

Цитата: sfstudio от 04/08/2020, 11:27

В FF проверит кто-нить

У меня фаерфоксе не шло, я в самом первом посте писал.

Цитата: sfstudio от 01/08/2020, 17:57

Плюс определиться что у вас общего по браузерам и оси. Версия и того и другого. Фаеры/антивирусники какие стоят и т.д.

Пока вижу что у обоих доступ PPPOE ?

Пробовал ФФ, хром и оперу под вин7, антивирь ESET NOD32,
и ещё смартфонную оперу с андройд9, и из антивирей только встроенный "защитник" от сяоми (не уверен он фильтрует доступ в интернет или нет)

С гугл драйва у меня тоже всё качается, как и с kernel.org, скажем. Не совсем понял в чём был смысл той махинации; если проблемы возникают в 70% случаев то тут явно конфликт не с одним конкретным "неудачным" файлом.

Давайте я вам скажу просто? Вы либо желаете решить проблему и тогда действуете как вам говрят. Либо не желаете.

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

Однако сижу и придумываю варианты как сузить круг поиска. Высасываю из пальца потенциально что могло бы к такм приводить. Не ну грю, право ваше. Я могу предложить просто обратиться к дисту за возвратом средств.

Или будем таки решать проблему?

Вот, теперь у меня есть время что-то проверять.

Сегодня поменял MTU, 1400, 1200, 1000 - проблему не решило
Провайдер тоже не помог - сказали только что устройства NAG с аналогичной прошивкой дополнительной настройки не требовали.

Цитата: sfstudio от 01/08/2020, 14:03

Сброс, мин настройка (только VPN и пароль на радио) + отключение оффлоадов, всех.

Хоть бы в логи openssh с обоих сторон бы привели, может оно бы подсказало куда копать.

Можете уточнить, что такое "все оффлоады" и где их искать в меню роутера? "Программная обработка" в сервисы->разное?

ssh к удалённому серверу рвётся свыше 5 минут бездействия(в норме я оставлял его до часу, всё было ок), с моей стороны пишет в лог только "Network error: Software caused connection abort", со стороны сервера не могу сказать т.к. не админ и рут-прав не имею. Попробую связаться с админом, если это что-то даст.

Цитата: sfstudio от 01/08/2020, 14:07

Что там за одноантенный роутер из 2013 я фиг знает. Но мне известен только один набор логики с PPE от Ralink/MTK одностримный тех лет. Это RT3050(он же RT3350). Все остальные наборы логики тех лет, одностримные, (кроме риалтэков) не имели аппаратного оффлоада вообще.

ZyXEL Keenetic Lite rev B • CPU: Ralink RT5350 , да.

Цитата: sfstudio от 04/08/2020, 11:27

Такс. Вот что давайте попробуем. 2 команды (будет действовать до перезагрузки)

sysctl -w net.netfilter.nf_conntrack_generic_timeout=1200
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=2400

Я правильно понял, что надо был зайти по ssh на роутер, запустить две команды и ничего не перезагружая проверить интернет?
Если да - то нет, ничего не поменялось (теперь проверяю загрузка + ssh на сервер)

  1. Ага. А ещё НАГ сам софт пишет =)))))) Не всплыло там вот и всё, и тут бы не всплыло если бы таки не было похоже клиентозависимо.
  2. В MISC смотрите (уж простите но как оно на русском не помню, не юзаю Ранш UI =)), вот в Misc по дефолту Offload в Complex, вырубить вовсе и посмотреть. Как минимум исключим PPE из подозреваемых.
  3. со стороны сервера было бы интересно именно. В т.ч. как и keeplive работает или нет, настроен или нет, ничего подобного у себя не вижу, записи в логах роутера в это время есть какие-то? Уже перебрал все точки (бльше 10ти провайдеров по РФ у тестерв и друзей под нашим ПО и железом, повторения нет).
  4. 5350 эт самый куций чип из выпущенных за лет 15 у MTK/Ralink никаких оффлоадов, всё софтово
  5. да, именно, зайти по ssh и выполнить 2 команды

Ну и что бы было от чего отталкиваться:
1) обновление и сброс + минимальная настройка
2) проверка по проводу
3) проверка в прямой видимости

Т.е. нужно определить круг потенциальных виновников. Ибо с MT веткой (поставляемой NAG) в этой части нет разницы, как и репортов по MT ветке нет, хотя там десятки тысяч активных девайсов светятся онлайн.

Значит нужно искать специфику в ваших условиях.

Вообще я уже грил, что обрыв TCP/IP соединения штука в общем-то обычная в современных сетях. И на уровне http прекрасно обрабатывается. Потому я лично не въеду чего оно "не докачивает" учитывая до кучи мультипоточность.

А уж то что это всё все браузеры с незапамятных времён обрабатывать умеют... Короч загадка века.

Вот с ssh было бы чуть проще понять чего происходит, но надо логи с обратной стороны.

Таймауты точно не 5ть минут. Даже generic таймаут 8 минут. Но вынос такой сессии по таймауту грит что keepalive не работает. Ессно тупо висящие сессии без дела надо закрывать дабы память не тратить почём зря. А что бы не закрывались сами по себе при неактивности keepalive и придуман.

И в http и в ssh оно есть. Как бы это вообще нормальная логика позволяющая экономить ресурсы.

Ну а если слегка ругнуться. То можн вспомнить, что IP и TCP+UDP придуманы ХЗ сколько лет назад и что бы ими по сей день можно было пользоваться и не упираться в узкие места например connection tracking или NAT придуманы миллионы обходных путей типа keepalive. Но это уже лирика.

В любом случае и клиентская и серверная сторона должны уметь реагировать на подобное. ssh там ещё можно понять почему при выносе сессии из контрака по неактивности может умирать без keepalive. Но вот с http...

Из положительного: отключение offload в misc. действительно решило проблему с закачками! (перепроверил даже)
Из не очень - проблему с ssh оно не решило

В прямой видимости всё так же, по проводу от провайдера ок, по проводу от роутера нет

Вот терь верните оффлоады на родину и отключите только UDP оффлоад, есть подозрение что хостер пытается юзать http3 который quic по udp и всплывает трабла с offload`ом в итое.

В общем проверить бы надо во всех режимах.

С ssh (на правах гадалки ибо ничего другого не придумывается и новых данных нет, как и массовых репортов за 10+ лет) либо настраивайте keepalive на сервере и клиенте, либо задирать таймауты контрака что не есть гуд. У меня везде работает keepalive и никаких проблем не наблюдается вообще.

Вынос из контрака неактивных соединений вполне нормальное поведение. И происходит на всех узлах. Особенно это критично на домашних железках, где рамы далеко не гигабайты.

В прямой видимости всё так же, по проводу от провайдера ок, по проводу от роутера нет

Т.е. не специфично по проводу или беспроводу. Ок. Ясно, осталось подтвердить догадку на тему http3.

Логика оффлоада (кстати) для TCP уже скоро как лет 12 по сути не меняется. И опять таки массово репортов нет. Это первый. С чем связано не знаю. Если с http v3 то всё понятно. Если нет, то видимо есть ещё какой-то фактор для достижения повторямости у остальных. Пока не ясно какой.

настроил keepalive и ssh тоже нормализовалось. Не совсем понятно, правда, почему на старом роутере всё работало просто с дефолтными настройками(выключенном keepalive). Возможно на старом не было, а на DUO-G есть некий "NAT firewall", который "time out idle sessions after a certain period of time [...] sometimes as as little as 300 seconds."

 

Цитата: sfstudio от 13/08/2020, 14:18

Вот терь верните оффлоады на родину и отключите только UDP оффлоад, есть подозрение что хостер пытается юзать http3 который quic по udp и всплывает трабла с offload`ом в итое.

Не-а, с одним выключенным UDP проблема присутствует.
Попробую пеперебирать остальные.

К слову, там менюшке есть подсказка
"for IPOE/PPPOE recommended HARDWARE mode, for L2TP/PPTP - COMPLEX".
Мне следует выставить не комплекс а хардварный режим тогда, раз дом ру у меня через РРРОЕ, или это какое-то другое РРРОЕ..?

  1. Как раз выше чётко поясняю что контроль стэйтов и эти таймеры нынче есть везде и всегда. Это нормально и это позволяет на куцих железках закрывать потребности всего того ада соединений что генерит современный софт. Таймауты выставлены везде разные (см /etc/sysctl.conf на тему опций conntrack). Ничего криминального в выносе соединений неактивных совсем нет. Это всё нынче обрабатывается софтом из коробки. Если соединение нужно держать до упора то используется keepalive. Реализации есть и в ssh и в http и везде где нужно что бы соединения даже неактивные оставались установленными длительное время. Таймаут не меньше 300с, а больше это всяко. Но ssh без кипэлайв уже лет 5ть как вообще может не активничать никак и контрак стэйт машине просто не откуда узнать что соединение ещё живо. На старом девайсе либо выкручены таймауты были ещё выше (тут только эксперементально подбирать если не лень) или костыль какой в garbage collector контрака был. Однако ещё раз повторюсь, что никакого криминала в зачистке мертвичины нет. А выбор таймаутов это всегда компромисс. На больших системах их можно выкрутить до упора, на маленьких лучше держать минимальными.
  2. Для IPOE/PPPOE софтовый оффлоад почти не имеет смысла (т.к. они могут быть целиком аппаратно обработаны). С точки зрения снижения потенциальных тараканов (т.к. любой NAT/Conntrack offload штука не штатная для ядра и меняет логику в самом сердце прохождения пакетов) можно переключиться в hardware only режим. Для PPTP/L2TP без софтварного оффлоада будет грустно. Ибо там то что в туннеле обрабатывается софтово и оффлоадиться им, а то что в локалочку (по сути IPOE) будет обработано хардварно.

Однако если нет проблем то и менять ничего не следует. В 99,9999% случаев т.е.

Надо выяснить сейчас какой вариант оффлоада приводит к повторяемости и попробую посмотреть кой чего, есть тут смежный репорт о подземном стуке от человека который я никак не могу пояснить (внутренняя логика PPE увы не доступна даже на подглянуть через щёлочку). Так что тараканы PPE выявлять и обходить крайне сложно. Благо уже годами новых проблем там не появлялось, а старые все известны. Хотя не удивлюсь что что-то новенькое всплыло в конкретной вот связке (от клиента до роутера, провайдера и хостера). Что является триггером не понятно.

В новых версиях я чутка увеличу таймауты, т.к. теперь у нас уже точно нет и не будет устройств с <64Мб оперативы. Или устройств с <128 + USB.

Кстати keepalive так же спасает от ситуации когда conntrack table заполняется, и garbage коллектор при сборке мусора выносит самые старые соединения без наличия активности. Без keepalive они так же будут зачищены. С keepalive нет.

Так что настроенный keepalive для ssh просто must have в любом случае.

Просьба обновиться со сбросом и настройкой руками.

Как грил выше чуть таймауты увеличил + удалось достигнуть на наколенных тестах "повисания" одного из потоков в многопоточной загрузки при больших потерях (эмулировал работающим полисером) на передающей стороне при работающем PPE. Вроде удалось снизить вероятность возникновения оного почти до нуля.

Если это оно - то должно поведение хрома выше полечиться.

ОДНАКО! Такая ситуация так или иначе должна корректно обрабатываться качалкой. В на моих системах с chromium/FF/curl и т.д. достигнуть повторяемости так и не удалось. Пришлось писать эмулятор с кривой обработкой подобных вещей что бы подтвердить догадку.

Т.е. не смотря на то, что какой-то косячёк в PPE (аппаратный блок оффлоада) на эту тему есть, но при правильно работающем клиентском браузере/качалке проблем быть не должно. Как и не будет их если передающая сторона (или где-то по пути) не использует полисер (в отличии от шейпера скорость ограничивается дропом части пакетов куда).

Пока исходя из всех данных и экспериментов эта теория единственная выжила, была хоть как-то подтверждена в песочнице и что-то с этим удалось сделать (не решить полностью, но отодвинуть "проблему").

Таймауты контрака так же как и грил несколько увеличил.

Виновником оказался "WiFi hardware nat offload". Причём даже по проводу, что (для меня) звучит немного странно. Если его и только его перевести в disable всё закачивается как должно.

UPD это проверялось до вот этого последнего обновления 18.08, если что

Очень интересно. Помониторю посмотрю как оно вообще может быть связано. Странно. Проверьте плз на последней версии.

He-а, изменений не заметил. Всё так же не докачивает при включенном WiFi hardware nat offload (ни один 3 проверочных файлов; если выключить - все 3 качает).

Пятиминутный таймаут ssh при выключенном keepalive тоже не изменился, к слову, хотя это уже и не важно.

Ну не пятиминутный он. =) Эх ладно. Попробую ещё раз глазками пробежаться по коду PPE ибо идеи для повторения у меня иссякли.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: