I see you're using D or D+ Controller and I think you will struggle using TCP/IP via K-Roset for this.
I myself, have never done any TCP/IP work in K-Roset using a D/D+ configuration, so never knew this was a problem.
I have managed to replicate what you're seeing using D/D+ configuration and it is evident a connection request is coming in from within windows OS on the specified port, and even though K-Roset is accepting this request, it is not binding the port to the IP, so with my limited network skills, I am unable to determine the source of the request.
However, using an E configuration with a ZX165U, this request does not appear to be seen, and therefore is not causing a problem.
So, I can only assume/speculate this is a problem within K-Roset TCP/IP and the associated firmware/application programming within K-Roset.
In usual circumstances, the accepted request would bind a socket no. provided by K-Roset to the incoming requested IP address.
These details would be displayed in the zprsocket displayed information.
But this is not showing a socket ID no from K-Roset or the source IP address normally displayed in reverse order - ie 1.0.0.127
So I can only assume, this is a failing within how K-Roset is operating on the TCP/IP using the D/D+ Controller built in firmware for the simulation.
I would be interested to see if there are any 'Network guru's' out there that could look into this and maybe track down a 'service' within windows that could be stopped and thus possibly prevent this from occurring.
But even then, I believe the root cause would actually be attributed to K-Roset though.
The only thing I can suggest is to continue development using a ZX165U using an E Controller inside K-Roset instead.
This way you can test/prove your sequencing from a simulation perspective.
Your final code should be transferrable and executable within a live D/D+ Controller when complete though.