I wanted to add an update to this issue. By checking the interrupt status in the Ethernet interrupt I confirmed that an RX FIFO overrun error was indeed occurring with the HTTP POST request. It seems the LM3S6965 receive FIFO is 2K. I think something else is going on though, because even after adjusting the TCP_MSS to 960 and TCP_WND to 1920, there are still very long delays (about 1.2 seconds) between the received packets and the ACKs sent by the device running lwip. At least there aren't any dropped packets or duplicate ACKs though. I've attached a new packet capture.
This processor is running at 50MHz. One noteworthy thing is how the lwip port related code is handling the Ethernet interrupt. It uses a Queue to signal a FreeRTOS task when data is available from the Ethernet interface. This task does the actual handling of the data received from the Ethernet MAC. I scheduled this task as the highest priority one in the system, but it doesn't seem to make a difference. The system is idle most the time, so I can't see how task priority would account for 1.2 seconds of ACK delay.
I turned off the naggle algorithm with the HTTP listen port, not sure if this also needs to be done with the accepted connections though.
Best regards,
Element Green