Hi Sylvain, Hi Simon, OK ... I've got an update. It's *not* that the 376 bytes fragments (2 and 4 in my overview) gets lost! I've written a test where I immediately send the 2x1400 bytes to the TCP connection so also the ETH is facing the queued data.
As LwIP is smart *g*, it'll fragment different here. Instead of: 1) 1024 bytes 2) 376 bytes 3) 1024 bytes 4) 376 bytes it'll fragment it like this: 1) 1024 bytes 2) 1024 bytes 3) 752 bytes Writing a known pattern in the payload I confirm that the first two packets of 1024 bytes are matching! So the 3rd fragment of 752 is just not sent over the PPP. Using the PPP_DEBUG I can see that pppifOutput is just called 2 times with a LEN of 1024 bytes each. For the last 752 bytes fragment, pppifOutput is not called. We try to dig deeper here, but as we don't have a deep knowledge of the internal structure of LwIP any help or idea how to debug is appreciated ;-) Marco >Using an RTOS doesn't change anything, your uart tx function must wait if your >fifo/queue/whatever is full. >But… PPPoS in lwIP 1.4.1 is not thread safe and hard to do right. On which >context are you calling the PPP input function ? >Sylvain _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
