Ack Flooding

Ack Flooding

[Pradeep Anbumani]

Hi,

 I am implementing TCP Daytona, and as my first step I wanna generate
5 acks for each packet received. The ack flooding should be done after
the 3-way handshake.
Can Any one help me out with which function has to be modified.
regards,
Pradeep.A

Ack Flooding

[Srinivas Naga Vutukuri]

Hi,
            
       Am just looked at the tcp_input.c
will it serve in modifying the function, tcp_rcv_established()
calling tcp_send_ack() inside it places 3 or 5 times,


Regards,
srinivas.





********************************************************************
No virus was detected in the attachment no filename

Your mail has been scanned by InterScan.
********************************************************************


The information contained in this electronic message and any attachments 
to this message are intended for the exclusive use of the addressee(s) 
and may contain confidential or privileged information.
If you are not the intended recipient, please notify the sender at 
Samsung Electro-Mechanics Co. Ltd. or admin@semsoftindia-samsung.com
immediately and destroy all copies of this message and any attachments.
Any unauthorized review, use, disclosure, dissemination, forwarding, 
printing or copying of this email or any action taken in reliance on
this e-mail is strictly prohibited and may be unlawful.

ACK Flooding

[Pradeep Anbumani]

I wanna analyse how the Linux Kernel reacts for the change I've made.
I've changed the tcp_input.c file and the function is
"__tcp_ack_snd_check()" function.........and added a loop of 100
acks.....generation .....The behavior of TCP is not as expected after
adding this piece of code....

If anybody could tell me what changes had to be made to get the
desired output..the desired output is TCP as per the conventional
behaviour has to increase the transmission rate as it gets more
duplicate acknowledgements....

static __inline__ void __tcp_ack_snd_check(struct sock *sk, int ofo_possible)
 {       int i=0;
         struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp);

3009             /* More than one full frame received... */
3010         if (((tp->rcv_nxt - tp->rcv_wup) > tp->ack.rcv_mss
3011              /* ... and right edge of window advances far enough.
3012               * (tcp_recvmsg() will send ACK otherwise). Or...
3013               */
3014              && __tcp_select_window(sk) >= tp->rcv_wnd) ||
3015             /* We ACK each frame or... */
3016             tcp_in_quickack_mode(tp) ||
3017             /* We have out of order data. */
3018             (ofo_possible &&
3019              skb_peek(&tp->out_of_order_queue) != NULL)) {
3020                 /* Then ack it now */
                       for(i=0;i<100;i++){ /* My CHANGES ONLY THIS FOR LOOP
                       tcp_send_ack(sk);
                       }
3022         } else {
3023                 /* Else, send delayed ack. */
3024                 tcp_send_delayed_ack(sk);
3025         }
3026 }

Pradeep

Re: ACK Flooding

[David S. Miller]

On Tue, 23 Nov 2004 09:42:18 +0530
Pradeep Anbumani <pradeepdreams@gmail.com> wrote:

> If anybody could tell me what changes had to be made to get the
> desired output..the desired output is TCP as per the conventional
> behaviour has to increase the transmission rate as it gets more
> duplicate acknowledgements....

If you send a 100 ACKs you won't get this behavior.
Once you give more ACKs than the other end has packets
to send (or more than the congestion window can fit)
the sender just waits for a timer based timeout before
it retransmits more data.

So what you code causes to happen is after the first data segment
is sent, you crazily spit out 100 ACKs, the send has a tiny
congestion window (now 2 segments) so at most it can send 2
packets back in response to all of those ACKs.