TCP/IP packet fragmentation issue

Mick Davis mickd at goanna.iinet.net.au
Wed Jun 20 03:05:49 UTC 2012


One problem that's easy to diagnose is to see if you're running out of 
network buffers.

Perhaps you could see if the problem is better or worse with more 
buffers, eg

struct rtems_bsdnet_config rtems_bsdnet_config = {
         &eth0_cfg,
         NULL,

         5,
         512*1024,
         512*1024,

There's also the netstats shell command, in particular "netstats -m", 
which runs rtems_bsdnet_show_mbuf_stats().


On 20/06/12 03:28, João Paulo Scalão Martins wrote:
> Hello guys,
>
> I tried the patch suggested by Mick Davis, and the situation is now much
> better than before!
>
> Answering the questions/suggestions:
>
> Thomas:
>
> I'm using RTEMS version 4.10.2, and my BSP is the PC386. Thesw network
> configurations structures are declared in the networkconfig.h file:
>
> struct rtems_bsdnet_config rtems_bsdnet_config = {
> &eth0_cfg,
>          NULL,
>
>          5,
>          256*1024,
>          256*1024,
>
> "rtems",
> "abtlus",
> "10.128.11.1",
> "10.128.11.1",
>          { "10.128.11.1" },
>          { "10.128.11.1" },
>
>          0,
>          0,
>          0,
>          0,
>          0,
> };
>
> static struct rtems_bsdnet_ifconfig eth0_cfg = {
> "fxp1",             /* Name - ne1 is the default for  */
>          libbsdport_netdriver_attach,           /* Driver Attach
> Function - */
>          NULL,
>
> "10.128.11.1",                              /* IP Adress */
> "255.0.0.0",                                /* IP Netmask */
>
>          eth0_address,                               /* Ethernet
> hardware MAC address */
>
>          0,                                          /* Ignores broadcast */
>          0,                                          /* MTU - default */
>          0,                                          /* rbuf  - default */
>          0,                                          /* xbuf - default */
>          0,                                          /* port - default */
>          0,                                          /* irq - default */
>          0,                                          /* bpar - default */
>          NULL                                        /* driver control
> pointer - default */
> };
>
> driver_t* libbsdport_netdriver_table[] =
> {
> &libbsdport_fxp_driver,
>          NULL
> };
>
>
> The initial definitions are like this:
>
> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
>
> #define CONFIGURE_MAXIMUM_TASKS                     10
> #define CONFIGURE_MAXIMUM_SEMAPHORES                15
> #define CONFIGURE_MAXIMUM_MESSAGE_QUEUES            16
> #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS    16
> #define CONFIGURE_MAXIMUM_TIMERS                    20
> #define CONFIGURE_MAXIMUM_PRIORITY                  63
> #define CONFIGURE_MAXIMUM_PERIODS                   2
>
> #define CONFIGURE_STACK_CHECKER_ENABLED
> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
> #define CONFIGURE_UNIFIED_WORK_AREAS
>
> /*
>   *  RTEMS Memory Definitions
>   */
> #define CONFIGURE_EXECUTIVE_RAM_SIZE    (490*1024)
> #define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
> #define CONFIGURE_EXTRA_TASK_STACKS (32 * RTEMS_MINIMUM_STACK_SIZE)
>
>
> Dear friend Wendell,
>
> I would like to test and use UDP, but we have a serious problem here:
> the client software (running in the Control Room) is not ours. It is
> held by another group, and we have no autonomy to modify it,
> unfortunately. And this software is based in TCP streams.
>
>
> Mick Davis,
>
> Thank you! I applied the patch, and the fragmentation problem was solved!
>
> Now I still have another problem, maybe is nor related with the RTEMS
> network supplement. As the packets grow above *_200_* bytes, the
> communication goes down after some retransmissions. And this situation
> goes on until the packets have 250 bytes, when it gets normal again. I'm
> attaching the Wireshark capture of the problem.
>
> However, my situation is a lot better than before, so I thank you so
> much, once again!
>
> Regards from Brazil,
>
> Joao

-- 

Mick Davis
Goanna Technologies Pty Ltd
+61 8 9444 2634



More information about the users mailing list