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
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
