LINUX.ORG.RU
решено ФорумAdmin

SYN_SENT hang

 ,


1

1

После 8 часов работы компьютера все tcp запросы идут жэсточайшэ долго на любой хост. провайдер - byfly

curl -v http://www.google.by
netstat -np | grep -i curl
> tcp        0      1 192.168.0.3:59216       173.194.40.87:80        SYN_SENT    13244/curl
sudo grep -i "173.194.40.87" /proc/net/ip_conntrack
> 104 SYN_SENT src=192.168.0.3 dst=173.194.40.87 sport=59216 dport=80 [UNREPLIED] src=173.194.40.87 dst=192.168.0.3 sport=80 dport=59216 secctx=null use=2
таблица ip_conntrack не переполняется

  • перезагрузка компа - сразу все отлично
  • смена mac адреса модема - никакого толку
  • перезагрузка модема и его друзей посредством отключения питания - никакого толку
  • смена mac адреса компа и перезапуск dhcp - никакого толку
  • выгрузить/загрузить модуль r8169 - никакого толку
  • отключить tcp_sack, перезагрузится и подождать 8 часов - никакого толку
  • подождать 2-3 часа - снова все отлично

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

есть достаточно знаменитый тред. читал и кивал головой. вродебы они пришли к тому что «Ephemeral Port Range» нужно изменить

sudo cat /proc/sys/net/ipv4/ip_local_port_range
>32768	61000

описанными в треде портами 3127-3198 тут не пахнет. и как этот промежуток изменить, чтобы syn_sent не бесил?

ну или может какой-то другой костыль вставить?

★★

ухты, попробуй на невстроенной сетевухе

visual ★★★ ()

Что-то не понял - в том треде на experts-exchange сужение диапазона портов фигурирует как решение или как причина. Может стянешь куда-нибудь копию, а то там регу хотят для прочтения.

varchar ()

Может это кровавая гэбня белорусская пробует новые файрволлы какие-то? :) А после перезагрузки этот файрволл про тебя ненадолго забывает ;)

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

Спасибо, интересное расследование. Поискав, я нашел в другом месте решение:

sysctl net.ipv4.tcp_sack=0
сработавшее для человека столкнувшегося с такой же проблемой:

I figured out a countermeasure. When the 38 hour limit is hit and the connections start to get stuck in SYN_SENT, I disabled tcp_sack in the linux kernel. Almost instantly, the SYN_SENT connections cleared up and connectivity was restored.

Причиной он считает баг где-то в ядре - очень интересно, надо дальше копать.

varchar ()

навербозил в ядре. неделю наблюдал. syn идет, а в ответ пшык. после 5-10 ретрая - присылает ответ. полюбому криворукий провайдер, что в беларуси-то не удивительно.

punya ★★ ()
Последнее исправление: punya (всего исправлений: 1)

что-то типа такой бороды. поставим лимит, посмотрим как будет.

punya ★★ ()

ЗЫ надыбал другую сетевуху - все тоже самое

punya ★★ ()

посоны. если кому интересно

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_fin_timeout = 30
24 часа комп работает ниразу бага не было. varchar оказался прав.

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