I need some help to understand how the stack works, because I cannot
understand what I see when I'm debugging my problem. The situation is
the following. I stopped on a breakpoint when when I receive an
acknowledgement from the PC and 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). But actually "len" and "tot_len" are
0 (this is something that I don't expect) and the pointer to the payload
is valid, but it seems to point incorrect data.
The receive conformation that I'm evaluating now is according to the
last line of the following log:
The previous two frames are exactly to port 51999 according to the
acknowledgement on the last line.
Since I don't know if I understand how all things work, please, tell me
if this content is expected and why.
Simeon
On 21.6.2017 г. 08:44 ч., Simeon Trifonov wrote:
When I'm looking in my code, I think that this was exactly the problem
that I have solved. Nevertheless, I removed my changes and I used the
original state of the stack. I have the same problem again, so now I'm
sure that at least my changes are not the reason for the problem that
I'm trying to solve.
However, thank you that you that you try to help me. I'm still
debugging and probably soon I will find out the reason. It must be
something connected to the way I use the stack in the device.
Simeon
On 20.6.2017 г. 21:10 ч., [email protected] wrote:
Simeon Trifonov wrote:
Probably you will ask now what kind of bug I mean. I don't remember,
but I will try to find out. Probably my fix is not the best and you
can offer me another one.
If the bug was not being able to use PBUF_REF/PBUF_ROM for input
(since pbuf_header does not work in both directions on these types),
this should be fixed by now. Although that change might not be too
easy to backport.
I don't know if your local changes influence the bug, but how could I
know?
Simon
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
--
Simeon Trifonov
Head of department "Development"
AMK Drives and Controls Ltd.
Bulgaria / Gabrovo
Phone: +359 (0)66 819125
Fax: +359 (0)66 819101
E-Mail: [email protected]
Web: www.amk-drives.bg
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
