Re: lug-bg: treason unloacked

[George Danchev <danchev@xxxxxxxxx>]

On Monday 20 June 2005 11:44, Hristo Chernev wrote:
> Здравей,
> Имам подобен проблем отпреди година поне, също като теб пуснах до листата
> описание на проблема но явно никой не се беше сблъсквал и така си и остана.
> Ето линк за постинга ми:
> http://linux-bulgaria.org/webarchive/2004/Dec/32198.html
> Този (д)ефект ( или напълно изчезване на машината - краш ) се получава горе
> долу веднъж в месеца. Повечето случаи има  Treason Uncloaked съобщения в
> лога. Разликата е че аз съм с апаче 1.
> Затова с голям интерес чаках някой да ти отговори , но уви...
> Понеже почнах да подозирам драйверите на мрежовата карта или самата карта
> искам да те питам с каква карта си? И има ли някакви нови разкрития при
> теб?

Сега се сетих ;-) Тогава го оприличих по-скоро на SYN атака, но май не е. Не 
трябва да подозираш драйвера на картата, а TCP кода (в лога пише ли, че идва 
от kernel: TCP:...?) който се бори с това некоректно или нападателно 
поведение на отсрещната страна (дето си свива tcp window [1] волно или 
неволно). Щом принти Treason Uncloaked, значи ядрото е заловило нарушението 
по свиване на tcp джама (което нарушава и TCP RFC btw) и взима мерки. Ето 
някои обяснения на google:

http://www.linuxprinting.org/pipermail/general-list/2003q2/003945.html
http://lists.debian.org/debian-isp/2002/04/msg00192.html

Не съм решавал такъв проблем, но *според мен* това което се случва е: 
отсрещната страна казва (s tcp window-a) прати ми много малко или нула data 
octets обратно, при което ядрото не затваря сокета веднага, а изчаква по 
определена схема (в коментарите в сорса пише), съответно това може да влияе 
на инстансите на апаха / а и не само /. Т.е. опит да те постави в положение 
да изчакваш ангажирайки си собствените ресурси за колкото се може по-дълго 
време. Отсрещната страна може да прави това и неволно ако е с бъгав TCP code, 
но всеки трябва да реагира подходящо.

Евентуално може да се събере малко инфо с tcpdump,
да се прочетат внимателно коментарите в 
/usr/src/linux/net/ipv4/tcp_timer.c и може би да се добие по-добра представа 
за промяна на съответните tcp* променливите (tcp orphans ли да се намалят, 
по-бързо да таймаутва connection-a ли ? ) от /proc/sys/net/ipv4 или друго 
което е хич не е тривиално... промяна в кода на ядрото които се бори с това 
( тук ask lkml ).

NOTE: не знам точното решение, а просто предлагам в каква посока да търсите.

[1] http://www.protocols.com/pbook/tcpip2.htm#TCP

-- 
pub 4096R/0E4BD0AB 2003-03-18 <danchev.fccf.net/key pgp.mit.edu>
fingerprint    1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB