INFO: Servers, Clients and "Ping Timeout"

[Panzertard]

Okai, I had to dig a bit into this one myself - so bear with me.

 

Easy things to check on your own side:

- Replace your cables! It's one of the easiest things to check - and darn cheap.

- Using Wireless? Don't! Use cables from your PC to the router.

- "Bigfoot Networks Killer XENO Pro" in your PC? Set it to application mode.

- Can you borrow a router from a friend? Test-replace your own with a new one, and see if that improves your situation.

- Router firmware upgrade/downgrade. It can be quite dangerous if you dont know what to do - it *can* break your router and leave you without internet and a very angry wife.

But a few routers and firmware may cause undesired package loss (DLINK anyone?).

- Your router logs - very easy to forget - find them and read them.

 

 

------------

 

Symptoms and how to investigate:

 

A few facts first:

- FC2/DCS is NOT using ICMP (Windows/Linux "ping" wont give any answers)

- FC2/DCS uses both TCP and UDP for certain mechanisms.

- UDP is a lightweight protocol, it's not meant to be reliable.

- TCP is meant to be reliable, but it comes with a added latency / bandwidth cost.

 

* Others can connect - but I cannot.

* I can play but I loose connection now and then.

The sum of packetloss (UDP) "from you--> to the server --> and back to you" is too high.

If you cannot improve the server's (ISP, cables, routers etc) then you can only try to improve things on your own side.

Typically you may find this in the <gamefolder>\Temp\network-<datetime>.log:

[size=1]6.361000: Lua: events.lua loaded[/size]
[size=1]NET: 6.361000: Lua: events.lua loaded[/size]
[size=1]NET: 6.362000: Lua: loading ./Scripts/net/default.cfg : OK[/size]
[size=1]NET: 6.362000: Lua: loading ./Config/network.cfg : OK[/size]
[size=1]NET: 6.362000: Lua: loading ./Scripts/net/net_types.lua : OK[/size]
[size=1]NET: 11.607000: client has started[/size]
[size=1]NET: 28.856000: server maxPlayers=32, numPlayers=1[/size]
[size=1][color=seagreen]NET: 28.857000: connected to server[/color][/size]
[color=seagreen][size=1]NET: 28.857000: Lua: on connect: 153.221.12.140:10308[/size][/color]
[color=red][size=1]NET: 237.175000: disconnected: Server ping timeout[/size][/color]
[color=red][size=1]NET: 237.180000: disconnected from server[/size][/color]
[size=1]NET: 623.672000: disconnected: [/size]
[size=1]NET: 623.672000: disconnected: [/size]
[size=1]NET: 623.672000: client has stopped[/size]

 

* I pinged the server, but got no response.

ICMP and ping is not required for FC2/DCS to work.

Unfortunately Telnet is the only reliable method - but you could ask the server-owner to try to open for ICMP/Ping, then you may be able to use this method later.

 

* Telnet worked, but I cant connect with FC2 to the server.

TCP may be open in your firewall, but UDP openings may be missing.

Or UDP may be lost enroute and back to your again.

 

* Telnet didnt work as expected.

You couldn't reach the server over internet

- TCP may be blocked in your firewall, or on the server firewall.

- Incorrect port, is the server using 10308 or some other port?

Can other people connect?

 

* Playtesting: Playing MP on that particular server

This is the only method for determining if you have a reliable connection.

You dont have a reliable connection to the server if:

- you cannot connect.

- you can connect, but drops out after a while.

Too many UDP packages are not reaching the server and back to you.

 

------------

Test procedures for the tech savvy

 

* So what to do to check if you can reach a server?

You cannot use "ping nn.xx.yy.ww", it's not supposed to answer.

However you can "telnet <serverip> <serverport>".

Example: for my server on LAN: "telnet 192.168.101.98 10308"

 

If you do that from a CMD prompt, telnet, and:

• GOOD: the CMD goes "black" - followed by a lot of rubbish - then you have a connection. Close the CMD prompt.
  
  • Firewall and Route is OK.
    

  [*]BAD: the screen waits and you get "Could not open connection to the host, on port 10308: Connect failed"

  • - there are no "server answering your request".
    
  • - Or the route through internet and back is broken.
    
  • - Or a firewall along the way is blocking the port.
    You are NOT reaching the server - or it cannot reach you.
    

Now you have determined if you *can reach* the server.

You have not determined if you have a *reliable* connection to it.

 

Server Admins:

- Check and recheck any NAT rules.

Network translation may be incorrectly configured - but that should cause loss for both TCP and UDP.

As long as you're past getting TCP working then NAT should be configured correctly.

Acedys PING TIMEOUT suggestions: http://forums.eagle.ru/showpost.php?p=737045&postcount=81

 

Other useful tips:

- Tracert *can* indicate how many hops you have to the server.

Many hops (> 15 hops): Very likely that you may expect a few more losses than normal, as well as higher latency.

Short / medium route (1-15 hops): You shouldn't expect package loss.

But thats it - tracert cannot tell you if you have a reliable connection.

 

- Properly configuring the router for the correct mode (or zone) such as sniffer suggested here.

 

----------------

 

FINAL NOTE: Telnet is not installed by default on Windows 7.

You may have to add this using Control Panel -> Programs -> Add Windows components -> Telnet Client

Edited April 11, 2010 by Panzertard

[RastaPutin]

Seems an awful lot of techno babble to get a trivial piece of code written in the last years of the first decade of the 21st centuary to work.

Strangely I nor do most folks have any similar problems connecting to stable, well written and fully tested MP applications or MP gamming enviroments.

 

Perhaps the solution is for ED to spend a little more time making the MP connectivity, fully functional and robust. ( Along with the Editor :) )

 

That said - nice post PT.

[Vitesse2l]

Thanks for the information Panzertard.

 

It helped me troubleshooting my connection problem today and I think (hope) I have cured it.

 

Don't think it was ED's fault. More likely mine from fiddling where I shouldn't!

[c0ff]

FC2 uses the same network code as DCS (and original LOMAC), and we didn't get so many bugreports with BlackShark and LO.

Something went wrong, and it slipped through testing.

We'll check this out.

 

Anyway, I find this thread a little confusing.

Or things are really this bad?

[Panzertard]

FC2 uses the same network code as DCS (and original LOMAC), and we didn't get so many bugreports with BlackShark and LO.

Something went wrong, and it slipped through testing.

We'll check this out.

 

Anyway, I find this thread a little confusing.

Or things are really this bad?

I must admit - one need to be quite techy to understand this topic. And I'm a bit gimped writing such techy stuff because this is what works for me. :inv:

 

But folks (anyone) if you have some better way of presenting troubleshooting Ping Timeouts - please throw some post content, and I'll revise mine :)

Trobleshooting UDP is hard though, thats the nature of UDP. Now if there was no UDP in the games, then it would be easier of course. But games benefit from UDP in many occasions. :)

 

But now if you say you also detected some snags in the code, c0ff - thats good news? It means it'll be less prone to disconnects in the future?

EDIT: Rearranged the OP a bit.

Edited April 9, 2010 by Panzertard

[Vitesse2l]

I don't think there is anything much wrong with the MP code. My problems were certainly at my end.

 

I flew two hours yesterday evening FC2 and BS with no problems at all.

 

Not sure what Rastaputin is on about.

 

A few members posted http://forums.eagle.ru/showthread.php?t=51983 with MP problems and PT has been most helpful.

 

Cheers!

[Distiler]

FC2 uses the same network code as DCS (and original LOMAC), and we didn't get so many bugreports with BlackShark and LO.

Something went wrong, and it slipped through testing.

We'll check this out.

 

Anyway, I find this thread a little confusing.

Or things are really this bad?

 

No, things are not bad, in fact MP is way smoother than DCS:Ka-50 so something changed for the better. I played lots and lots of hours and had just a couple of ping outs. The thing is, my internet connection never went down (I was in TeamSpeak) and my ping stayed all the time below 100. This never happened with DCS:Ka-50. So, it's not bad but "perhaps" there something worth to look at.

[104th_Crunch]

Another suggestion. Many router companies offer good free technical support by phone. I had disconnects and called in. I was lucky to get a good rep that walked me through settings for my router that fixed my problems. I then saved the setting and backed them up.

 

Thanks Panzertard.

[TheMoose]

http://portforward.com/

 

Been posted before, but still good for this thread.;)

[Breakshot]

Guys quick question!

 

Is it still possible to adjust "client/server timeout" settings in some network file (like in FC1) just to prevent dropouts caused due to slow loading times, etc etc...? If so, then what file does this?

 

I still remember that doing wonders for many of those people with FC1 timeout problems...

 

As far as netcode is concerned, i havent noticed anything major to indicate any problems... the only thing is that sometimes the "loading map" screen can take quite a while on joining servers with heavy missions... which btw, could be a cause for a timeout?

