Hi,
(I report this as a theoretical bug only based reading the code/specs)

The window value in a segment is relative to its ACK number. Consequently pcb->snd_wnd is relative to pcb->snd_wl1. But tcp_output seems to assume it is relative to pcb->lastack.

I suppose a discrepancy between lastack and snd_wl1 can occur when a segment is received that:
- Is recognized as a window update but not a valid acknowledgement.
- Is recognized as a valid acknowledgement but not a window update.

(I have not done any more detailed analysis when this can occur)

Depending on the case snd_wl1 may become smaller or larger than lastack. Effectively tcp_output may end up transmitting more data than the advertised window allows, or limit the amount of transmitted data unnecessarily, respectively.

Note, I also think there is a similar spec bug in RFC 793 p72, in "If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK." (SND.UNA is lastack, updated due to newly acked data). Here it is not considered that SND.WND is relative to SND.UNA, so by increasing SND.UNA without a corresponding decrease of SND.WND, the effective send window could now be larger than the remote permits.

I see two approaches to fix this in lwIP:
1. Change tcp_output to consider snd_wnd relative to snd_wl1 instead of lastack.
2. Change any relevant code to always keep snd_wnd relative to lastack (e.g. window update and lastack update).
... but I'm not comfortable implementing anything specific due to possible ripple effects, and also I'm currently writing my own new TCP/IP stack :)