UPlay not connecting

[Odisej75]

In any Proton version I use I cannot connect to Uplay. It stops at initializing and gives an error.

Workaround is possible using VPN connection.

Works on Win 11 on the same computer, same network (no VPN necessary)

I am using Manjaro, stable, latest updates installed.

[Moilleadoir]

Uplay today won’t even display a window; just silently crashes. It was fine last week. Also Manjaro fwiw.

[Skiski]

If you are using Steam client beta, you should try opting out. It may be what is causing this. You can also try to add PROTON_USE_WINED3D=1. If it launches, then it is the steam beta client problem.

[Moilleadoir]

That was it. Thanks.

[Odisej75]

Ok. So, the problem is present in Ubuntu 22.10 as well.

When Uplay is being updated as I install a Ubisoft game there is also an error of a missing .dll but I don't believe this is the real issue. if I restart the game the Uplay starts normally but gets, as said, stuck on "initializing".

Does not happen if I use VPN.

[ErikReider]

Works when using a mobile hotspot but not when running it with ethernet....

[Odisej75]

Erik, can you share which distro are you using. I am following this issue on several forums/sites but it seems only some of us are affected which puzzles me. And no solution. So, maybe we can find something which connects all of us with Uplay problem.

I am using Ubuntu 22.10 currently (Manjaro on other compuiter).

Info on my ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) . Got this info by using the following command: lspci | egrep -i --color 'network|ethernet'

Edit: am using Pihole on my network but changing DNS settings on the computer does not help. It wouldn't work on Windows 11 anyway I think if Pihole would be an issue.

[ErikReider]

I've tried it on my Arch machine, Windows 11 partition on said machine and on my Steam Deck. It only works in Windows.

I'm running a Intel Corporation I211 Gigabit Network Connection (rev 03)

I've also tried switching DNS to no avail :/

Edit: Heres a Gist of my proton log when trying to launch FarCry 5

Edit 2: I've now also tried the flatpak version of Steam but didn't change a thing

Edit 3: I've found something interesting. I tried connecting to Ubisoft Connect with a USB Ethernet adapter (the Amazon basics one) and it didn't work but when using my phones internet over USB (Hotspot USB Tethering) it worked which also showed up as "USB Ethernet"

[ErikReider]

https://bugs.winehq.org/show_bug.cgi?id=53346

[ErikReider]

Update: Works now after I set net.ipv4.tcp_mtu_probing to 1 (only probes when an ICMP black hole is detected). Also had this issue on my Steam deck so @kisak-valve, maybe add this to SteamOS? (Don't know if you're the correct person to contact regarding that 😅)

[Peter-JanGootzen]

@ErikReider That completely fixed my issue as well! Thanks a lot for posting it here as well. :pray: To fix it on the current boot (to try out if it works for you):

sudo sysctl -w net.ipv4.tcp_mtu_probing=1

To fix it permanently (until a ful SteamOS update I presume):

echo net.ipv4.tcp_mtu_probing=1 | sudo tee /etc/sysctl.d/zzz-custom-mtu-probing.conf

[tuxtergames]

guys, sorry if its not correct place to put my question, my problem is that I logged in and after sometime playing through steam uplay just disconect me for inactivity make me log again in my account, sorry but I don't find answer anywhere

[kakra]

Wow! Really? MTU probing? Whatever the Uplay connector is doing, with net.ipv4.tcp_mtu_probing=1 it now just works (maybe it sends the DF flag without evaluating the resulting ICMP packet). Great. I wonder if this is an issue in wine itself or Uplay. If it is in wine, it may fix other games, too, which have connection problems. OTOH, the sysctl description reads like you may want to have it set to 1 anyways, so I did.

[dangerousdonut]

Seeing this issue now under Proton Experimental. A persistent error message "Connection Lost. A Ubisoft service is currently unavailable. Please try again later."

Any chance this gets addressed in a way that won't require changing an obscure value via command line?

