wine-bugs June 2021

wine-bugs@winehq.org

1 participants
5428 discussions

[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

[Bug 51261] New: Dongle recognition issue
by WineHQ Bugzilla 11 Jun '21

11 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=51261 Bug ID: 51261 Summary: Dongle recognition issue Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: belcamara.developer(a)gmail.com Distribution: --- Created attachment 70140 --> https://bugs.winehq.org/attachment.cgi?id=70140 Error file generated I am trying to use an application Windev that require usage of USB DONGLE. I plugged the dongle and when i start the app it give me error attached file. Dongle are good, I tested on windows machine and works fine. -- 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 50974] New: Multiple applications fail to open \Device\Afd\xxx with non-empty final element (Rust applications using the Mio or Smol libraries, Starcraft Remastered)
by WineHQ Bugzilla 10 Jun '21

10 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=50974 Bug ID: 50974 Summary: Multiple applications fail to open \Device\Afd\xxx with non-empty final element (Rust applications using the Mio or Smol libraries, Starcraft Remastered) Product: Wine Version: 5.0 Hardware: x86-64 OS: Linux Status: NEW Keywords: download, patch Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)winehq.org Reporter: z.figura12(a)gmail.com Depends on: 50520 Distribution: --- Split from bugs 50520 and 50366. This is the second problem facing those applications. An example application is attached to bug 50520. This is addressed by a currently out-of-tree patch <https://repo.or.cz/wine/zf.git/commitdiff/28004107fa92dbc58ae52fc5a799af96f…>. -- 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 5

[Bug 51256] New: Encarta 2008 (German): Problem initializing the program
by WineHQ Bugzilla 10 Jun '21

10 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=51256 Bug ID: 51256 Summary: Encarta 2008 (German): Problem initializing the program Product: Wine Version: 6.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: cweiske(a)cweiske.de Distribution: --- Created attachment 70129 --> https://bugs.winehq.org/attachment.cgi?id=70129 log messages in the terminal When running the installed "Microsoft Encarta 2008: Lernen und Wissen" (German) (wine ENCARTA.EXE), an error popup is shown and setup fails: Original German: > Das Programm kann nicht gestartet werden > Unbekannter Fehler bei der Intilisierung dieses Programms. > Starten Sie Windows neu und versuchen Sie es anschließend emeut. > Führen Sie Setup von der Installations-CD noch einmal aus, wenn die Probleme nicht behoben sind. English: > The program could not be started > Unknown error during initialization of the application. > Restart Windows and try again. > Run the Setup on the installation CD again if the problems are not gone. (Installation did not work without installing the .net framework 2.0 with "winetricks dotnet20", see #51255). -- 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 51255] New: Encarta 2008 (German): .NET Framework Language Pack installation failed
by WineHQ Bugzilla 10 Jun '21

10 Jun '21

https://bugs.winehq.org/show_bug.cgi?id=51255 Bug ID: 51255 Summary: Encarta 2008 (German): .NET Framework Language Pack installation failed Product: Wine Version: 6.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: cweiske(a)cweiske.de Distribution: --- When running the setup for "Microsoft Encarta 2008: Lernen und Wissen" (German), an error is shown and setup fails: > Installation von Microsoft .NET Framework Language Pack ist fehlgeschlagen (0x0000101B). > Eventuell läuft gerade eine andere Produktinstallation. > Bitte starten Sie Setup später noch einmal, oder starten Sie Ihren Computer neu und führen Setup erneut aus, English translation: > Installation of Microsoft .NET Framework Language Pack failed (0x0000101B). > Maybe another product installation is running. > Please run setup again later, or reboot your computer and run setup again. The log: 0024:fixme:msi:MsiOpenPackageExW dwOptions 00000001 not supported 0024:fixme:file:NtLockFile I/O completion on lock not implemented yet 0024:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION 010c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1. 010c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1. 0114:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1. 0114:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1. 0114:fixme:advapi:DecryptFileA ("C:\\users\\cweiske\\Temp\\IXP000.TMP\\", 00000000): stub 011c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1. 011c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1. 011c:fixme:heap:RtlSetHeapInformation 0000000001370000 0 000000000011FD90 4 stub 011c:fixme:heap:RtlSetHeapInformation 0000000001480000 0 000000000011EBC0 4 stub 011c:fixme:security:GetWindowsAccountDomainSid (000000000011EE10 00000000012CD558 000000000011EE0C): semi-stub 011c:fixme:secur32:GetComputerObjectNameW NameFormat 7 not implemented 011c:fixme:file:NtLockFile I/O completion on lock not implemented yet -- 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

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