Have you checked the tcp_write() return code ? Do you call tcp_sndbuf() to see what your available room is ? You seem to have said so in the first thread, so you actually get out of buffer space. Maybe you don't free your received pbufs. Do you know you have to wait for the other end to send ACKs so the stack can free your transmitted buffers and signal you can send more by means of the tcp_sent() callback ?
> Once .10 starts sending data, after 300ms, the seq no it sends with is > 1 and the ACK field is 1461. However, .74 sends back an ACK with 9251. No, it is not, you are confusing seq numbers with ACK numbers, the sequence is correct as far as I understand how TCP works. Unfortunately I don't have the time nor is this the space for a TCP crash course. ACK numbers reflect the expected seq numbers for the next message from the other end. In frame 19, .10 is acknowledging it got data upto 9251 (next data byte will be 9252) and sending 1446 bytes starting from 1 at the same time (piggybacked ACK). Regarding that jumbo frame, I don't know what stack is running on .74 and why it does that. Furthermore, the fact that .10 issues to ACKs for that, one in frame 18 and the other piggybacked in frame 19, makes me think that actually two frames got out and what we see is an artifact of the capture driver on .74 where you run wireshark because it is a PC or equivalent (what you don't say) I would check on .10 what it sees and why it can't transmit. You have statistics you can enable and see how memory pools are being handled. You can put breakpoints and check return codes. Your problem, IMO, is in your application, but there is a possibility you have a broken driver/port or something else. _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