As I was searching for a solution, I also saw people suggest switching to Proton 7.04 to fix it (not workable at the time of writing since compatibility is broken outside of Experimental), and in another Reddit post about these issues on Windows someone changed a flag in the registry to get around it.

Maybe those are related somehow.

[ErikReider]

Seeing this issue now under Proton Experimental. A persistent error message "Connection Lost. A Ubisoft service is currently unavailable. Please try again later."

Any chance this gets addressed in a way that won't require changing an obscure value via command line?

Have you tried changing the value? Running sudo sysctl -w net.ipv4.tcp_mtu_probing=1 only lasts until you reboot.

in another Reddit post about these issues on Windows someone changed a flag in the registry to get around it.

Does it work?

[dangerousdonut]

Have you tried changing the value? Running sudo sysctl -w net.ipv4.tcp_mtu_probing=1 only lasts until you reboot.

I haven't yet. I trust it could work, but I'd rather not rely on solution like that, which is why I was wondering if a more permanent fix was realistic. Having to use the console is where I draw the line for how far I'm willing to troubleshoot just to play a game. I'm sure that's unsatisfying, but I'm just a relatively casual Steam Deck user.

Does it work?

I looked around briefly in system.reg in the compatibility folder, but I couldn't find the relevant thing to adjust. I'm not savvy enough to know what to look for even. I added the line "DisabledComponents"="32" under the path they referenced, but that didn't do anything, and I have no clue what to do in there anyway :<

[kakra]

I trust it could work, but I'd rather not rely on solution like that

While the launcher should probably handle such situations better, I'd actually recommend this kernel setting. It tries bypassing ICMP blackhole routes by probing for lower MTU, it won't affect connections that do not indicate that a lower MTU may be needed. Such network problems are usually out of your scope of influence.

In this case, something may be badly configured on the Ubisoft server side. Maybe they try to prevent fragmentation by intentionally blocking packets being too big, for better multiplayer latency. And by doing so, they rely on Windows behavior to automatically probe lower MTU if proper ICMP replies were received. Setting this sysctl setting should match that behavior.

OTOH, there may be a bug in wine which prevents the launcher from automatically using smaller packets in the first place. This sysctl setting will automatically tune the connection for optimal packet size then. Or wine doesn't use the proper MTU in the first place regarding routing to the internet (which usually needs a lower MTU than your local networking).

I added the line "DisabledComponents"="32" under the path they referenced

According to the reddit link, this may only affect people connecting via IPv6. So maybe the IPv6 routing path at Ubisoft is a little bit awkward configured... TBH, I'd rather enable MTU probing than disable IPv6 because, if supported, IPv6 fixes a lot of problems for gaming with IPv4 NAT routers.

I don't think this registry setting does do anything for wine.

[Nowa-Ammerlaan]

OTOH, there may be a bug in wine which prevents the launcher from automatically using smaller packets in the first place. This sysctl setting will automatically tune the connection for optimal packet size then. Or wine doesn't use the proper MTU in the first place regarding routing to the internet (which usually needs a lower MTU than your local networking).

I don't think it is a bug in wine/proton. I tried the Ubisoft launcher in a Windows 11 VirtualBox, which works just fine if the virtual network adapter is configured in bridged mode (i.e. the virtual machine can access the network adapter directly). But if it is in NAT mode I get the exact same problem (i.e. the Windows virtual machine network has to go through the Linux host). In this case proton/wine is not involved at all and the launcher still can't reach the server.

The net.ipv4.tcp_mtu_probing=1 workaround is great though, much easier than what I was doing before (connecting through a VPN, which causes a whole bunch of new (performance) problems).

[ErikReider]

I don't think it is a bug in wine/proton. I tried the Ubisoft launcher in a Windows 11 VirtualBox, which works just fine if the virtual network adapter is configured in bridged mode (i.e. the virtual machine can access the network adapter directly). But if it is in NAT mode I get the exact same problem (i.e. the Windows virtual machine network has to go through the Linux host). In this case proton/wine is not involved at all and the launcher still can't reach the server.

