Simon, you gave me a great advice. I knew that I have to check my code
and I made this many times unfortunately without result by now. But
your words "check your code if there's something that could overwrite
these fields..." focused my think in another direction. When I want to
give a frame (received by the HW) to the stack, I reserve memory for a
PBUF_REF buffer, then set the "payload" pointer to the frame (I want
to avoid one more copy) and call the function input(). When the
function input() returns, I release the memory for the buffer. Now I
simply commented out the release of the memory and the device works
without any problem even with 6 parallel GET request. All seems to
work perfect, looking in the Wireshark logs. Of course it works until
all the memory is consumed. I don't really know why this solved the
problem, but probably I release the memory too early and the stack
still use it, meantime the same memory is allocated again and used
from another function. But now it comes the other question. When I
have to release the memory for this buffer? How could I know when the
stack has finished his work with it? Can you give an advice?
Simeon
On 21.6.2017 г. 13:52 ч., Simon Goldschmidt wrote:
Simeon Trifonov wrote:
I' looking in the content of the corresponding pcb, especially the
member "unacked". Here is what I see:
The variable "len" seems to be ok - 1460. The pointer "p" points the
buffer with "len" set to 54 and "tot_len" set to 1514.
This seems to be correct too. The pointer "next" is valid (not
null), so it must point the rest of the frame (1514 bytes).
I don't want to include your screenshots again, so I'll try to do
without.
What you see is a segment of 1460 bytes of user data (unacked->len).
Now that segment has already been sent, so the pbufs contain
headers (ETH, IPv4, TCP = 54 bytes). These are stored in an extra
pbuf so the whole frame is 1514 bytes long.
In theory, the first pbuf of this segment is OK (len=54,
tot_len=1514), but the next should be len=tot_len=1460, so definitively,
there is something wrong.
At first sight of such problems, I always assume violation of lwIP's
threading requirements (don't call into the core code from
more than one thread or from thread + interrupt). But this also could
be something completely different.
What's strange is that the pbuf's type, ref and payload seem to be OK
but the len not. My best suggestion is try to check your code
if there's something that could overwrite these fields...
Simon
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users