Hi Sergio, Thank you for your detailed help. I actually began from the beginning and parsing step by step I understood the points and junctions at which I had messed up a lot of concepts. Your answers were a guide at every step. Thanks again
On Fri, Feb 12, 2016 at 6:40 PM, Sergio R. Caprile <[email protected]> wrote: > 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 _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
