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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.