TCP fragmentation issue

[Ian Caddy]

Hi All,

Well, I performed the investigation and came up with the following 
analysis if anyone is interested:

We set up a simple echo server and a PC client which was capable of 
sending a programmable size payload to see what would happen.

In the write from our server, it would eventually (not a long trip) end 
up in a function called sosend in 
rtems/c/src/libnetworking/kern/uipc_socket.c in 4.5.0 
(rtems/libkit/libnetworking/kern/uipc_socket.c in 4.6.1)

All the action we are interested in happens from line 424 to 480.

Basically, it gets an mbuf (standard buffer for building network frames) 
which is a length of 128 bytes.  It has to allow space for some header 
information and so it makes the length mlen = MHLEN which is 100 bytes.

It then checks if resid (our payload size) is >= MINCLSIZE (minimum 
cluster size) which is 208 bytes, or just less than 2 MBUFs.  If it is, 
it will create a cluster and store the payload in it.

So, if the size is greater than the mbuf space (100 bytes) and less than 
a minimum cluster size (208 bytes), only the first 100 bytes are sent 
and the bit left over is sent as another frame, and we go through this 
loop all over again, for TCP.  For UDP, a flag is marked making it 
ATOMIC and it will loop over getting another mbuf and linking it to the 
first before going on.  In this way UDP packets do not get fragmented.

I thought I would look into 4.6.1 to see if it was still handled the 
same way and it appears to be, although I can't find the param.h file, 
in fact I can't find a definition anywhere in the tree for MSIZE! (I 
even greped the whole tree *.*)

The code appears to be the same so the same fragmentation will happen 
for TCP frames also.

I understand this is not a bug, but our project people are still having 
problems with the devices that they are interfacing with.

I have two choices.  The first is to modify sosend to link in the second 
mbuf to send the whole frame, or the other option is manually modify the 
minimum cluster size to it matches up with the mbuf size with no gap.  I 
  will let you all know how I go.

You have done well if you made it this far, thanks.

regards,

Ian Caddy
Microsol (Aust) Pty Ltd.


Ian Caddy wrote:

> Hi All,
> 
> Some of our project people have reported an issue with our product 
> fragmenting TCP packets destined to another machine when the length of 
> the packet is between 100 and 202 bytes in length.
> 
> TCP packets of larger sizes are sent through unfragmented.
> 
> We are using RTEMS 4.5.0 for our product with 100MBit Ethernet.  The max 
> MTU is not set in our stack (set to 0 so defaults to 1500) and it is not 
> set to anything other than default on the Windows machine it is talking 
> to.  They have tried various different machines to with the same results.
> 
> This in itself is not a problem, but a commercial package on the windows 
> machine, has a problem if the packet is fragmented which is causing 
> issues.  We have other systems running with no problems, so they have 
> asked if I can look into it.  They even checked it with another package 
> that works, and the checked the raw packet log and saw that packets of 
> between 100 and 202 bytes were fragmented, so this particular package is 
> not effecting the behaviour.
> 
> I had a quick look in the mail archives, and nothing turned up.
> 
> Before I start a proper investigation, has anyone seen this sort of 
> behaviour before in RTEMS and have an explanation about why it is 
> happening?
> 
> I look forward to your responses.
> 
> regards,
> 
> Ian Caddy
> Microsol (Aust) Lty Ltd.
>