problém s FTP (bad cksum 0)

Dan Lukes dan at obluda.cz
Fri Jun 10 10:58:07 CEST 2011


On 06/10/11 10:26, Zbyněk Burget:
>> 09:31:03.905406 IP (tos 0x0, ttl 64, id 45338, offset 0, flags [DF],
>> proto TCP (6), length 52, bad cksum 0 (->9aaf)!)
>> 10.0.3.2.ftp> gwo.stampi.cz.30603: Flags [.], cksum 0xef20 (incorrect
>> -> 0x4c0d), seq 291, ack 91, win 8325, options [nop,nop,TS val
>> 2803289076 ecr 395292522], length 0
>>
>
> Chybi mi tu informace i tom, jaky je smer toku toho packteu - to je
> packet na tom interface prichozi nebo odchozi? Pokud je odchozi, tak bad
> checksum nemusi nutne znamenat chybu

Spravne upozorneni, ale v tomhle pripade tam ta chyba spis byt musi.

Ma tam poskozeny jak checksum v IP hlavicce tak checksum v TCP hlavicce. 
Prvni TXCSUM akcelerace vysvetli (pokud jde o 'out' paket), ten druhy ne.


On 06/10/11 09:59, Cizek Milan:
> Tou IGW paket jen projde, kontroluje se zde checksum?

V IP hlavicce ano, v TCP hlavicce ne. Navic - IP hlavicka se meni 
(snizuje se TTL) takze checksum je treba spocitat znovu, TCP zustava 
nezmenena.

Udelej to jednodusse - vypni na zucastnenych BSD hardwarove akcelerace 
(rxcsum,txcsum; u ostatnich odporucuju mit je vypnuty trvale, nemam s 
nimi dobre zkusenosti) - tim odpadne problem "jeste nespocitaneho 
checksumu u odesilanych paketu". No a pak musis projit celou cestu a 
najit misto kde jsou na vstupu pakety jeste v poradku a na vystupu jiz 
poskozene (a ne tak, ze budes zkoumat pakety v ruznych smerech).

Pokud by se nahodou stalo, ze vypnutim akceleraci problem zmizi (coz by 
me tak uplne neprekvapilo), mas taky odpoved.

A az zjistis, ze je za tim ten Mikrotik (coz je druha moznost, kter aby 
me neprekvapila) musis se obratit o radu do jine konference ...

Dan



More information about the Users-l mailing list