http://mikrotik.moscow Новое в теме Ошибка отслеживания соединения TCP-сессии? форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Wed, 05 Aug 2026 00:58:22 -0400 Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
Может, это как-то связано? http://forum.mikrotik.com/t/question-about-tcp-established-and-call-of-duty-disconnects/144346/1
23.11.2020 08:58:00, Maggiore81.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396269 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396269 Mon, 23 Nov 2020 08:58:00 -0500 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
Как вы решили эту проблему? У меня есть Chateau LTE12, и такая же ситуация. Могу передавать файлы с помощью «scp» на удалённый сервер, но подключиться по ssh не получается. Через какое-то время выдает ошибку «Broken pipe».
13.11.2020 13:47:00, infabo.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396268 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396268 Fri, 13 Nov 2020 13:47:00 -0500 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
У меня такая же проблема на моём Chateau C12 LTE. После последнего обновления ROS v7.1beta1 я не могу подключиться к своему SSH-серверу. Всегда получаю следующую ошибку: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe. В логах не вижу никаких потерянных пакетов. ОБНОВЛЕНИЕ Проблема связана с fasttrack и обычной обработкой брандмауэра.
01.08.2020 17:32:00, haj3s29a.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396267 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396267 Sat, 01 Aug 2020 17:32:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
Хорошо, приятно это слышать. В ближайшие недели у меня будет возможность проверить другую конфигурацию, в которой я сталкиваюсь с этой ошибкой, и обновить её до RC-версии, чтобы увидеть, сработает ли это и в моём случае.
05.11.2016 08:57:00, pe1chl.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396266 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396266 Sat, 05 Nov 2016 08:57:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
Судя по моим тестам, v6.38rc24 полностью исправляет проблему, теперь я не вижу никакой разницы в отслеживании сессий при включённом или выключенном fasttrack.
05.11.2016 07:17:00, drees.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396265 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396265 Sat, 05 Nov 2016 07:17:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
Я отправил в поддержку письмо, ссылаясь на эту ветку, и они спросили, есть ли у меня какие-то правила fasttrack, а также попросили мой файл supout.rif. Судя по вопросу, я отключил правило fasttrack, и теперь, похоже, таймауты соединения работают как положено на версии 6.37.1.
12.10.2016 05:51:00, drees.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396264 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396264 Wed, 12 Oct 2016 05:51:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
Да, недавно были изменения, но я не помню, в какой именно версии. Мне казалось, что это было до 6.34.6, но я не уверен. В любом случае, поведение довольно непредсказуемое. У некоторых соединений проблем вообще нет, а у других эта проблема возникает.
09.10.2016 08:44:00, pe1chl.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396263 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396263 Sun, 09 Oct 2016 08:44:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
Я откатил роутер/AP RB951G-2HnD до версии 6.34.6 из ветки с исправлениями, и бага там вроде как нет, хотя поведение немного отличается. Сначала таймаут подключения устанавливается на 2 дня, потом снижается до примерно 1 дня. Иногда он снова подпрыгивает до примерно 2 дней. Немного странно, но хоть не нужно переживать, что соединения внезапно разорвутся.
08.10.2016 20:45:00, drees.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396262 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396262 Sat, 08 Oct 2016 20:45:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
Единственный побочный эффект увеличения этого таймера — возможно, некоторые TCP-соединения, которые уже «мертвы», будут дольше оставаться в таблице отслеживания. Но проблем это вызывать не должно. Если хотите решить проблемы с SSH и имеете доступ к настройкам сервера, добавьте в /etc/ssh/sshd_config примерно следующее:  
ClientAliveInterval 240  
ClientAliveCountMax 6  
Это отправляет проверочный пакет по соединению, чтобы держать его открытым, включая и другие роутеры на пути. К сожалению, на стороне клиента такой функции нет, и установка TCPKeepAlive, похоже, не помогает.
08.10.2016 08:37:00, pe1chl.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396261 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396261 Sat, 08 Oct 2016 08:37:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
У меня такая же проблема, RB951G-2HnD с ROS 6.37.1 и прошивкой 3.33. Устройство работает как роутер плюс точка доступа, при этом точка доступа объединена с LAN-портами в мост. За роутером по Ethernet подключён Linux-компьютер, который через NAT устанавливает SSH-соединение с удалённым сервером в интернете. Если SSH-сессия долго неактивна (точно не знаю, но примерно 5-10 минут), таймаут падает с 23 часов до 5 минут. Когда таймаут истекает, соединение закрывается с ошибкой SSH «Write failed: broken pipe», и приходится переподключаться. Если немного сгенерировать трафика, таймаут увеличивается до значения TCP Unacked Timeout. Например, достаточно нескольких команд ls. Если же на SSH-сессии сделать больше активности (запустить top на 15 секунд — этого хватает), таймаут возвращается к 24 часам (TCP Established Timeout). Есть идеи? Очень раздражает, когда SSH-сессии постоянно умирают, а увеличение TCP Unacked Timeout, похоже, может вызвать другие проблемы.
07.10.2016 21:36:00, drees.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396260 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396260 Fri, 07 Oct 2016 21:36:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
Если свернуть окно RDP, соединение перейдёт в состояние бездействия.
15.09.2016 12:12:00, Mosin.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396259 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396259 Thu, 15 Sep 2016 12:12:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
Спасибо, pe1chl. Я тоже думал, что это не может быть причиной проблем с RDP, но после увеличения «TCP unacked timeout» проблема, кажется, решилась. Пока подожду немного, прежде чем делать выводы. Раньше я уже увеличивал время ожидания unacked после того, как заметил странное сокращение таймаута RDP-соединения с 24 часов до 5 минут. Узнав про твоё дополнительное правило, я и попросил поделиться им, надеясь узнать что-то новое.
12.09.2016 09:02:00, Mosin.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396258 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396258 Mon, 12 Sep 2016 09:02:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
Не думаю, что RDP-соединение будет простаивать целых 5 минут и вызовет эту проблему, скорее всего, причина в чем-то другом. Но в любом случае вы можете увеличить таймаут TCP Unacked в отслеживании соединений: я поднял его с 5 до 30 минут, а если это все ещё вызывает неполадки, можно увеличить до 1 дня, как таймаут для TCP Established. Тем не менее, это ошибка (вероятно, баг ядра), и с этим нужно что-то делать.
12.09.2016 08:35:00, pe1chl.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396257 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396257 Mon, 12 Sep 2016 08:35:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
TCP RESET разорвёт соединение в любом случае, но по вашим правилам, а не тогда, когда решит роутер. Это ошибка в последних версиях RouterOS, которую должен исправить Mikrotik. Лучшее пока решение — установить таймаут TCP unacked на 1 день, тогда он будет равен обычному таймауту для установленного соединения и не будет приводить к обрывам. Таймаут unacked предназначен для данных, которые отправлены, но ещё не подтверждены. По какой-то причине ядро RouterOS не видит подтверждения (ACK) для этих данных, поэтому использует неправильный таймаут и сбрасывает соединения намного раньше, чем нужно.
11.09.2016 21:03:00, R1CH.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396256 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396256 Sun, 11 Sep 2016 21:03:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
У меня такая же проблема с RB2011UiAS-2HnD-IN: бездействующие RDP-сессии обрываются после тайм-аута TCP unacked. Не могли бы вы поделиться своим дополнительным правилом для TCP RESET?
11.09.2016 18:39:00, Mosin.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396255 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396255 Sun, 11 Sep 2016 18:39:00 -0400 RouterOS Ошибка отслеживания соединения TCP-сессии? RouterOS в форуме RouterOS.
Я долго разбирался с проблемой, частично вызванной другим оборудованием, но MikroTik-роутер тоже был связан с ней следующим образом: роутер содержит правила Forward, которые пропускают Established/Related, сбрасывают Invalid и разрешают новые соединения в одном направлении. Ничего необычного. Это не NAT-среда, а pure routing.

