Question

I wrote a program to send 1460 byte data using TCP client and server continuously. My system interface MTU is 1500.

Here is my program of client

if((sockfd = socket(AF_INET, SOCK_STREAM, 0))< 0)
{
  printf("\n Error : Could not create socket \n");
  return 1;
}
setsockopt(sockfd,SOL_TCP,TCP_NODELAY,&one,sizeof(one));
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons(9998);
serv_addr.sin_addr.s_addr = inet_addr("10.10.12.1");

if(connect(sockfd, (struct sockaddr *)&serv_addr, sizeof(serv_addr))<0)
{
  printf("\n Error : Connect Failed \n");
  return 1;
}

while(1)
{
   write(sockfd, send_buff, 1448) ;

}

In wireshark initial 15 to 30 packets are showing that 1514 byte of packet is going but afterwards showing as below

wireshark output of some packet

No.     Time        Source                Destination           Protocol Length Info
 16 0.000000    10.10.12.2            10.10.12.1            TCP      5858   53649 > distinct32 [ACK] Seq=3086892290 Ack=250285353 Win=14608 Len=5792 TSval=23114307 TSecr=23833274

Frame 16: 5858 bytes on wire (46864 bits), 5858 bytes captured (46864 bits)
Ethernet II, Src: 6c:3b:e5:14:9a:a2 (6c:3b:e5:14:9a:a2), Dst: Ibm_b5:86:85 (00:1a:64:b5:86:85)

Internet Protocol Version 4, Src: 10.10.12.2 (10.10.12.2), Dst: 10.10.12.1 (10.10.12.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
Total Length: 5844
Identification: 0x8480 (33920)
Flags: 0x00
Fragment offset: 0
Time to live: 64
Protocol: TCP (6)
Header checksum: 0xb38d [correct]
Source: 10.10.12.2 (10.10.12.2)
Destination: 10.10.12.1 (10.10.12.1)

Transmission Control Protocol, Src Port: 53649 (53649), Dst Port: distinct32 (9998), Seq: 3086892290, Ack: 250285353, Len: 5792
Source port: 53649 (53649)
Destination port: distinct32 (9998)
[Stream index: 0]
Sequence number: 3086892290
[Next sequence number: 3086898082]
Acknowledgement number: 250285353
Header length: 32 bytes
Flags: 0x010 (ACK)
Window size value: 913
[Calculated window size: 14608]
[Window size scaling factor: 16]
Checksum: 0x42dd [validation disabled]
Options: (12 bytes)
    No-Operation (NOP)
    No-Operation (NOP)
    Timestamps: TSval 23114307, TSecr 23833274

Data (5792 bytes)

On wireshark it is showing that more than 5792, 7000, 65535 byte of packet are going. But i am sending 1514 byte of packet in one go. on other side i am receiving 1514 byte of packets only due to network mtu.

So my question is

why this much of huge packets are going ?

I tried without NODELAY option also but it is not working.

Is there any solution to send particular packet size (such as 1514 byte) can be send, no jumbo frames ?

I update my tcp_rmem and tcp_wmem also for tcp sending buffer and receiving buffer also. But did not found any solution.

Was it helpful?

Solution 3

I searched a lot and found that, we need to change some parameter on interface.

On my interface eth0 default option are

Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

now using ethtool we need to off some sending side segementation offload. For that sudo ethtool -K eth0 tso off gso off

using this

Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

After this your interface will send packets whatever you want to send.

OTHER TIPS

TCP, by design, bundles up multiple write() calls into larger packets. Also, TCP coalesces packets by default according to Nagle's Algorithm.

If you want more control over the actual size of network packets, use UDP.

These are "jumbo frames", and they're faster than traditional frame sizes because they don't load up a CPU as much.

Consider yourself fortunate that you're getting them without futzing around with your IP stack's settings.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top