tcp previous segment not captured

My interpretation is that

1. the server application listening at port 8085 rejects several repeated attempts of 10.1.25.60 to connect; as the repeated attempts come from different ports and none of them succeeds, it does not seem to be caused by previous session using the same client side socket and closed shortly before. Some access rules at the server application are more likely. But I don't think it is a symptom of what you're after.

2. the "previous segment not captured" can be seen only once, in frame 1723, but it seems to be a symptom of some kind of larger network failure than of just a loss of a single frame and thus a better indicator of an issue. The last "fine" frame is 1719, then there are some 78 seconds of silence, and then the client (10.1.25.60) uses ARP to find out the MAC address of the server so that it could send the next frame. The last "fine" frame has a relative seq number of 3016, the "previous segment not captured" one has a relative seq number of 3056, so there should have been a 40-byte-payload packet in the same direction but it has not been captured.
   Soon after, the server sends again an ACK to 3016 so it has also not received that 40-byte-payload packet, i.e. it is not only an issue of capturing. This seems obvious here as the capture was running at the server itself, but I mention that as it would be an important indicator if the capture would be taken somewhere else along the network path between the client and the server.
   Does the client machine happen to have several network cards (including wireless), i.e. if the proper interface would be down, could it be that the missing packet would be sent via a different interface (and lost because it would not reach the destination as there is no network route between that other interface and the server)?
   As you wrote that you've replaced a hub by a switch, I would have a look at speed/duplex negotiation settings on the ports of the switch (and compare them between ports to which different client machines are connected), as it seems to me as if the client's network interface would be occasionally down at L1. And, still following the same idea, can you compare the network adaptor type and manufacturer of those 7 machines, maybe the 4 affected ones have a common make/model different from the remaining 3? Experience shows that "some" Ethernet adaptors have speed/duplex negotiation issues with "some" switches even if settings of both are compatible to each other.