netdev - Re: Restricting payload size in do_tcp

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: <CAJNbMrwrNZkMQcBJ12QjrVYbC_1HR0FBcCF44d3dC7kOopSAoA@mail.gmail.com>
Date:	Thu, 1 Mar 2012 18:30:42 +0100
From:	Ashwin Rao <ashwin.shirvanthe@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Restricting payload size in do_tcp_sendpages.

On Thu, Mar 1, 2012 at 4:58 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> Le jeudi 01 mars 2012 à 16:16 +0100, Ashwin Rao a écrit :
>> Hi,
>>
>> I would like to perform some experiments where I want TCP to send
>> packets of size less than the MSS even more than an MSS worth of data
>> is available in the TCP buffers.  I am performing these experiments to
>> submit a patch that can avoid synchronization of TCP flows. I have
>> modified the following code in the function do_tcp_sendpages in the
>> file net/ipv4/tcp.c.  For testing purposes I have currently set the
>> mss_now to half of the value that would have been typically used. I
>> have even updated the size_goal which controls the maximum size that
>> can be sent when offloading is enabled. To avoid coalescing smaller
>> skbs I have even set the can_coalesce to 0. Despite these changes the
>> frames sent over the Ethernet have the length of 1514 bytes. I would
>> like to know which function is responsible for coalescing these
>> packets despite forcing a small segment size.
>>
>> *** linux-3.2.6/net/ipv4/tcp.c
>> --- linux-3.2.6-modified/net/ipv4/tcp.c
>> *************** static ssize_t do_tcp_sendpages(struct s
>> *** 774,779 ****
>> --- 774,783 ----
>>       clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags);
>>
>>       mss_now = tcp_send_mss(sk, &size_goal, flags);
>> +     /* hack begin */
>> +     mss_now = mss_now >> 1;
>> +     size_goal = mss_now;
>> +     /* hack end */
>>       copied = 0;
>>
>>       err = -EPIPE;
>> *************** new_segment:
>> *** 805,810 ****
>> --- 809,817 ----
>>
>>               i = skb_shinfo(skb)->nr_frags;
>>               can_coalesce = skb_can_coalesce(skb, i, page, offset);
>> +             /* hack begin */
>> +             can_coalesce = 0;
>> +             /* hack end */
>>               if (!can_coalesce && i >= MAX_SKB_FRAGS) {
>>                       tcp_mark_push(tp, skb);
>>                       goto new_segment;
>> *************** wait_for_memory:
>> *** 857,862 ****
>> --- 864,873 ----
>>                       goto do_error;
>>
>>               mss_now = tcp_send_mss(sk, &size_goal, flags);
>> +             /* hack begin */
>> +             mss_now = mss_now >> 1;
>> +             size_goal = mss_now;
>> +             /* hack end */
>>       }
>>
>>
>
> You dont need to hack kernel
>
> man 7 tcp
>
>       TCP_MAXSEG
>              The  maximum  segment  size  for  outgoing TCP packets.  If this
>              option is set before connection establishment, it  also  changes
>              the  MSS value announced to the other end in the initial packet.
>              Values greater than the (eventual) interface MTU have no effect.
>              TCP  will  also  impose  its minimum and maximum bounds over the
>              value provided.
>
>

My objective is to send a train of packets each of which has a
different packet size. The maximum packet size should be restricted by
the MSS however the packet sizes should not be the same. Before
randomizing the packet sizes, I wanted to check if I set the packet
size to a fixed value will it be reflected on the packets being sent
over the wire.

Regards,
Ashwin
--
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