> Anyway, unless the client end is really messed up, it shouldn't send both the ACK on the first SYN This is a race condition; hypothetic sequence of events:

> Anyway, unless the client end is really messed up, it shouldn't send both the ACK on the first SYN This is a race condition; hypothetic sequence of events: send SYN-0, wait for reply or timeout timer interrupt fires timeout to resend SYN(-1) is ready, start running that packet interrupt fires (interrupts resend) got SYN+ACK-0, construct and send ACK-0 iret finish constructing SYN-1 and send it iret again This is clearly a bug, but it could easily work >99.99% of the time (especially if the timeout is high enough that normal RTTs never hit it, which is probably how the person setting the timeout would try to set it).