![]() 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? Ubuntu seems to have discussed enabling this by default, but never actually made the change. 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 doubt any change in kernel or other software is the root cause, probably Ubisoft changed something on their end accidentally creating this "black hole". ![]() I needed the 6.1 series to successfully run my Intel Arc GPU. 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 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 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). On Gentoo, there actually was such a setting in nf - but that was back in 2016 according to my config backups. 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. The _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). In this case proton/wine is not involved at all and the launcher still can't reach the server. the Windows virtual machine network has to go through the Linux host). But if it is in NAT mode I get the exact same problem (i.e. the virtual machine can access the network adapter directly). 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. I don't think it is a bug in wine/proton. I don't think this registry setting does do anything for wine. 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. So maybe the IPv6 routing path at Ubisoft is a little bit awkward configured. I added the line "DisabledComponents"="32" under the path they referencedĪccording to the reddit link, this may only affect people connecting via IPv6. ![]() 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). This sysctl setting will automatically tune the connection for optimal packet size then. OTOH, there may be a bug in wine which prevents the launcher from automatically using smaller packets in the first place. Setting this sysctl setting should match that behavior. And by doing so, they rely on Windows behavior to automatically probe lower MTU if proper ICMP replies were received. Maybe they try to prevent fragmentation by intentionally blocking packets being too big, for better multiplayer latency. In this case, something may be badly configured on the Ubisoft server side. Such network problems are usually out of your scope of influence. 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. While the launcher should probably handle such situations better, I'd actually recommend this kernel setting. I trust it could work, but I'd rather not rely on solution like that
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |