Bug #18007

[Linux DS] PMTU Discover issue.

Added by Swappp over 4 years ago. Updated over 3 years ago.

Status:Closed Start date:03/02/2011
Priority:High Due date:07/01/2011
Assignee:Dwarden % Done:

0%

Category:Server
Target version:1.60.87580
Affected ArmA II version:1.59.79548 Linux Server First affected build:
Reproduced by another DH user:Yes First affected ArmA II version:
I am using some Mods:No Single / Multi Player?:
I am using:OA only BIForumURL:
Reproducible for you:Yes NGUrl:
Related to content of DLC: WIKIurl:

Description

Some clients have troubles with connection to the dedicated linux server. The problem is related to PMTU Discover. Some routers and ISP have MTU less then server interface. By default Linux DS sends UDP packets with DF (don't fragment) bit. In general case router with MTU less then packet size must drop packet with DF bit and send back ICMP packet "fragmentation needed" (ICMP type 3, subtype 4). But some ISPs and routers drop packets without send ICMP packet or just block ICMP.

As a result, some clients can't connect to Linux DS. This problem also know as stuck on "Wait for host" and "Receive data" screen.

One way to resolve this problem is to disable PMTU Discover in system ("echo -n 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc"). Then UDP packets are sending without DF bit. But some ISP drop fragmented packets, and other players can't connect. Also this disables PMTU Discover for TCP.

Windows DS don't have such problems, in cause of it doesn't set DF bit, and send UDP packets with size ~1050 byte when client is connecting.

The manpage ip(7) says:
While MTU discovery is in progress, initial packets from datagram sockets may be dropped. Applications using UDP should be aware of this and not take it into account for their packet retransmit strategy.
To bootstrap the path MTU discovery process on unconnected sockets, it is possible to start with a big datagram size (up to 64K-headers bytes long) and let it shrink by updates of the path MTU.
To get an initial estimate of the path MTU, connect a datagram socket to the destination address using connect(2) and retrieve the MTU by calling getsockopt(2) with the IP_MTU option.

History

Updated by kju over 4 years ago

  • Due date set to 06/01/2011
  • Status changed from New to Assigned
  • Assignee set to Dwarden
  • Reproduced by another DH user changed from No to Yes
  • I am using set to OA only
  • Reproducible for you changed from No to Yes

Great info Swappp!

I am pretty sure many people are plagued by this issue and
we had several tickets about this problem, yet we could never
determine the exact source.
So far people could only change their router and most time it helped.

Updated by Dwarden over 4 years ago

  • Priority changed from Normal to High
  • Target version set to Upcoming version

Updated by Dwarden over 4 years ago

  • Operating system set to Linux

Updated by UnNamedRUS over 4 years ago

Linux Server beta 1.59.79548 also has this problem.

Updated by kju over 4 years ago

  • Due date changed from 06/01/2011 to 07/01/2011
  • Affected ArmA II version changed from 1.57.76894 Linux Server to 1.59.79548 Linux Server
  • Language deleted (Please set for missions)

Updated by Mikhail over 4 years ago

Have Linux DS with latest patch. One player never managed to get past map into the game. His unit is spawned ingame, but he reported staying at map and having no control of his unit.
Another player had no issues for a month, then got the same problem without any luck to resolve.

(By the way he reported to have the Invisible\Ghost player issue before that. He said after he was killed he respawned, saw the game and layers, killed them but had a very laggy and jumpy models. Other players told that they didn't saw him or got any damage. As if he was in a parallel game.)

Log show only that he connects and nothing more.

RPT empty too.

Both of them have no issues on hosted games.

Can this be the same issue?

Updated by UnNamedRUS over 4 years ago

Mikhail wrote:

Have Linux DS with latest patch. One player never managed to get past map into the game. His unit is spawned ingame, but he reported staying at map and having no control of his unit.
Another player had no issues for a month, then got the same problem without any luck to resolve.

(By the way he reported to have the Invisible\Ghost player issue before that. He said after he was killed he respawned, saw the game and layers, killed them but had a very laggy and jumpy models. Other players told that they didn't saw him or got any damage. As if he was in a parallel game.)

Log show only that he connects and nothing more.

RPT empty too.

Both of them have no issues on hosted games.

Can this be the same issue?

90% is suitable for this problem.

Updated by Mikhail over 4 years ago

UnNamedRUS, any solutions to recommend?

I know so far about

  • router\modem replacement
  • Network card drivers reinstallment
  • And new network card.

Updated by UnNamedRUS over 4 years ago

Mikhail wrote:

UnNamedRUS, any solutions to recommend?

I know so far about

  • router\modem replacement
  • Network card drivers reinstallment
  • And new network card.

If this fails echo "sudo echo -n 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc", then you have to experiment with "ip route"

Updated by Mikhail over 4 years ago

Ouch. It's a hosted game-server with no root acces. But anyways, thank you very much! If it comes to it I'll tell about it to my tech sup.

Updated by UnNamedRUS over 4 years ago

Mikhail wrote:

Ouch. It's a hosted game-server with no root acces. But anyways, thank you very much! If it comes to it I'll tell about it to my tech sup.

Can detailed instructions for action to send the mail. Here is my address .
My native language is Russian, but google translate helps me :-)

Updated by Mikhail about 4 years ago

Swapp from flashpoint.ru told me that they solved all issues by tweaking their server's PMTU settings. But he insisted adding "Use at your own risk, this is a workaround and my not work with everyone and server can have performance impact" to his solution.

That's what he told me.

"MTU is 1500 now and we set:
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
and edited /etc/sysctl.conf to:
net.ipv4.ip_no_pmtu_disc = 1
so that this setting remains after reboot.
No one ever complained." 

But again, as he said later, use at your own risk, this is a workaround and my not work with everyone and server can have performance impact.

I asked my server provider tech support to set this for me. I'll report back if it works (but may be they'll refuse to change this config, who knows.)

Updated by jaynus about 4 years ago

This MTU issue we have also recently seen extremely common from other less standardized countries (we have multiple players from brazil who get the MTU issue, for example). This is on a windows server, and the MTU issues are always strictly from the client end with sub-standard MTU settings (usually 3rd world DSL like I mentioned in brazil).

Here are our server configs:

language="English";
adapter=-1;
3D_Performance=10000;
Resolution_W=160;
Resolution_H=120;
Resolution_Bpp=16;
viewDistance=10000;
MinBandwidth=10000000;
MaxBandwidth=2147483647;
MaxMsgSend=1024;
MaxSizeGuaranteed=1024;
MaxSizeNonguaranteed=64;
MinErrorToSend=0.0040000002;
maxCustomFileSize=0;
Windowed=0;

The above settings cause what our players have dubbed "the 62 bandwidth bug". Their bandwidth in game shows at permanently 62. This is usually fixed by one of two methods:
1. they call their ISP and have them adjust the MTU settings or reboot endpoint routers
2. We actually have some players that can fix it by re-initiated a new UDP stream to our server (FTP), this seems to also clear the MTU black hole.

Updated by Suma almost 4 years ago

The game is not using any explicit IP_MTU_DISCOVER or IP_DONTFRAG, system wide defaults should be used. The game is not performing any MTU discovery, the intention is the message size as defined by MaxSizeNonguaranteed and MaxSizeGuaranteed should be small enough to not cause any MTU issues (if server admins are overriding it, they should have MTU in mind).

It is possible some Linux systems have defaults force the MTU discovery. We could try disable the MTU discovery explicitly, this page seems to describe how to do so:
http://stackoverflow.com/questions/973439/how-to-set-the-dont-fragment-df-flag-on-a-socket

Updated by Suma almost 4 years ago

  • Status changed from Assigned to Resolved

IP_MTU_DISCOVER = IP_PMTUDISC_DONT is now used on Linux, IP_DONTFRAGMENT = 0 on Windows. This should make manual system wide changes like ip_no_pmtu_disc no longer necessary.

Updated by Dwarden almost 4 years ago

  • Target version changed from Upcoming version to 1.60 BETA

Updated by bebul almost 4 years ago

Suma wrote:

IP_MTU_DISCOVER = IP_PMTUDISC_DONT is now used on Linux, IP_DONTFRAGMENT = 0 on Windows. This should make manual system wide changes like ip_no_pmtu_disc no longer necessary.

And Linux server version 1.60 was uploaded on ftp://downloads.bistudio.com/arma2.com/update/a2oa-server-1.60.86521.tar.bz2 at last.

Updated by Sickboy almost 4 years ago

Can anyone confirm fixed?

Updated by Fireball over 3 years ago

  • Status changed from Resolved to Closed

Mass-closing resolved issues for 1.60.

Please re-open or, preferably, create a new ticket for (partially) unresolved issues.

Updated by kju over 3 years ago

  • Target version changed from 1.60 BETA to 1.60.87580

Also available in: Atom PDF