Что я заметил: некоторые TCP-сессии, в которых нет трафика, считают таймаут “TCP unacked”, а не “TCP established”, как задано в connection tracking. Этот таймаут по умолчанию всего 5 минут, тогда как established — целый день. После этих 5 минут запись в трекинге удаляется, а через некоторое время удалённый конец закрывает неактивное соединение с FIN ACK, который отбрасывается как “invalid” (что правильно), и локальная сторона никогда не видит закрытия соединения, думая, что оно всё ещё открыто.

Когда локальная сторона пытается отправить данные, роутер создаёт новую запись трекинга, и данные отправляются. Но дальше по пути есть ещё один файрвол (не MikroTik), который видел этот безответный FIN ACK и уже удалил свою запись трекинга, поэтому он сбрасывает эти данные как недействительные. При этом он не отправляет никакого ответа, чтобы сообщить об этом. Локальная система видит "мертвое" TCP-соединение и ругается.

Я обошёл эту проблему сначала, отправляя TCP RESET для TCP-трафика, который сбрасывался как invalid (это заставляет локальную систему понять, что что-то не так и заново устанавливать сессию). Но потом я заметил корень проблемы, увеличил таймаут “TCP unacked” — и теперь сессия корректно закрывается.

Однако корень проблемы в неправильной классификации неактивной сессии. Кажется, я уже сталкивался с этим раньше — SSH-сессии, которые умирали при простое. В моём случае исследовалась связь Linux — Windows, в случае SSH — Linux с Linux.

Что вообще означает “TCP Unacked”? Там есть и таймер “TCP retransmit”, но он не задействован (я менял таймауты, чтобы понять, какой именно отсчитывает). В WiKi это не описано. Может быть, этот таймер срабатывает некорректно, когда одна сторона шлёт “TCP Keepalive”, а другая — нет?
23.06.2016 14:31:00, pe1chl.]]> http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396254 http://mikrotik.moscow/forum/forum57/85423-oshibka-otslezhivaniya-soedineniya-tcp_sessii/message396254 Thu, 23 Jun 2016 14:31:00 -0400 RouterOS