The net.ipv4.tcp_mtu_probing=1 workaround is great though, much easier than what I was doing before (connecting through a VPN, which causes a whole bunch of new (performance) problems).

Experienced the same result when trying this before in a VM. Does Windows default to MTU probing?

[Nowa-Ammerlaan]

Experienced the same result when trying this before in a VM. Does Windows default to MTU probing?

From what I have been reading it is enabled by default on Windows since Vista. (I can't find the link to where I read that earlier though).

I wonder why 1 is not the default on Linux. I can see why 2 (always enabled) might decrease performance, but 1 (enabled only if black hole detected) should be fine right?

[kakra]

I wonder why 1 is not the default on Linux. I can see why 2 (always enabled) might decrease performance, but 1 (enabled only if black hole detected) should be fine right?

I think I only observed that after upgrading von kernel 5.15 to 6.1, so it may have been the default on previous kernel, and later, distributions are expected to set it by default. On Gentoo, there actually was such a setting in sysctl.conf - but that was back in 2016 according to my config backups. I think back in 2016, it still worked differently (it didn't do binary search probing, it just cut packet sizes in half until it worked). I wonder why Gentoo set it by default, then later removed it: That can only mean the kernel used it by default at some point which supports my claim that it worked until I upgraded from 5.15 to 6.1.

[Nowa-Ammerlaan]

I think I only observed that after upgrading von kernel 5.15 to 6.1, so it may have been the default on previous kernel, and later, distributions are expected to set it by default. On Gentoo, there actually was such a setting in sysctl.conf - but that was back in 2016 according to my config backups. I think back in 2016, it still worked differently (it didn't do binary search probing, it just cut packet sizes in half until it worked). I wonder why Gentoo set it by default, then later removed it: That can only mean the kernel used it by default at some point which supports my claim that it worked until I upgraded from 5.15 to 6.1.

I tested this yesterday on a Ubuntu machine (which hasn't upgraded to the 6.1 series yet) on a different network, with a different router (same ISP though) and got the exact same result as on my Gentoo machine which has been running the 6.1 series since the first release candidate came out (October). I needed the 6.1 series to successfully run my Intel Arc GPU.

I doubt any change in kernel or other software is the root cause, probably Ubisoft changed something on their end accidentally creating this "black hole". Either they don't know about the problem yet, or they haven't bothered to fix it because the workaround is enabled by default on Windows.

Ubuntu seems to have discussed enabling this by default, but never actually made the change [1]. I don't know if this is something we can/should enable by default in Gentoo, but maybe Valve can consider enabling it by default on Steam Deck/SteamOS?

In the end this is all working around the root of the problem and Ubuisoft should just fix their firewall.

[1] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-February/013195.html

[kakra]

Either they don't know about the problem yet, or they haven't bothered to fix it because the workaround is enabled by default on Windows.

I think they most likely don't know about the problem, Linux is not on their watchlist. And other than that, probably only Windows machines need to connect to those services, no one will notice that any Linux machine (which the internet is mostly made of) cannot connect to these service with default kernel settings.

but maybe Valve can consider enabling it by default on Steam Deck/SteamOS?

This would be great. And then fix the bugs with cloud sync and in-game cloud saves. That would be even greater. :-)

[k4ss4n]

Same problem on current PopOS with "south park - the fractured but whole", "watch dogs" and "watch dogs - legion"

https://github.com/ValveSoftware/Proton/issues/6260#issuecomment-1385209525 tested for south park and it works. (ty!)

additional note: Using different networks and this problem does not exist on one configuration(wireless + router) at one place, but on all others tested at another place not far away(LAN, wireless + router, wireless + hotspot + router). The system used is the same in all scenarios. Don't understand enough to know why.

[Akselmo]

Can confirm that sudo sysctl -w net.ipv4.tcp_mtu_probing=1 helped for me when launching WatchDogs2

First uplay game i've launched on this machine as well