[sniffer]

Good input Panzertard!

 

Little addiditon (maybe helpful for somebody):

 

For example my D-Link DI-524.

Tried to set some stuff but I don't know a lot about new 'server browser' from DCS. When I tried to change settings in firewall and my router has a very, very poor management of firewall rules so I wasn't able to set it properly. But to avoid some problems and avoid starting to search anywhere else (game, sys. settings, etc.) I put my router in DMZ (demilitarized zone <- love this words) and I saw a lot of servers in server browser. Thankfully D-Link DI-524 has a DMZ option so if anybody has problems with configuring router, You can try this option to be sure is that router problem.

Also good thing is to check logs (probably every router has it) - in my logs I saw a lot of blocked attempts from unknown for me IP's but port was 10308 and I knew what is going on...

[Panzertard]

Guys quick question!

 

Is it still possible to adjust "client/server timeout" settings in some network file (like in FC1) just to prevent dropouts caused due to slow loading times, etc etc...? If so, then what file does this?

 

I still remember that doing wonders for many of those people with FC1 timeout problems...

 

As far as netcode is concerned, i havent noticed anything major to indicate any problems... the only thing is that sometimes the "loading map" screen can take quite a while on joining servers with heavy missions... which btw, could be a cause for a timeout?

 

One: I'd love to find such a value myself. I'll try to dig around a little bit.

 

Two: loading causes ping timeout? No - or not that common I think.

Some of the 159th guys had this problem - they could start loading the mission now & then - but not always. Quite rarely actually.

Changed the router & the cables - problem solved.

 

IMO: I would suspect that ED are using TCP to transfer the mission over to you (reliable, but slower) - then when you play (mission loaded and ready) most of the timely data uses UDP.

I havent sniffed / netstat / perfmon the transfer to verify this - but that would be the logical thing to do.

[Ramstein]

D-Link has one of the best Router Interfaces..

I stil have snapshots from my old router..

See Black Shark is highlighted..

============

Good input Panzertard!

 

Little addiditon (maybe helpful for somebody):

 

For example my D-Link DI-524.

Tried to set some stuff but I don't know a lot about new 'server browser' from DCS. When I tried to change settings in firewall and my router has a very, very poor management of firewall rules so I wasn't able to set it properly. But to avoid some problems and avoid starting to search anywhere else (game, sys. settings, etc.) I put my router in DMZ (demilitarized zone <- love this words) and I saw a lot of servers in server browser. Thankfully D-Link DI-524 has a DMZ option so if anybody has problems with configuring router, You can try this option to be sure is that router problem.

Also good thing is to check logs (probably every router has it) - in my logs I saw a lot of blocked attempts from unknown for me IP's but port was 10308 and I knew what is going on...

[Acedy]

Guys quick question!

 

Is it still possible to adjust "client/server timeout" settings in some network file (like in FC1) just to prevent dropouts caused due to slow loading times, etc etc...? If so, then what file does this?

 

I posted this some time ago, but I didn't try it myself, so I am not sure if it works or not:

 

http://forums.eagle.ru/showpost.php?p=737045&postcount=81

[Panzertard]

I posted this some time ago, but I didn't try it myself, so I am not sure if it works or not:

 

http://forums.eagle.ru/showpost.php?p=737045&postcount=81

 

Awesome, I'll attach the url to the OP. Cheers :)

[Kuky]

Just a heads up from me... I had issues where I could connect to any FC2 server with exception of 159th... tonight I found out if I disabled port forwarding for LockOn then I can connect, if I enable it I can't connect... very weird

[Panzertard]

Just a heads up from me... I had issues where I could connect to any FC2 server with exception of 159th... tonight I found out if I disabled port forwarding for LockOn then I can connect, if I enable it I can't connect... very weird

Port forwarding or NAT yes - if incorrectly configured can cause undesired forwarding happen. Good catch, bud. :)

Look at the logs on your router, you may find some more hints there - and if you provide a screenshot of the port forwarding configuraiton we might be able to pinpoint your problem. :)

[Kuky]

But it's was not incorrectly configured, I've had this setup for years and worked fine...

[Raz_Specter]

I have been serving a few missions to our wing and on occasions we have had people disconnect with either a client timeout or a crash, funny thing is though when they try to connect back into the sim the server crashes. This might be a coincidence, we will do some further testing.

 

thanks Myth