Check to be sure your Ethernet driver isn't increasing pbuf->ref anywhere. Some drivers do this so that the packet is freed only after a DMA transfer is complete and not at the time low_level_output returns. If it's freed too soon the packet can be corrupted if its pbuf is used before the DMA finishes.
Bill >-----Original Message----- >From: [email protected] >[mailto:[email protected]] On >Behalf Of Bernhard 'Gustl' Bauer >Sent: Wednesday, January 20, 2010 7:39 AM >To: Mailing list for lwIP users >Subject: Re: [lwip-users] http server and pbuf overflow > >Hi, > >I checked the memory where pbuf pool is located. On power up it is zero >except for the ->next pointers. Some time later MEM PBUF_POOL used is at >3 (max=5) in spite there is no traffic. So I checked the memory again. >The top 3 pbufs (63, 62, 61) are like this: >->next=0 >->tot_len=0 >->len=0 >->ref=1 > >pbuf (60) is like this: >->next=&pbuf[58] >->tot_len=0 >->len=0 >->ref=0 > >pbuf (59) is like this: >->next=&pbuf[59] >->tot_len=0 >->len=0 >->ref=0 > >All pbufs with ref=1 are not freed, all pbufs with ref=0 are freed. Is >this correct? > >I crosschecked the pbufs with the attached wireshark file. >pbuf[63] = packet 55 >pbuf[62] = packet 1028 >pbuf[61] = packet 999 > >In all 3 cases this is a FIN packet from remote after a corrupt >transfer. From the pcap file I can only guess whether ACK (42, 1007, >983) and POST (43, 1008, 984) are missed, or passed on to my >application. > >I checked my http_recv(). I have 3 different exits: >1: pbuf_free(); tcp_abort(); return ERR_ABORT; >2: tcp_receved(); pbuf_free(); tcp_abort(); return ERR_ABORT; >3: tcp_receved(); pbuf_free(); return ERR_OK; Is there anything wrong >with an exit? Do I need tcp_recved() before tcp_abort(); return >ERR_ABORT; ? > >Glad for any pointers. > >Gustl > _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
