wine-bugs June 2021

wine-bugs@winehq.org

1 participants
5215 discussions

[Bug 51270] New: Asus Armoury Crate crashes when opening it with Wine.
by WineHQ Bugzilla 14 Jun '21

14 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=51270 Bug ID: 51270 Summary: Asus Armoury Crate crashes when opening it with Wine. Product: Wine Version: 6.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: 4lon3ly0(a)protonmail.com Distribution: --- Created attachment 70149 --> https://bugs.winehq.org/attachment.cgi?id=70149 Asus Armoury Crate Backtrace When I open the Asus Armoury Crate 3.0.11.0 under Wine 6.9, it crashes saying that the program had encountered a serious problem and that it needed to close. Sha1sum: fd6a0db01793eee7ff081e3afbd0f00133e213d4 Download: https://dlcdnets.asus.com/pub/ASUS/mb/14Utilities/ArmouryCrateInstallTool.z… Sysinfo: X64 Artix Linux Linux 5.12.7-hardened -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by WineHQ Bugzilla 14 Jun '21

14 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #35 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- (In reply to Gabriel Ivăncescu from comment #34) > Yeah, speaking of that, I had some patches to implement the asynchronous > ICMP pings with Events and APCs, but they fell off the list. I should > probably resend them, thanks for the reminder. Great :). > Do you plan to work on fixing this? It shouldn't conflict with my async > patches much anyway, worst case a simple rebase would be sufficient. I could > probably take a look if you can't, but you seem to know a lot more about it > than I do, so am just asking to not duplicate the effort. Sure. Some of the code is already written. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by WineHQ Bugzilla 14 Jun '21

14 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #34 from Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- (In reply to Damjan Jovanovic from comment #33) > (In reply to Gabriel Ivăncescu from comment #32) > > I don't remember the exact details, there was a game pinging multiple time > > every 5 seconds and it had a nasty stutter when that happened with the > > wine-staging patch, since it invoked external commands and was very slow. > > That's not good. If the game stuttered merely because of the latency of a > fork(), when we fix this and it waits for a network round-trip instead, it > will be much worse. Are you sure there isn't another problem, eg. game wants > asynchronous ping but we do it synchronously? > Yeah, speaking of that, I had some patches to implement the asynchronous ICMP pings with Events and APCs, but they fell off the list. I should probably resend them, thanks for the reminder. > > I'm not that familiar with it, so I admit I haven't tested it at all other > > than creating the raw socket itself, but it did fix the slowdown; now that > > you mention it, though, it probably failed to ping. > > Ok thank you. Do you plan to work on fixing this? It shouldn't conflict with my async patches much anyway, worst case a simple rebase would be sufficient. I could probably take a look if you can't, but you seem to know a lot more about it than I do, so am just asking to not duplicate the effort. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by WineHQ Bugzilla 14 Jun '21

14 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #33 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- (In reply to Gabriel Ivăncescu from comment #32) > I don't remember the exact details, there was a game pinging multiple time > every 5 seconds and it had a nasty stutter when that happened with the > wine-staging patch, since it invoked external commands and was very slow. That's not good. If the game stuttered merely because of the latency of a fork(), when we fix this and it waits for a network round-trip instead, it will be much worse. Are you sure there isn't another problem, eg. game wants asynchronous ping but we do it synchronously? > I'm not that familiar with it, so I admit I haven't tested it at all other > than creating the raw socket itself, but it did fix the slowdown; now that > you mention it, though, it probably failed to ping. Ok thank you. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 51269] New: no se ejecuta
by WineHQ Bugzilla 14 Jun '21

14 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=51269 Bug ID: 51269 Summary: no se ejecuta Product: WineHQ Apps Database Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: appdb-unknown Assignee: wine-bugs(a)winehq.org Reporter: facundocarlosvillanueva(a)gmail.com Distribution: --- Created attachment 70147 --> https://bugs.winehq.org/attachment.cgi?id=70147 este es el error(perdon si me equivoque de categoria es q asi me dijo el error no se ejecuta el programa -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 42945] New: FFXIV Loop opening
by wine-bugs＠winehq.org 14 Jun '21

14 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=42945 Bug ID: 42945 Summary: FFXIV Loop opening Product: Wine Version: 2.7 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ssbkm(a)icloud.com Distribution: --- FFXIV gets stuck in a loop for opening movie requires work around by entering config and disabling the movie to play game at all. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 5

