wine-bugs October 2021

wine-bugs@winehq.org

1 participants
4887 discussions

[Bug 46365] New: Proteus 8.7 SP3 - Cannot open network adapter: en0: BIOCSRTIMEOUT: Invalid argument [U2]
by wine-bugs＠winehq.org 08 Oct '21

08 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=46365 Bug ID: 46365 Summary: Proteus 8.7 SP3 - Cannot open network adapter: en0: BIOCSRTIMEOUT: Invalid argument [U2] Product: Wine Version: 4.0-rc3 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: wpcap Assignee: wine-bugs(a)winehq.org Reporter: rajhlinux(a)yahoo.com Created attachment 63098 --> https://bugs.winehq.org/attachment.cgi?id=63098 proteus simulation error without wpcap.dll override. Everything is working fine in proteus 8.7 SP3 but when running a simulation with an ENC28J60 ethernet controller on the schematic, proteus stops and gives an error: Cannot open network adapter: en0: BIOCSRTIMEOUT: Invalid argument [U2] Proteus requires WinPcap drivers for networking simulations. I attempted to use wpcap.ddl override from winecfg as native and did the simulation again and got the error: Failed to initialize WinPcap Drivers [U2] I also tried installing proteus 8.7 SP3 on crossover, playonmac and wineskin all give the same errors when running the same simulation above. I tried using proteus in both 32 and 64bit installations with same errors. After launching proteus from wine, proteus has a working internet connection because I can see the news updates from the main home page of proteus. I know the simulation works because I have installed windows 10 x64 using vmware fusion on the same computer installing the same proteus 8.7 sp3 installer which I used for wine and runs perfectly using Win10Pcap drivers. I'm sure the WincPcap drivers that comes with proteus installation which you have to manually install from the programs folder will work without Win10Pcap drivers. I have attached the error log. macOS Mojave: 10.14.2 Wine Dev 4.0 rc3 -- 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 4

[Bug 40173] New: traffic watcher complians "This program works only on Ethernet networks." on wine with wpcap
by wine-bugs＠winehq.org 08 Oct '21

08 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=40173 Bug ID: 40173 Summary: traffic watcher complians "This program works only on Ethernet networks." on wine with wpcap Product: Wine Version: 1.9.3 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wpcap Assignee: wine-bugs(a)winehq.org Reporter: zhangjianqiu_133(a)yeah.net Distribution: --- Created attachment 53674 --> https://bugs.winehq.org/attachment.cgi?id=53674 Log for wine relay trace When running traffic watcher on wine (with pcap supported), An err Msgbox pops out shows "This program works only on Ethernet networks." and when use WINEDEBUG=+relay,+wpcap,+tid wine xxx.exe it shows this, which I think is wrong 0009:trace:wpcap:wine_pcap_datalink (0x7d8c1b08) 0009:Ret wpcap.pcap_datalink() retval=00000071 ret=004078a7 The retval here seems to make no sense\ The app can be get via sourceforge: https://sourceforge.net/projects/trafficwatcher/files/ The bug above is tested with ver 2.0.1 The attachment is the result of cutting full log with cat log | grep wpcap -- 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 51768] New: Controller Random Disconnection v6.17
by WineHQ Bugzilla 08 Oct '21

08 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=51768 Bug ID: 51768 Summary: Controller Random Disconnection v6.17 Product: Wine-staging Version: 6.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: spanky_12inch(a)hotmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- With version 6.17 controller did not function. However deleting a registry key fixed the controller. ( That bug is already mentioned here ) But controller randomly disconnects now instead. Doesn't happen with version 6.16 -- 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 8332] Multiple applications fail to send ICMP requests on Linux (failure to open IPPROTO_ICMP sockets)
by WineHQ Bugzilla 07 Oct '21

07 Oct '21

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 07 Oct '21

07 Oct '21

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 07 Oct '21

07 Oct '21

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 51847] New: fixme:advapi
by WineHQ Bugzilla 06 Oct '21

06 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=51847 Bug ID: 51847 Summary: fixme:advapi Product: Wine Version: 6.0.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: advapi32 Assignee: wine-bugs(a)winehq.org Reporter: danielrosario92(a)gmail.com Distribution: --- Created attachment 70741 --> https://bugs.winehq.org/attachment.cgi?id=70741 problems not installing programs -- 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 51839] New: Unable to connect to Server in WatchGuard System Manager
by WineHQ Bugzilla 05 Oct '21

05 Oct '21

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 05 Oct '21

05 Oct '21

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 05 Oct '21

05 Oct '21

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

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 October 2021