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
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 ч., address@hidden 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
address@hidden
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: address@hidden Web: www.amk-drives.bg