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

[Jochen Strohbeck]

Hello Indan!

As far as I understand the trace, the ACK is to the SYN packet before
(49564):

328782  137.544808074   192.168.0.6     192.168.0.100   TCP     74      [TCP 
Port numbers
reused] 49564 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1
TSval=1370931857 TSecr=0 WS=128

328783  137.545136624   192.168.0.100   192.168.0.6     TCP     60      80 → 
49564 [ACK]
Seq=1 Ack=4286058530 Win=2764 Len=0

328784  137.545170810   192.168.0.6     192.168.0.100   TCP     54      49564 → 
80 [RST]
Seq=4286058530 Win=0 Len=0

328785  137.553397500   192.168.0.6     192.168.0.100   TCP     74      [TCP
Retransmission] [TCP Port numbers reused] 49564 → 80 [SYN] Seq=0
Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1370931865 TSecr=0 WS=128

328786  137.553698566   192.168.0.100   192.168.0.6     TCP     60      [TCP 
Dup ACK
328783#1] 80 → 49564 [ACK] Seq=1 Ack=4286058530 Win=2764 Len=0

328787  137.553751807   192.168.0.6     192.168.0.100   TCP     54      49564 → 
80 [RST]
Seq=4286058530 Win=0 Len=0


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?


BTW: I noticed that this failed TCP connection 49564 is not logged if
TCP_DEBUG is enabled which means that a lower lwip layer handled this
connection request.

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.

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

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.

Regards,
Jochen