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