lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] LWIP 1.4.1, LPC1788, DP83848 - problem with douple processi


From: Slava Zilberfayn
Subject: [lwip-users] LWIP 1.4.1, LPC1788, DP83848 - problem with douple processing of input
Date: Thu, 19 Sep 2013 14:45:39 -0500

Hello lwip-users,

I'm a new user of the LWIP, although over last few weeks I had to dig
in pretty deeply.

I'm very new to TCP/IP and still have many questions...

The hardware I'm using is  LPC1788, DP83848. I'm using LWIP 1.4.1 and
I got emac drivers from NXP libraries.

First, I started testing it with by device connected directly to a PC.
Initially I had memory related problems where it would run out of
memory to allocate pbufs and quit. I switched to mem pools, and got it
working. I thought. After I tried the board connected to a router, a
bunch of new problems appeared.

It looks like due to extra delay that packets take to travel, lwip
sends replies twice. These causes major congestions as eventually the
number of packets it has to process grows exponentially.

I'm gradually uncover what is going wrong but it is so slow. Any hints
would be greatly appreciated. Attached is a wireshark trace, and debug
console output.

As you can see, it outputs the same segment twice in the beginning.
both tcp_output calls originate from receive thread:

        lpc_low_level_output() at lpc17_emac.c:631 0x5a1c
        etharp_send_ip() at etharp.c:426 0x1d576        
        etharp_output_to_arp_index() at etharp.c:856 0x1da5c    
        etharp_output() at etharp.c:954 0x1dbde 
        lpc_etharp_output() at lpc17_emac.c:1,003 0x6198        
        ip_output_if() at ip.c:797 0x1cab4      
        ip_output() at ip.c:834 0x1cb18 
        tcp_output_segment() at tcp_out.c:1,173 0x151be 
        tcp_output() at tcp_out.c:997 0x14c7a   
        tcp_listen_input() at tcp_in.c:514 0x1737c      
        tcp_input() at tcp_in.c:258 0x16cfc     
        ip_input() at ip.c:574 0x1c6ca  
        ethernet_input() at etharp.c:1,363 0x1e262      
        lpc_enetif_input() at lpc17_emac.c:482 0x574c   
        vPacketReceiveTask() at lpc17_emac.c:813 0x5d0c 
        0x0     

This is what stack looks like on both calls to tcp_output. So what is
is, a bug in the receive portion of the driver?

Thank you, Slava

Attachment: duplicates.pcap
Description: Binary data

Attachment: capture.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]