June 2021 - Wine-bugs - list.winehq.org

[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 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

[Bug 51265] New: valgrind shows an uninitialized read in is_wow64_thread()
by WineHQ Bugzilla 12 Jun '21

12 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=51265 Bug ID: 51265 Summary: valgrind shows an uninitialized read in is_wow64_thread() Product: Wine Version: 6.9 Hardware: x86-64 OS: Linux Status: NEW Keywords: valgrind Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)winehq.org Reporter: z.figura12(a)gmail.com Distribution: --- ==875840== Conditional jump or move depends on uninitialised value(s) ==875840== at 0x1493A6: is_wow64_thread (registry.c:2074) ==875840== by 0x1493A6: req_create_key (???:0) ==875840== by 0x14AAC2: call_req_handler (request.c:312) ==875840== by 0x14B9E7: read_request (request.c:367) ==875840== by 0x15350F: thread_poll_event (thread.c:383) ==875840== by 0x128D45: fd_poll_event (fd.c:525) ==875840== by 0x128D45: main_loop_epoll (???:0) ==875840== by 0x128FAD: main_loop (fd.c:985) ==875840== by 0x11AA61: main (main.c:149) The problem is that a process that's starting up makes a couple of create_key/open_key calls before it maps the main image. This can be trivially fixed by initializing the "machine" field. None of the keys we open are actually sensitive to architecture (well, one is, but we use the WOW64_64KEY flag on it). Still, it strikes me as a little fragile. Can we determine the architecture any earlier? -- 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 51193] New: BrickLink Stud.io: graphics corruption
by WineHQ Bugzilla 12 Jun '21

12 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=51193 Bug ID: 51193 Summary: BrickLink Stud.io: graphics corruption 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: sfrijters(a)gmail.com Distribution: --- Created attachment 70067 --> https://bugs.winehq.org/attachment.cgi?id=70067 Concatenated logs from 6.8 and 6.9 Regression from wine-6.8 (Staging) -> wine-6.9 (Staging). Using BrickLink Stud.io 2.2.5_1 from https://www.bricklink.com/v3/studio/download.page -> https://s3.amazonaws.com/blstudio/Studio2.0/Archive/2.2.5_1/Studio+2.0.exe, renamed so I can keep track of my different versions: $ sha256sum Studio+2.2.5_1.exe c5e77dca39df20a3cb77fe771ec0c69c736c8dfe5ee56b8780994eef7f140083 Studio+2.2.5_1.exe) At startup the graphics are immediately all over the place in wine-staging 6.9, while this didn't happen in 6.8. I've diffed the logs when starting from the command line and I don't see any (to my eye) significant differences, but I've attached them for reference. system: `"x86_64-linux"` host os: `Linux 5.11.21, NixOS, 21.11.20210527.5658fad (Porcupine)` -- 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