Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
This is LPC driver issue ... Vincent Vincent Cui Firmware Engineer Leader Shanghai Enlogic Electric Technology Co., Ltd. Room1106, Building A, New Caohejing Business Centre, No.391, Guiping Road, Xuhui District, Shanghai, P.R.China T: +86 21 34612525, M: +86 13482482211 www.enlogic.com Please consider the environment before printing this email. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. Any views and/or opinions expressed in this e-mail are of the author only and do not necessarily represent the views of Enlogic. -Original Message- From: lwip-users-bounces+vincent.cui=enlogic@nongnu.org [mailto:lwip-users-bounces+vincent.cui=enlogic@nongnu.org] On Behalf Of Slava Zilberfayn Sent: 2014年10月16日 10:34 To: Mailing list for lwIP users Subject: Re: [lwip-users] pbuf_alloc failed after sometime at driver side. Hello Slava, Hm, the driver was missing error handling, naturally the missing packets returned some error. Looking further... Regards, Slava Wednesday, October 15, 2014, 3:54:16 PM, you wrote: SZ> Hello, SZ> I'm having some issues with lwip stack, or rather with the system as SZ> whole. At this point I studied the stack relatively well at seems to SZ> work as intended. However I might be still mistaken, so I'm posting SZ> here. SZ> The root of the problems is that sometimes packets are being lost SZ> for no reason. This can happen even if I connect my PC directly to SZ> the lwip device. SZ> When I look at the WireShark trace, it shows as "TCP Previous SZ> Segment not captured". See attachment. It is certainly not just "not SZ> captured", as this is always accompanied by problems on receiving SZ> end and netconn_write takes longer time to be completed. Eventually SZ> the packets are retransmitted, but it could take like 10 seconds, SZ> which is not very good. SZ> I already instrumented the driver (lpc17_emac), and logs confirm SZ> that all packets are leaving my device strictly in order. What could SZ> be the reason for router to ignore my packets? I also tried with two SZ> different routers and it is the same. Could the problem be with MAC-PHY link? SZ> Can anybody suggest further steps for debugging? SZ> Thanks, Slava -- Slava Zilberfayn mailto:szil...@home-electro.com Phone: 416 7289367 Home Electronics, www.home-electro.com 100 Drumlin Circle, Suite 205 Concord, ON, L4K 3E6 CANADA ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
Hello Slava, Hm, the driver was missing error handling, naturally the missing packets returned some error. Looking further... Regards, Slava Wednesday, October 15, 2014, 3:54:16 PM, you wrote: SZ> Hello, SZ> I'm having some issues with lwip stack, or rather with the system as SZ> whole. At this point I studied the stack relatively well at seems to SZ> work as intended. However I might be still mistaken, so I'm posting SZ> here. SZ> The root of the problems is that sometimes packets are being SZ> lost for no reason. This can happen even if I connect my PC directly SZ> to the lwip device. SZ> When I look at the WireShark trace, it shows as "TCP Previous Segment SZ> not captured". See attachment. It is certainly not just "not captured", as this is SZ> always accompanied by problems on receiving end and netconn_write SZ> takes longer time to be completed. Eventually the packets are SZ> retransmitted, but it could take like 10 seconds, which is not very SZ> good. SZ> I already instrumented the driver (lpc17_emac), and logs confirm that all packets SZ> are leaving my device strictly in order. What could be the reason for SZ> router to ignore my packets? I also tried with two different routers and it SZ> is the same. Could the problem be with MAC-PHY link? SZ> Can anybody suggest further steps for debugging? SZ> Thanks, Slava -- Slava Zilberfayn mailto:szil...@home-electro.com Phone: 416 7289367 Home Electronics, www.home-electro.com 100 Drumlin Circle, Suite 205 Concord, ON, L4K 3E6 CANADA ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
Hello, I'm having some issues with lwip stack, or rather with the system as whole. At this point I studied the stack relatively well at seems to work as intended. However I might be still mistaken, so I'm posting here. The root of the problems is that sometimes packets are being lost for no reason. This can happen even if I connect my PC directly to the lwip device. When I look at the WireShark trace, it shows as "TCP Previous Segment not captured". See attachment. It is certainly not just "not captured", as this is always accompanied by problems on receiving end and netconn_write takes longer time to be completed. Eventually the packets are retransmitted, but it could take like 10 seconds, which is not very good. I already instrumented the driver (lpc17_emac), and logs confirm that all packets are leaving my device strictly in order. What could be the reason for router to ignore my packets? I also tried with two different routers and it is the same. Could the problem be with MAC-PHY link? Can anybody suggest further steps for debugging? Thanks, Slava prev-not-received.pcap Description: Binary data ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
@Sergio R. Caprile I think you are right, i haven't check buffer in tcp/udp call back. Now i am free the buffer in call back and it's working longer. Will let you know after more testing. Thanks -- View this message in context: http://lwip.100.n7.nabble.com/pbuf-alloc-failed-after-sometime-at-driver-side-tp23381p23394.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
> Isn't the stack responsible for freeing PBUFs? No Grzegorz, the stack isn't more responsible than you are. The Ethernet driver usually allocates the pbufs when signalled by the Ethernet controller. This code does not belong to lwIP but to the driver developer. It is responsible for freeing non-IP frames. Code for this is in the netif tree and is modified by the one providing the driver and the port. It usually follows src/netif/ethernetif.c and usually uses etharp.c, but the only one who actually knows that is you, the user (and others running the same driver...), so if you are using vendor code, you should check with your vendor, they do like to do things at will. > And now upper laye stack have resposibilty to free this packat after > it no longer in use. No jbhoi, the upper layer is ultimately layer-5to7 and ergo your responsibility, unless we are talking about pings/arp..., or you are using a known to work application, which I don't know because you don't say. > [...] will pass it io next phase like ip_input and from that it call > tcp_input or udp_input or other and it will free that packet. Nope, it will just ultimately call the application callback function and it (YOU) will free the pbuf. TCP will only free the pbuf when INSTRUCTED TO DO SO, by returning a specific value in your callback function. UDP will not free it. You guys should by all means try a known to work application to rule out any problem in your driver and/or port. I first thought of the driver because the problem description looked like non-IP frames pbufs were not being freed. Now, since you actually don't know you have to free pbufs, I'm beginning to think that you actually have a non-working application. Anyway, there are many network conditions that may cause different pbuf allocation and that might fail in different ways. Please read the docs. Take a time to read the wiki http://lwip.wikia.com/wiki/Raw/native_API Check that you are following the multithreading requirements (just one thread and only one will talk to lwIP (pbuf functions are supposed to be a bit more permissive but I don't run RTOSes so I can't tell you how to do anything other than keep everything on the same context). http://lwip.wikia.com/wiki/Raw/TCP http://lwip.wikia.com/wiki/Raw/UDP Then take a time to check the tcpecho_raw application for TCP or the sntp application for UDP; in the contrib tree Follow those guidelines in your application. Regarding specifics for pbuf freeing; from the wiki: UDP: "The callback function is responsible for deallocating the pbuf" TCP: "If there are no errors and the callback function returns ERR_OK, then it is responsible for freeing the pbuf. Otherwise, it must not free the pbuf so that lwIP core code can store it" Let's make a deal: If something is wrong in the wiki, I will fix it. If something is wrong in your code, you will fix it. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
I don't think the issue related to the driver because driver have pass after
checking the eth type of the pakcet it pass to the upper layer stack. And
now upper laye stack have resposibilty to free this packat after it no
longer in use.
Here peace of drive code
/* move received packet into a new pbuf */
p = lpc_low_level_input(netif);
if (p == NULL) {
return;
}
/* points to packet payload, which starts with an Ethernet header */
ethhdr = p->payload;
switch (htons(ethhdr->type)) {
case ETHTYPE_IP:
case ETHTYPE_ARP:
#if PPPOE_SUPPORT
case ETHTYPE_PPPOEDISC:
case ETHTYPE_PPPOE:
#endif /* PPPOE_SUPPORT */
/* full packet send to tcpip_thread to process */
if (netif->input(p, netif) != ERR_OK) {
LWIP_DEBUGF(NETIF_DEBUG,
("lpc_enetif_input: IP input
error\n"));
/* Free buffer */
pbuf_free(p);
p=NULL;
}
break;
default:
/* Return buffer */
pbuf_free(p);
p=NULL;
break;
}
Here `netif->input` mapped to tcpip_input function of lwip stack which store
packet in queue and tcp ip running thread will pass it io next phase like
ip_input and from that it call tcp_input or udp_input or other and it will
free that packet.
--
View this message in context:
http://lwip.100.n7.nabble.com/pbuf-alloc-failed-after-sometime-at-driver-side-tp23381p23388.html
Sent from the lwip-users mailing list archive at Nabble.com.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
Sergio R. Caprile napisał(a): Please don't repost the same issue with a different name... Check your driver code, from what the other user said, looks like non-IP packets are being discarded without freeing their buffer. Check with the one who wrote the driver and/or the port. When the Ethernet controller signals frame(s) pending, the receiving task allocates a buffer for it and transfers data. Then, this buffer is checked for upper-layer protocol and handled to the stack or discarded. Code for this is in the netif tree and is modified by the one providing the driver and the port. Isn't the stack responsible for freeing PBUFs? Received frames are passed by mbox (in tcpip_input()) to the TCP/IP thread. Inside the thread the ethernet_input (etharp.c) function is called. For IP packets it calls ip_input(), for non-ARP and non-IP it calls pbuf_free(). Best regards, Grzegorz Niemirowski ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
Please don't repost the same issue with a different name... Check your driver code, from what the other user said, looks like non-IP packets are being discarded without freeing their buffer. Check with the one who wrote the driver and/or the port. When the Ethernet controller signals frame(s) pending, the receiving task allocates a buffer for it and transfers data. Then, this buffer is checked for upper-layer protocol and handled to the stack or discarded. Code for this is in the netif tree and is modified by the one providing the driver and the port. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
Thanks for replying @Thomas But my device have limited memory. I am able to use 16K memory so have defined it #define MEM_SIZE(16 * 1024). Also my lwip not crashes but just lost the ping from other device. Any other way to overcome this issue? Can we force the upper layer to Free all buffer? For solution i have keep highest priority for TCP/IP thread but no luck. Thanks, Jayesh -- View this message in context: http://lwip.100.n7.nabble.com/pbuf-alloc-failed-after-sometime-at-driver-side-tp23381p23383.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
Hi, I had the same problem in my lpc1788. When I ran it on the companies local network it was just a couple of minutes before it halted. On a closed network it ran like forever! I fixed it by increasing the mem size so I had space enough for allocation. So I had to move it from internal PIRAM to external SDRAM. The only thing I wonder why the lwip crashed when alloc fails! Thomas -- View this message in context: http://lwip.100.n7.nabble.com/pbuf-alloc-failed-after-sometime-at-driver-side-tp23381p23382.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
