From: Patrick McHardy <kaber@trash.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] checksum update in TCP
Date: Mon, 20 Jan 2003 11:19:34 +0000 [thread overview]
Message-ID: <marc-lartc-104306145614818@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104305763511093@msgid-missing>
Patrick McHardy wrote:
> devik wrote:
>
>> Hi,
>>
>> anyone knows when TCP checksum is updated ? I have problem
>> with FTP transfers. I tested with two linux servers both
>> as ftp client or server. In all cases large (cca 50MB) file
>> transfers are corrupted inside.
>> I want to spot the problem, so that my question is:
>> if packet goes thru 2.4.18 router, does the router TCP
>> checksum recomputation ? Router has NAT enabled but not for
>> packets I'm interested in.
>>
> Hi devik,
> NATted packets have incremtental checksum updates, i think the function
> is called something like ip_nat_cheat_check. TTL is decreased in
> include/net/ip.h,
Sorry just got out of my bed ;) The function is called ip_decrease_ttl
but it doesn't alter
tcp checksums. I think for a normal forwarded packet which doesn't hit
any mangling
iptables targets tcp checksum is untouched.
bye
patrick
>
> thats also where the checksum is updated. If you are using iptables
> some targets also
> do checksum recalculation, namely ECN is broken in 2.4.20 (wrong
> checksums).
> I'm aware of no place where complete recalculation of checksum is
> done, i think
> everything is done as incremental update these days.
> bye
> patrick
>
>> If yes then if router itself corrupts packet's data the case
>> will not be caught because it simply computes valid checksum
>> of corrupted data.
>> On other side if it simply passes packet thru (because nothing
>> except TTL is changed and TTL is not part of TCP checksum) then
>> the checksum should really ensure that nothing is changed
>> between sender and reciever and if data are invalid then error
>> would be on sender's or reciever's side.
>>
>> thanks,
>> -------------------------------
>> Martin Devera aka devik
>> Linux kernel QoS/HTB maintainer
>> http://luxik.cdi.cz/~devik/
>>
>> _______________________________________________
>> LARTC mailing list / LARTC@mailman.ds9a.nl
>> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>
>>
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2003-01-20 11:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-20 9:23 [LARTC] checksum update in TCP devik
2003-01-20 10:35 ` Pavel Mores
2003-01-20 11:09 ` Patrick McHardy
2003-01-20 11:19 ` Patrick McHardy [this message]
2003-01-20 14:09 ` devik
2003-01-21 11:58 ` Pavel Mores
2003-01-21 13:59 ` devik
2003-01-22 23:24 ` Pavel Mores
2003-01-23 7:31 ` devik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-104306145614818@msgid-missing \
--to=kaber@trash.net \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox