Reputation: 820
I am using LWIP in an application that needs high data rates. So i allocate 4 pbufs once and store their address and with some hardware magic, fill them one after another and, tell the program that buffer is ready and the software sends it as UDP packets, how ever after some time when i sniff the packet I have about 60 extra bytes in my packet, they seem like extra UDP headers but in the payload. any workaround/suggestion?
Upvotes: 0
Views: 1076
Reputation: 1
I faced the same problem and i think in udp_ send function, the headers will be added to your pbuf and it increases the len element of pbif. So you have two choices, first you should free the pbuf and allocate it in the next cycle. Second you can truncate the added headers using pbuf_free_header function, in this case no free pbuf and reallocation needed.
Upvotes: 0
Reputation: 61
On my project at work, we had pbuf corruption that was causing a similar kind of issue. We were using multiple MACs of different types from xilinx and there was unhappiness in the pbuf department. What I would recommend you do is turn on full lwip debug on for IP layer and possibly UDP layer. Then manually trim the prints to something that is managable that reproduces the problem (lwip has a minimum print level - you can use this to help trim out things like warning versus serious prints). In our case we would get UDP or IP layer checksum errors and it was a sign of bad stuff. Also, it is helpful to test in only one direction at a time, to limit the possibilities of bad stuff in one direction. We used iperf examples from xilinx and expanded on them. These were helpful with troubleshooting the issue. BTW 4 pbufs is nothing... When I have looked at ethernet traffic - there is a ton of stuff going on, overhead etc... There is tons of potential problems, from too little ARP table entries and on... Four pbufs is rediculously low, if you are that trapped for memory, I feel sorry for you trying to use lwIP. That just sounds like a nightmare. Also, be careful that typically prints are blocking... so that will mess up performance. It's wise to replace the lwip debug prints with a non blocking routine that you know will not clog up your realtime performance.
Upvotes: 0