[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <B58BD160-4613-4CE8-9899-70E2D028AE5B@guavus.com>
Date: Mon, 17 May 2010 03:49:14 +0000
From: Bijay Singh <Bijay.Singh@...vus.com>
To: Eric Dumazet <eric.dumazet@...il.com>
CC: Stephen Hemminger <shemminger@...tta.com>,
David Miller <davem@...emloft.net>,
"<bhaskie@...il.com>" <bhaskie@...il.com>,
"<bhutchings@...arflare.com>" <bhutchings@...arflare.com>,
netdev <netdev@...r.kernel.org>,
Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Subject: Re: TCP-MD5 checksum failure on x86_64 SMP
On 17-May-2010, at 2:18 AM, Eric Dumazet wrote:
> Le mardi 11 mai 2010 à 22:50 +0200, Eric Dumazet a écrit :
>> Le mardi 11 mai 2010 à 04:08 +0000, Bijay Singh a écrit :
>>> Hi Eric,
>>>
>>> I guess that makes me the enviable one. So I am keen to test out this feature completely, as long as I know what to do as a next step, directions, patches.
>>>
>>> Thanks
>>
>>
>> I believe third problem comes from commit 4957faad
>> (TCPCT part 1g: Responder Cookie => Initiator), from William Allen
>> Simpson.
>>
>> When a SYN-ACK packet is built (in tcp_synack_options()),
>> it specifically forbids a TIMESTAMP option to be included if SACK is
>> also selected :
>>
>> doing_ts &= !ireq->sack_ok;
>>
>> Problem is this mask is done on a local variable. socket is still marked
>> as being timestamp enabled.
>>
>>
>> Later, when we build tcp options for data packets, we _include_ a
>> timestamp, while our SYNACK didnt mention the option.
>>
>> So the following trafic can happen (and fails) :
>>
>> 18:38:29.041966 IP 192.168.0.33.58906 > 192.168.0.56.22226: Flags [S], seq 4014064674, win 8860, options [mss 4430,sackOK,TS val 519041 ecr 0,nop,wscale 7,nop,nop,md5can't check - 9b44126367effcf3247fcbf6da76b24d], length 0
>> 18:38:29.042072 IP 192.168.0.56.22226 > 192.168.0.33.58906: Flags [S.], seq 586328714, ack 4014064675, win 5792, options [nop,nop,md5can't check - badd847799ded46f39642c341cc7e92b,mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
>> 18:38:29.042093 IP 192.168.0.33.58906 > 192.168.0.56.22226: Flags [.], ack 1, win 70, options [nop,nop,md5can't check - 3994ef6987df02a592963fba04c5d313], length 0
>> 18:38:29.043217 IP 192.168.0.33.58906 > 192.168.0.56.22226: Flags [.], seq 1:1441, ack 1, win 70, options [nop,nop,md5can't check - 8399f7ccab3a6b8c5a3027ed58bba314], length 1440
>> 18:38:29.043226 IP 192.168.0.33.58906 > 192.168.0.56.22226: Flags [P.], seq 1441:2501, ack 1, win 70, options [nop,nop,md5can't check - 701ebf65b1894a6bed4cefbf7a56596a], length 1060
>> 18:38:29.043374 IP 192.168.0.56.22226 > 192.168.0.33.58906: Flags [.], ack 1441, win 68, options [nop,nop,md5can't check - 1badb315ba436ab59bff5b37daa871be,nop,nop,TS val 113051377 ecr 519041], length 0
>> 18:38:29.043383 IP 192.168.0.56.22226 > 192.168.0.33.58906: Flags [.], ack 2501, win 91, options [nop,nop,md5can't check - 120564dcb99f822f3b70910282a6ed9d,nop,nop,TS val 113051377 ecr 519041], length 0
>> 18:38:29.043673 IP 192.168.0.56.22226 > 192.168.0.33.58906: Flags [.], seq 1:1429, ack 2501, win 91, options [nop,nop,md5can't check - fe5dfb438065373b52ba85bf800876a8,nop,nop,TS val 113051377 ecr 519041], length 1428
>> 18:38:29.043681 IP 192.168.0.56.22226 > 192.168.0.33.58906: Flags [P.], seq 1429:2500, ack 2501, win 91, options [nop,nop,md5can't check - 7a910cd5ff357bf0e2c8d3489aafaa86,nop,nop,TS val 113051377 ecr 519041], length 1071
>> 18:38:32.037786 IP 192.168.0.56.22226 > 192.168.0.33.58906: Flags [.], seq 1:1429, ack 2501, win 91, options [nop,nop,md5can't check - fe5dfb438065373b52ba85bf800876a8,nop,nop,TS val 113051677 ecr 519041], length 1428
>> 18:38:38.037708 IP 192.168.0.56.22226 > 192.168.0.33.58906: Flags [.], seq 1:1429, ack 2501, win 91, options [nop,nop,md5can't check - fe5dfb438065373b52ba85bf800876a8,nop,nop,TS val 113052277 ecr 519041], length 1428
>> 18:38:50.037524 IP 192.168.0.56.22226 > 192.168.0.33.58906: Flags [.], seq 1:1429, ack 2501, win 91, options [nop,nop,md5can't check - fe5dfb438065373b52ba85bf800876a8,nop,nop,TS val 113053477 ecr 519041], length 1428
>>
>>
>> Could you try following patch ?
>>
>> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
>> index 5db3a2c..0be21cd 100644
>> --- a/net/ipv4/tcp_output.c
>> +++ b/net/ipv4/tcp_output.c
>> @@ -668,7 +668,7 @@ static unsigned tcp_synack_options(struct sock *sk,
>> u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
>> xvp->cookie_plus :
>> 0;
>> - bool doing_ts = ireq->tstamp_ok;
>> + bool doing_ts;
>>
>> #ifdef CONFIG_TCP_MD5SIG
>> *md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
>> @@ -681,11 +681,12 @@ static unsigned tcp_synack_options(struct sock *sk,
>> * rather than TS in order to fit in better with old,
>> * buggy kernels, but that was deemed to be unnecessary.
>> */
>> - doing_ts &= !ireq->sack_ok;
>> + ireq->tstamp_ok &= !ireq->sack_ok;
>> }
>> #else
>> *md5 = NULL;
>> #endif
>> + doing_ts = ireq->tstamp_ok;
>>
>> /* We always send an MSS option. */
>> opts->mss = mss;
>>
>>
>>
>>
>
> Bijay, had you tested this patch by any chance ?
>
I am on quite an old kernel 2.6.27 and could not apply your patches.
Then i moved on to the kernel 2.6.32.11 however since then I have not been able to bring up my card, this is something i need to fix before i can test you fix. Working on that.
> Thanks
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists