- Wine-Bugs - list.winehq.org

[Bug 8332] Multiple applications fail to send ICMP requests on Linux (failure to open IPPROTO_ICMP sockets)
by WineHQ Bugzilla Oct. 7, 2021

Oct. 7, 2021

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #39 from Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- (In reply to oiaohm from comment #38) > (In reply to Zebediah Figura from comment #37) > > I'm adjusting the title, since it's misleading. As far as I understand > > SOCK_DGRAM + IPPROTO_ICMP actually does sufficiently work on Linux (Damjan > > claims it is "completely broken", which seems odd seeing as `wine ping` > > works fine.) The problem is, as far as I'm aware, this is *also* forbidden > > by default on some distributions, including Debian, via the > > "net.ipv4.ping_group_range" sysctl. > > > > Should we just require that sysctl to be set for Wine? Is it reasonable to > > try to fall back to ping(1)? I don't see any other way to achieve what we > > want... > > > > The linked download no longer works on Windows (i.e. it gives the same "no > > internet detected" message; probably the service died), so I'm removing that. > > https://serverfault.com/questions/1002225/how-do-i-limit-ping-icmp-response… > on-a-debian-10-server > > There are a lot of different changeable values > > net.ipv4.ping_group_range is is straight up forbid. There is also the > problem that a icmp send or receive rate limit can be set like mentioned > above and other setting. > > https://social.msdn.microsoft.com/Forums/en-US/74fd0d8e-b75a-4aa5-bb50- > 140e606950b6/icmp-error-processing-on-udp-socket?forum=wsk > > Also I am sorry but Damjan Jovanovic is wrong in a fatal way. Windows ICMP > error handling changes with windows version and configuration as well. > --Windows doesn't seem to provide any ICMP error data anyway:-- is right and > wrong as the same time. > > Mac OS and Linux both don't match what different versions of Windows will > provide applications with at times. > > The Linux should provide enough data to reconstruct all the different wacky > ways windows can respond to applications in case of ICMP error. > > Also to be really horrible windows ICMP error response altered based on > Windows firewalls as well. These differences can be why a program works > under XP then fails under Windows 7 and newer. Or only works with Windows 7 > and newer when particular firewall settings are set. > I think you missed the point. The failure happens when either creating the socket (because no permissions), or when sending it AFAIK, not the error received, although that's also another one of the issues between implementations. Anyway, Huw has done a rewrite of icmp on top of nsi. Damjan, can you test with latest wine git and see if it's still broken? -- 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] Multiple applications fail to send ICMP requests on Linux (failure to open IPPROTO_ICMP sockets)
by WineHQ Bugzilla Oct. 7, 2021

Oct. 7, 2021

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #38 from oiaohm <oiaohm(a)gmail.com> --- (In reply to Zebediah Figura from comment #37) > I'm adjusting the title, since it's misleading. As far as I understand > SOCK_DGRAM + IPPROTO_ICMP actually does sufficiently work on Linux (Damjan > claims it is "completely broken", which seems odd seeing as `wine ping` > works fine.) The problem is, as far as I'm aware, this is *also* forbidden > by default on some distributions, including Debian, via the > "net.ipv4.ping_group_range" sysctl. > > Should we just require that sysctl to be set for Wine? Is it reasonable to > try to fall back to ping(1)? I don't see any other way to achieve what we > want... > > The linked download no longer works on Windows (i.e. it gives the same "no > internet detected" message; probably the service died), so I'm removing that. https://serverfault.com/questions/1002225/how-do-i-limit-ping-icmp-response… There are a lot of different changeable values net.ipv4.ping_group_range is is straight up forbid. There is also the problem that a icmp send or receive rate limit can be set like mentioned above and other setting. https://social.msdn.microsoft.com/Forums/en-US/74fd0d8e-b75a-4aa5-bb50-140e… Also I am sorry but Damjan Jovanovic is wrong in a fatal way. Windows ICMP error handling changes with windows version and configuration as well. --Windows doesn't seem to provide any ICMP error data anyway:-- is right and wrong as the same time. Mac OS and Linux both don't match what different versions of Windows will provide applications with at times. The Linux should provide enough data to reconstruct all the different wacky ways windows can respond to applications in case of ICMP error. Also to be really horrible windows ICMP error response altered based on Windows firewalls as well. These differences can be why a program works under XP then fails under Windows 7 and newer. Or only works with Windows 7 and newer when particular firewall settings are set. ICMP error handling I can see this needing Linux particular code. I also see that Mac OS is kind screwed because for some cases the need data to replicate what windows does Mac OS ICMP handling does not provide that information. --On error: | reply's IP | reply's ICMP-- This is not windows. With windows 7 and newer reply's IP address could be 0.0.0.0 instead of valid address with Windows 7 and newer. reply's ICMP can also be also be cleared on Windows 7 and before. Windows Xp and before you have a different set of rules. Yes the fun one that Windows can be tell you the outgoing port with ICMP instead of the port its going to at the designation as well. Yes ping group range under windows can fail due to firewall settings under windows. Reality is Linux is not completely broken. But error handling with ICMP is very platform dependant and platform configuration dependant. ICMP successful is fairly much the same everywhere. When you need to handle ICMP failure its fairly much Linux, BSD(covering OS X) and about 5 different windows implementations(for different windows setups and version) so it least works without doing something totally stupid. Yes a lot of cases with windows with ICMP failures you are horrible short of information and the information can be massively mangled. So windows would be completely broken ICMP error handling design that Microsoft has been not keeping constant between versions of windows or configurations of windows. I would say this is one of these horrible areas. I would suspect some applications are not working with wine at the moment because wine under Linux and Mac OS don't match how windows miss behaves. Yes some windows applications will refuse to install if Microsoft firewall settings and other settings are not set particular was to get particular ICMP error handling. So this is more cursed than one would wish for. -- 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] Multiple applications fail to send ICMP requests on Linux (failure to open IPPROTO_ICMP sockets)
by WineHQ Bugzilla Oct. 7, 2021

Oct. 7, 2021

https://bugs.winehq.org/show_bug.cgi?id=8332 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com Summary|Applications and games |Multiple applications fail |using ICMP ping request |to send ICMP requests on |report 'no connection to |Linux (failure to open |internet' (Wine |IPPROTO_ICMP sockets) |32-bit/64-bit preloader | |requires CAP_NET_RAW to | |create raw sockets) | URL|https://web.archive.org/web | |/20070202125803/http://baha | |i-education.org/ocean/Ocean | |_English.exe | Keywords|download | --- Comment #37 from Zebediah Figura <z.figura12(a)gmail.com> --- I'm adjusting the title, since it's misleading. As far as I understand SOCK_DGRAM + IPPROTO_ICMP actually does sufficiently work on Linux (Damjan claims it is "completely broken", which seems odd seeing as `wine ping` works fine.) The problem is, as far as I'm aware, this is *also* forbidden by default on some distributions, including Debian, via the "net.ipv4.ping_group_range" sysctl. Should we just require that sysctl to be set for Wine? Is it reasonable to try to fall back to ping(1)? I don't see any other way to achieve what we want... The linked download no longer works on Windows (i.e. it gives the same "no internet detected" message; probably the service died), so I'm removing that. -- 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 51839] New: Unable to connect to Server in WatchGuard System Manager
by WineHQ Bugzilla Oct. 5, 2021

Oct. 5, 2021

https://bugs.winehq.org/show_bug.cgi?id=51839 Bug ID: 51839 Summary: Unable to connect to Server in WatchGuard System Manager Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: caldwelldugan(a)gmail.com Distribution: --- Created attachment 70735 --> https://bugs.winehq.org/attachment.cgi?id=70735 the backtrace output when the failure window pops up Summary Backtrace is attached The program is WatchGuard System Manager (WSM). I'm able to do everything I can on Windows, except connect to WSM Server (which isn't the same as WSM, don't care about WSM Server for Wine). When I go to connect to a server it gets to step 2/3 and crashes. I've done a clean wine prefix and tried the development version but unfortunately neither worked :( Steps to reproduce: 1. Install WSM (link to executable here: https://cdn.watchguard.com/SoftwareCenter/Files/WSM/12_7_1/WSM_12_7_1.exe ) 2. Launch WSM 3. Click File > Connect to Server 4. Enter a valid management server IP address, user, and password, then click Login 5. Wait for it to fail It fails on the 3rd step. The very first time I tried this (and not on subsequent times) it failed on the second step with something having to do with certificates. If it fails on the second step then repeat all 5 steps again and it should fail on the 3rd step. Also, more about certificates, this error appears on my terminal consistently, immediately before the crash: GnuTLS error: ASN1 parser: Error in DER parsing. wine: Unhandled page fault on read access to 00000000 at address 7CCA1F10 (thread 0009), starting debugger... Note that you need a valid WSM server with valid credentials. You can install it on any Windows box with the same installer as for WSM, you just need to check the Server box. The server doesn't need to work on Linux at all, just the frontend, but unfortunately you do need a backend to connect to. Please let me know if you need a valid server and I can probably set one up for you to test with. -- 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 14

[Bug 51773] New: Crysis Warhead enemies render with glitches
by WineHQ Bugzilla Oct. 5, 2021

Oct. 5, 2021

https://bugs.winehq.org/show_bug.cgi?id=51773 Bug ID: 51773 Summary: Crysis Warhead enemies render with glitches Product: vkd3d Version: 1.2 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: vkd3d Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- Created attachment 70673 --> https://bugs.winehq.org/attachment.cgi?id=70673 example vkd3d-1.2-513-g75a1a24 -- 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 2

[Bug 20907] New: $ORIGIN is undefined on NetBSD, breaking compile
by wine-bugs＠winehq.org Oct. 5, 2021

Oct. 5, 2021

http://bugs.winehq.org/show_bug.cgi?id=20907 Summary: $ORIGIN is undefined on NetBSD, breaking compile Product: Wine Version: 1.1.33 Platform: PC URL: http://mail-index.netbsd.org/netbsd-users/2009/07/29/m sg004188.html OS/Version: NetBSD Status: UNCONFIRMED Keywords: download, source Severity: blocker Priority: P2 Component: build-env AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com When compiling on NetBSD, build fails _really_ early, with: execname not specified in AUX vector googling around, I found: http://mail-index.netbsd.org/netbsd-users/2009/07/29/msg004188.html which shows that apparently $ORIGIN is not defined on NetBSD. I'm not quite sure wine can work around it, so marking the bug as unconfirmed for now... -- 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 22

[Bug 51840] New: Cheat Engine 7.0: cheat lists not handles correctly
by WineHQ Bugzilla Oct. 5, 2021

Oct. 5, 2021

https://bugs.winehq.org/show_bug.cgi?id=51840 Bug ID: 51840 Summary: Cheat Engine 7.0: cheat lists not handles correctly Product: Wine Version: 6.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: galtgendo(a)o2.pl Distribution: --- I rarely ever use Cheat Engine, so I'm not sure whether or not it's currently working in wine. But this isn't about its core functionality (at least not yet), but about its GUI. If single addresses are found and added to the presenting widget correctly, yet many cheat lists add created cheats in a hierarchy. Things go wrong then. Toplevel items seem to be added correctly, but if you try clicking on them, they seem to expand semi-random subitems in no obvious pattern of choosing them. Some of the items are inactive (well, can't be selected), others can be selected, but it's difficult to tell which are which. As I haven't used this functionality on my own, I suspect only some of them should be selectable. I'm not sure what fails here. Cheat lists are xml files, but it could be something related to the widget or even wrong interpretation of the code. (I'm trying to be coherent, but currently failing hard...) -- 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 42875] New: gaokao.love.100 Days failed to start
by wine-bugs＠winehq.org Oct. 3, 2021

Oct. 3, 2021

https://bugs.winehq.org/show_bug.cgi?id=42875 Bug ID: 42875 Summary: gaokao.love.100 Days failed to start Product: Wine Version: 2.6 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: litimetal(a)gmail.com Distribution: --- Created attachment 57993 --> https://bugs.winehq.org/attachment.cgi?id=57993 terminal.txt gaokao.love.100 Days is a game available on steam: http://store.steampowered.com/app/347620/ 0. rm -rf ~/.wine 1. winetricks steam 2. Install gaokao.love.100 Days from steam 3. Launch it from steam 4. The screen is black, the background music plays normally $ wine --version wine-2.6-154-gcced5dfbde -- 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 11

[Bug 6851] Wizmo can't trigger screensaver
by WineHQ Bugzilla Oct. 3, 2021

Oct. 3, 2021

https://bugs.winehq.org/show_bug.cgi?id=6851 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.grc.com/files/wi |https://web.archive.org/web |zmo.exe |/20070203001858if_/http://w | |ww.grc.com:80/files/wizmo.e | |xe OS|other |Linux Hardware|Other |x86-64 Component|programs |-unknown --- Comment #17 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Still present with wine-6.18-241-ga87abdbe857. Tested with a 32bit prefix in winxp mode. I think something might be going wrong in NC_HandleSysCommand or X11DRV_SysCommand, but that's a guess. Adding stable download. $ sha1sum wizmo.exe 4620cc52e9dbaba81fbed8a3247c71f199f5b4fb wizmo.exe $ du -sh wizmo.exe 40K wizmo.exe -- 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 41300] New: BV_Ana scientific software (Brainvision) attempts to access invalid license file path
by wine-bugs＠winehq.org Oct. 3, 2021

Oct. 3, 2021

https://bugs.winehq.org/show_bug.cgi?id=41300 Bug ID: 41300 Summary: BV_Ana scientific software (Brainvision) attempts to access invalid license file path Product: Wine Version: 1.9.12 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bob.mt.wya(a)gmail.com Distribution: --- Created attachment 55627 --> https://bugs.winehq.org/attachment.cgi?id=55627 bv_ana_console_log_trunc WineHQ Forum thread: https://forum.winehq.org/viewtopic.php?f=8&t=27355&sid=4e52de6ff33e3a23b17c… bv_Ana application fails after attempting to access license key: 138501.970:0027:0028:Call KERNEL32.GetFullPathNameA(0057cfb8 ":\\brainvision\\ana20160420_anaOnly_x64\\program\\license.txt",00000104,0023f0a0,0023ee98) ret=1401966e9 It appears to decide to attempt access an absolute path without a valid drive letter specifier. The application fails to start saying it can't write to path: ":\brainvision\ana20160420_anaOnly_x64\program\license.txt" which is naturally treated by wine as relative file access - starting with directory : I've attached a: WINEDEBUG=+all console log (truncated to prior and including the above line). I can't see/ find where the application detects what system drive letter it is installed to (assuming it even bothers to)... I've developed a couple of hacky patches that sanitise all wine ANSI path accesses - simply remove a leading : (colon) character (if present). These are also attached. These patches allow the demo-licensed version of the application to launch successfully (with no overrides) and it appears to function reasonably well (tested in a 64-bit Wineprefix on Gentoo w/ wine staging git master). The patches merely demonstrate that the license path issue is ALL that is stopping this piece of software from working! They are definitely not intended for production use! -- 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