Why would a server ack a packet and then ack the same packet plus one?

An FTPS upload sometimes works and sometimes fails. The client sends all the data but has not had it all acknowledged. It then sends FIN to close it's half session. The server is sending DUP ACKs because it has not receives several of the packets. The DUP ACKs result in retransmissions as they should. The server ACKs a retransmission of a 1460 byte packet and then ACKs one byte more. The client retransmits one byte past the previous segment. Server asks for the original next segment but does not accept it.

-> seq 36044 len 1460 next seq 37504 
<- Dup ACK 37504
-> seq 37504 len 1460 next seq 38964
<- ACK 37505                              **** SEEMS QUITE ABNORMAL ****** 
-> seq 37505 len 1460 next seq 38965  TCP OUT OF ORDER     ****** BUT RETRANSMITTED ANYWAY *****
<- Dup ACK 37505                          ********* This cones back immediately  
<- Ack 38964                              ********* NOW BACK TO NORMAL BUT REJECTED BY SERVER
-> seq 38964 len 1460 next seq 40424      ********* NEVER GETS PAST THIS ************
<- Ack 38964

The retransmitted data occurs after RTO. Each duplicate ACK comes back one RTT later (.203,..486, 1.007, 2, 4, 8, 16)until server sends FIN at sequence 146 which is Acked as 147. Server resets.

<- seq 146 0 next seq 38964
-> Ack 147      
<- RST  seq 147

To me it seems like the client has received the ACK for a FIN with an incorrect and very early sequence number. It won't except anymore data - it thinks it is done?

Sessions that don't have this odd Ack+1 all work.

Have you ever seen anything like this? I don't think there is anything but firewalls and the internet between client and server. I can't blame this on a proxy.

Please let me know what you think.

Thank you

R F Hayden