Re: [lwip-users] ACK missing after SYN, strange high Ack Num

[Indan Zupancic]

Hello Jochem,

Because you talked about performance and load my mind replaced SYN with 
FIN,
please disregard my previous e-mail.

On 2022-06-01 12:56, Jochen Strohbeck wrote:
> The sender sends an RST to 49564. It make one more retry with the same
> result and the request fails with timeout error. Is my interpretation
> correct?

I think the key here is "TCP Port numbers reused". If you open and close
many TCP connections to the same host MS Windows will re-used a recently
used port which is still in the CLOSE WAIT state on lwIP's side.

The behaviour you see here is expected and no one is doing anything 
wrong
(It's fine to use random ports and occasionally re-use recent ones, as
long as the error is not propagated to the application).

> Do you know where which function / code makes the decision to do a ACK
> after SYN? Probably I can trace back from here to find the root cause.

In this case lwIP probably thinks it's a previous connection.

> So telling from you post: ACKing on SYN is the correct behavior for a
> device which is not able to process the connection request?

ACK and SYN flags are independent, sending only and ACK is fine,
though in practise no one does that. Maybe lwIP does it if the
connection backlog is full. But if such an ACK is send, it will
always ACK the SYN and not something else.

> I still wonder about the 'insane high' number 4286058530 in the '[ACK]
> Seq=1 Ack=4286058530' reply, so I'm not sure if the protocol handling 
> is
> correct here.

Sequence numbers are randomly chosen for each connection. Wireshark
translates them to a logical value. So if the ACK is for a previous
connection and not the SYN packet, the ACK value will pretty much
always look ridiculously high. The raw value should match the FIN
sequence number send in the previous connection with the same port.

Greetings,

Indan