FSPortTest, port 6073, and dpnsvr.exe

[Air SeaTac]

I'm trying to diagnose some connection issues some of our pilots have had recently.  I run FSHost as a service on Windows Server 2003 (64 bit).  I've run FSPortTest and this is the output -

FSPortTest version 1.6
Using server: www.chocolatesoftware.com

Testing ports for FS2002, FS2004, and FSHostClient for FSX...

Port 23456... OK
Port  6073... Error: timed out waiting for response
Port  2300... OK
Port  2301... OK
Port  2302... OK

All subsequent ports are ok, port 6073 UDP is open on the firewall (there's no port forwarding involved because we're directly connected to the internet), and port 6073 UDP shows up in netstat output.  Any suggestions why this port is timing out & whether it could contribute to connection issues?

[Russell Gilbert]

I'm trying to diagnose some connection issues some of our pilots have had recently.

Hi,

One thing to check is that FSHost, FSHostClient, and Flight Simulator are all shut down before running FSPortTest.

You mentioned seeing port 6073 in netstat.  What is it showing exactly?

Thanks,
Russell

[Air SeaTac]

'Netstat -an -p UDP' shows 'UDP    69.194.193.216:6073    *:*'

I thought I read somewhere that only the sessions needed to be stopped while running these tests, I've done that by using the 'Stop' butting in the Session tab on the web interface.  Do I have to stop FSHost in it's entirety before running the test?

[Russell Gilbert]

From your answers I'm thinking maybe I've got this whole FSPortTest thing confused.

I think the netstat output is indicating that some other program is listening on 6073 and probably causing the problem.  Let's see if we can figure out which program it is.

Try running netstat with "-b" added to the end, to display the program involved.  So like this:

netstat -an -p UDP -b

Note that the program name seems to be listed below the port number, not above.

Russell

[Air SeaTac]

That shows -

  UDP    69.194.193.216:6073    *:*
  [dpnsvr.exe]

I Googled the .exe & it's the Microsoft Directplay server, so I guess the right program's listening on that port (I know 'listening' is not the right terminology for UDP)

Edit:  I've just checked Process Explorer & there's two instances of this program running, do you know if that's normal?

[Russell Gilbert]

Yes, dpnsvr.exe is the DirectPlay server, and it's what listens for incoming data on 6073. But usually you'd only see that when a session was active, and I've only ever seen one instance of it running at a time. I wonder if you somehow got two of them running and they hung up, even when FSHost's game servers were stopped.

I'd suggest rebooting, or possibly just killing all instances of it, and checking netstat again.

Russell

[Air SeaTac]

Happy new year to you & your family Russell

I restarted the FSHost service and this got rid of the 2nd instance of dpnsrv.exe, the trouble now is that I'll always get a timeout on port 6073 because when I stop the FSHost sessions it stops the dpnsrv.exe process (think you hinted at that in your last post).

Not sure if there's a particular service which runs this process, but I'm worried that if I try to keep it running manually I'll end up with two instances of it again when FSHost is started.

Edit:  Tried running it manually after FSHost had killed it's own dpnsrv process, but still timed out on port 6073.

[Air SeaTac]

Some more info -

When I stop the FSHost sessions from the web interface, the dpnsrv process takes time to be killed by FSHost, and sometimes isn't killed at all, when the process is left running a 2nd dpnsrv process is started when the FSHost sessions are restarted, that's probably why I saw 2 processes as reported earlier.

FSPortTest gives the 'green light' on all ports (including 6073) when all dpnsrv processes are terminated and the FSHost sessions are stopped (how does that work when there's nothing 'listening' on port 6073?)

[Russell Gilbert]

Ok, great, sounds like you're getting there.

When FSHost stops the game servers, you shouldn't see any instances of dpnsrv still running. I usually see it go away immediately, but I could understand if it took a bit of time -- that process is part of DirectPlay, and FSHost doesn't interact with it directly, so it's not actually FSHost that's telling it when to start and stop. But the act of stopping the game servers should usually be enough for DirectPlay to terminate dpnsrv automatically. If you have two instances running for a long period of time, I'd assume something was wrong.

You want all instances of dpnsrv to be stopped before you run FSPortTest. That's because FSPortTest itself listens on each of the ports when it checks it, and if something else is already listening on that port (like dpnsrv listening on 6073, or FSHost listening on port 80), it'll usually fail the test. That's why everything related to FS multiplayer should be stopped before you run FSPortTest, so it has exclusive access to all the ports.

Russell

[Air SeaTac]

Ah, understood.

I'll give it one more try later but it looks like I'm ok with the port test, giving me 'ok' on all ports when FSHost sessions & dpnsrv are properly shut down

[Air SeaTac]

Did one final test to be sure & I can confirm dpnsrv.exe doesn't always get shut down when stopping the FSHost sessions.  FSPortTest gives me the 'all clear' when it's shut down manually though.

Might look into this problem at a later date, but now I know what to look for it's not really a problem any more.

[Russell Gilbert]

Good to hear!

Thanks,
Russell

[AST003]

Russell,

I have been having a problem with port 2302 for FSX.  I run the port test first and everything is fine.  When I connect to FSHost and rerun the port test port 2302 times out.  This will happen if I connect without anyone online or with other online on the server.  When others are already on the server, my entry boots everyone which is not good so I can't connect when players are already in the session.  I now always need to wait until there is an empty session to connect to avoid booting everyone.  Any ideas?  If I look at the resource monitor it shows four instances of FSHostClient.exe listening to 2302 with firewall status as allowed, not restricted.  Thanks in advance for any help you can give.

AST003
Jim Hodde