[Bug 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by WineHQ Bugzilla 14 Jun '21

14 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #32 from Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- (In reply to Damjan Jovanovic from comment #31) > Falling back to calling the "ping" command line tool shouldn't ever be > necessary on MacOS and Linux. > > When creating a raw socket fails, Wine tries to fall back to using an > unprivileged ICMP socket, which is a non-standard socket type present on > MacOS and Linux: > > ---snip--- > int sid=socket(AF_INET,SOCK_RAW,IPPROTO_ICMP); > if (sid < 0) > { > /* Some systems (e.g. Linux 3.0+ and Mac OS X) support > non-privileged ICMP via SOCK_DGRAM type. */ > sid=socket(AF_INET,SOCK_DGRAM,IPPROTO_ICMP); > } > ---snip--- > > Documentation: > Linux: https://lwn.net/Articles/420800/ > MacOS: http://www.manpagez.com/man/4/icmp/ > > > On MacOS, I think that work fine. > > Linux however is currently completely broken, and pinging always fail, > because: > > 1. This socket type does not return the IP header as expected from the > recvfrom() system call in the icmp_get_reply() function, causing the reply > to be parsed incorrectly in that function. On Linux, the reply immediately > begins with the ICMP header instead. > > 2. Even when that is somewhat fixed (it's long and painful to fix fully), it > still breaks, because Linux overwrites the ICMP header field "icmp_id" with > its own value, ie. this value is later overwritten by the kernel: > > ---snip--- > icmp_header->icmp_id=id; > ---snip--- > > causing this check in icmp_get_reply() to always fail: > > ---snip--- > if ((icmp_header->icmp_id==id) && > (icmp_header->icmp_seq==seq)) > ---snip--- > > and the reply thus falsely never matches the request, so pinging still fails. > > The "icmp_id" is overwritten by the socket's port number, which can be set > through bind(). It cannot be queried by getsockname() which always returns > port 0, even after bind(). However it seems best not to set it, let the > kernel pick a free port, and then skip the icmp_id check above instead, as > the kernel already filters replies by their icmp_id. > > Fixing (2) is easy, but (1) really needs to use recvmsg() instead, with > IP_RECVTTL, IP_RECVTOS, IP_RETOPTS, IP_RECVERR and other ancillary data, > only on Linux and only for these unprivileged ICMP sockets. Then this > alternative source of IP header data needs to be integrated into > icmp_get_reply(). > > I don't know how Gabriel ever said that this works on Linux. Either he never > tested, only tested pinging an invalid address, or Linux changed how > unprivileged ICMP sockets work between then and now: > > ---snip--- > commit e6d9aaeb67172dd0ba1e73f34c7f0cad36ed43ff > Author: Gabriel Iv��ncescu <gabrielopcode(a)gmail.com> > Date: Mon Aug 3 16:15:52 2020 +0300 > > iphlpapi: Update comment for SOCK_DGRAM since Linux also supports it > from 3.0. > > Linux does require the user to be in the range specified by > /proc/sys/net/ipv4/ping_group_range though, but otherwise works fine. > > Signed-off-by: Gabriel Iv��ncescu <gabrielopcode(a)gmail.com> > Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> > ---snip--- I don't remember the exact details, there was a game pinging multiple time every 5 seconds and it had a nasty stutter when that happened with the wine-staging patch, since it invoked external commands and was very slow. I'm not that familiar with it, so I admit I haven't tested it at all other than creating the raw socket itself, but it did fix the slowdown; now that you mention it, though, it probably failed to ping. Note that the commit you referenced doesn't actually do anything, it just changes a comment, which is true, because Linux does allow creating raw sockets with the aforementioned requirements specified. So the code was already broken. The "broken" functionality you mention was already there. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by WineHQ Bugzilla 13 Jun '21

13 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=8332 Damjan Jovanovic <damjan.jov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov(a)gmail.com, | |gabrielopcode(a)gmail.com --- Comment #31 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- Falling back to calling the "ping" command line tool shouldn't ever be necessary on MacOS and Linux. When creating a raw socket fails, Wine tries to fall back to using an unprivileged ICMP socket, which is a non-standard socket type present on MacOS and Linux: ---snip--- int sid=socket(AF_INET,SOCK_RAW,IPPROTO_ICMP); if (sid < 0) { /* Some systems (e.g. Linux 3.0+ and Mac OS X) support non-privileged ICMP via SOCK_DGRAM type. */ sid=socket(AF_INET,SOCK_DGRAM,IPPROTO_ICMP); } ---snip--- Documentation: Linux: https://lwn.net/Articles/420800/ MacOS: http://www.manpagez.com/man/4/icmp/ On MacOS, I think that work fine. Linux however is currently completely broken, and pinging always fail, because: 1. This socket type does not return the IP header as expected from the recvfrom() system call in the icmp_get_reply() function, causing the reply to be parsed incorrectly in that function. On Linux, the reply immediately begins with the ICMP header instead. 2. Even when that is somewhat fixed (it's long and painful to fix fully), it still breaks, because Linux overwrites the ICMP header field "icmp_id" with its own value, ie. this value is later overwritten by the kernel: ---snip--- icmp_header->icmp_id=id; ---snip--- causing this check in icmp_get_reply() to always fail: ---snip--- if ((icmp_header->icmp_id==id) && (icmp_header->icmp_seq==seq)) ---snip--- and the reply thus falsely never matches the request, so pinging still fails. The "icmp_id" is overwritten by the socket's port number, which can be set through bind(). It cannot be queried by getsockname() which always returns port 0, even after bind(). However it seems best not to set it, let the kernel pick a free port, and then skip the icmp_id check above instead, as the kernel already filters replies by their icmp_id. Fixing (2) is easy, but (1) really needs to use recvmsg() instead, with IP_RECVTTL, IP_RECVTOS, IP_RETOPTS, IP_RECVERR and other ancillary data, only on Linux and only for these unprivileged ICMP sockets. Then this alternative source of IP header data needs to be integrated into icmp_get_reply(). I don't know how Gabriel ever said that this works on Linux. Either he never tested, only tested pinging an invalid address, or Linux changed how unprivileged ICMP sockets work between then and now: ---snip--- commit e6d9aaeb67172dd0ba1e73f34c7f0cad36ed43ff Author: Gabriel Iv��ncescu <gabrielopcode(a)gmail.com> Date: Mon Aug 3 16:15:52 2020 +0300 iphlpapi: Update comment for SOCK_DGRAM since Linux also supports it from 3.0. Linux does require the user to be in the range specified by /proc/sys/net/ipv4/ping_group_range though, but otherwise works fine. Signed-off-by: Gabriel Iv��ncescu <gabrielopcode(a)gmail.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> ---snip--- -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 49736] New: TERA (Gameforge version): stuck at loading splash screen after 64 bit update
by WineHQ Bugzilla 13 Jun '21

13 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=49736 Bug ID: 49736 Summary: TERA (Gameforge version): stuck at loading splash screen after 64 bit update Product: Wine Version: 5.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sickam(a)mail.ru Distribution: --- Created attachment 68033 --> https://bugs.winehq.org/attachment.cgi?id=68033 Console output After the last update, which added 64 bit support, I can't start TERA anymore. When I try to do so, it gets stuck in the loading splash screen and I have to kill the process. Link to the changelog: https://gameforge.com/en-GB/play/tera/news/ee5ee05a-7835-4e02-b69d-24e7be5e… Launcher: https://gameforge.com/en-US/download What I did so far: - Created a fresh 64 bit prefix - Installed the Gameforge launcher and TERA Console output is in the attachment. Thanks for helping! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 30439] New: Lexware Update Manager unable to connect
by wine-bugs＠winehq.org 13 Jun '21

13 Jun '21

http://bugs.winehq.org/show_bug.cgi?id=30439 Bug #: 30439 Summary: Lexware Update Manager unable to connect Product: Wine Version: 1.5.2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: rpc AssignedTo: wine-bugs(a)winehq.org ReportedBy: onny(a)project-insanity.org Classification: Unclassified Created attachment 39801 --> http://bugs.winehq.org/attachment.cgi?id=39801 terminal output LxUpdateManager.exe After successful installation of Lexware buchhalter 2012, I removed all ie6 dll overwrites, installed Mono 2.10 via winetricks and started the program LxUpdateManager.exe. After clicking on "Jetzt suchen..." ("Search now... [for updates]"), a message appears, saying that the program is unable to reach the server and that could be due to wrong proxy settings etc. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 14

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs June 2021