netdev - Re: TCP fast open question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 8 Mar 2014 22:47:37 +0800
From:	"gnehzuil.liu" <gnehzuil.liu@...il.com>
To:	Zhi Yong Wu <zwu.kernel@...il.com>
Cc:	Linux Netdev List <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	"David S. Miller" <davem@...emloft.net>,
	Yuchung Cheng <ycheng@...gle.com>,
	Jerry Chu <hkchu@...gle.com>,
	Xiaochen Wang <xiaochen.wxc@...baba-inc.com>,
	Zheng Liu <wenqing.lz@...bao.com>
Subject: Re: TCP fast open question

> 在 2014年3月8日，下午8:56，Zhi Yong Wu <zwu.kernel@...il.com> 写道：
> 
>> On Sat, Mar 8, 2014 at 7:58 PM, Zheng Liu <gnehzuil.liu@...il.com> wrote:
>> Hi all,
>> 
>> Now we are trying to use TCP fast open in our nginx server, and we
>> encounter a problem under non-blocking socket.  I appreciate if some one
>> can reply this question.  Thanks in advance.
>> 
>> I describe our question here.  we have two machines, one is as server and
>> another is as client.  'net.ipv4.tcp_fastopen' on both of them are set to
>> 3.  The server program looks like below:
>> 
>>  ...
>>  listenfd = socket(AF_INET, SOCK_STREAM, 0);
>>  bind(listenfd, (struct sockaddr *)&servaddr, sizeof(servaddr));
>>  int tfo_opt = 1;
>>  setsockopt(listenfd, SOL_TCP, TCP_LISTEN_INFO, &tfo_opt, sizeof(tfo_opt));
> s/TCP_LISTEN_INFO/TCP_FASTOPEN/??

Sigh!  Yes, it's a typo.  Thanks for pointing it out.

Regards,
                                                - Zheng

>>  listen(listenfd, 5);
>>  connfd = accept(listenfd, (struct sockaddr *)NULL, NULL);
>>  recv(connfd, &buf, 4096)
>>  ...
>> 
>> The client program:
>> 
>>  ...
>>  sockfd = socket(AF_INET, SOCK_STREAM, 0);
>>  fcntl(sockfd, F_SETFL, fcntl(sockfd, F_GETFL, 0)|O_NONBLOCK);
>>  sendto(sockfd, msg, strlen(msg), MSG_FASTOPEN,
>>        (struct sockaddr *)&servaddr, sizeof(servaddr);
>>  recv(sockfd, buf, 4096, 0);
>>  ...
>> 
>> We use a non-blocking socket to connect the server and send some
>> messages.  After calling sendto(2) we always get an EINPROGRESS error.
>> We think it is reasonable because connect(2) could also return this
>> error with a non-blocking socket and the connection will be established
>> later.  The question is *whether or not the data will be sent* after the
>> connection is established.  If I understand correctly, sendto(2) will
>> return the number of bytes of data queued up in the kernel or sent in
>> the SYN packet.  Even though the EINPROGRESS is returned.  If sendto(2)
>> returns -1, that means that no data is queued up in kernel or sent in
>> the packet.  Please correct me if I miss-understand something.
>> 
>> We run the program in our testing environment, and we use tcpdump(1) to
>> capture the packets.  From the result we can see there is no any data
>> that is sent.  Then we do another testing that after calling sendto(2)
>> the client program will sleep for 5 seconds and then call send(2) to
>> transfer some data.
>> 
>>  $ ./client xx.xx.xx.xx
>>  ret -1 errno 115
>> 
>> The program works well.  So that means that after getting a EINPROGRESS
>> error, the program must call send(2) manually.  Is it correct?  If we
>> want to avoid this problem, we need to set 'net.ipv4.tcp_fastopen' to
>> 0x707 ?
>> 
>> Regards,
>>                                                - Zheng
>> --
>> 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
> 
> 
> 
> -- 
> Regards,
> 
> Zhi Yong Wu
--
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