netdev - Re: Piggyback the final ACK of the three way TCP connection establishment with the data

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]

Message-ID: <1332458037.6521.12.camel@edumazet-glaptop>
Date:	Thu, 22 Mar 2012 16:13:57 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Vincent Li <vincent.mc.li@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Piggyback the final ACK of the three way TCP connection
 establishment with the data

On Thu, 2012-03-22 at 16:02 -0700, Vincent Li wrote:
> >
> > No kernel patch is needed, you already can do this on linux.
> >
> > Check file net/ipv4/tcp_input.c lines around 5722
> >
> >
> 
> is this code snippet in tcp_rcv_synsent_state_process that you refer to?
> 
> 5676                 if (sk->sk_write_pending ||
> 5677                     icsk->icsk_accept_queue.rskq_defer_accept ||
> 5678                     icsk->icsk_ack.pingpong) {
> 5679                         /* Save one ACK. Data will be ready after
> 5680                          * several ticks, if write_pending is set.
> 5681                          *
> 5682                          * It may be deleted, but with this
> feature tcpdumps
> 5683                          * look so _wonderfully_ clever, that I
> was not able
> 5684                          * to stand against the temptation 8)     --ANK
> 5685                          */
> 5686                         inet_csk_schedule_ack(sk);
> 5687                         icsk->icsk_ack.lrcvtime = tcp_time_stamp;
> 5688                         icsk->icsk_ack.ato       = TCP_ATO_MIN;
> 5689                         tcp_incr_quickack(sk);
> 5690                         tcp_enter_quickack_mode(sk);
> 5691                         inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
> 5692                                                   TCP_DELACK_MAX,
> TCP_RTO_MAX);
> 5693
> 5694 discard:
> 5695                         __kfree_skb(skb);
> 5696                         return 0;
> 5697                 } else {
> 5698                         tcp_send_ack(sk);
> 5699                 }
> 
> if I understand it correct on linux, the application code need to set
> socket option with TCP_DEFER_ACCEPT or TCP_QUICKACK in order to
> trigger it, correct?
> 
> We have user running wu-ftpd on HP Unix with tcp tunable
> tcp_delay_final_twh_ack on. so in active FTP situation, when wu-ftpd
> open up data connection to client, it sends SYN, client SYN/ACK, then
> ACK/PUSH with data. so on HU UNIX, it appears just turn on tcp tunable
> tcp_delay_final_twh_ack would make it happen.
> 
> but on Linux, do I need to change wu-ftpd code and modify the socket
> option with TCP_DEFER_ACCEPT or TCP_QUICKACK in order to trigger the
> code snippet in tcp_rcv_synsent_state_process?

Yes.

A third possibility (reading the code) if you use non blocking IO, is to
send() a message right after connect()



--
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