http://bugs.winehq.org/show_bug.cgi?id=32783
Bug #: 32783
Summary: STEP7_Lite_V30_incl_SP4 Setup Failed to start the
service, Error:1053, Service request timeout.
Product: Wine
Version: 1.5.22
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: fangendoucg(a)gmail.com
Classification: Unclassified
Created attachment 43286
--> http://bugs.winehq.org/attachment.cgi?id=43286
Terminal Output
env: ubuntu12.04 & wine 1.5.22 with the patch of the bug 32764
The software can be freely downloaded from:
https://a248.e.akamai.net/cache.automation.siemens.com/dnl/DQ/DQzMjkzAAAA_3…
extract it, cd to folder STEP7_Lite_V30_incl_SP4 , then run:
$wine Setup.exe
While installing Automation License Manager V4.0 SP3, a dialog box showed like
the attachment "dialog_box_1", click *R* showed another one like the attachment
"dialog_box_2". The Chinese words in dialog_box_2 means insufficient buffer.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=48567
Bug ID: 48567
Summary: Wine returns the loopback IP as first item in
GetIpAddrTable and a MAC of 0
Product: Wine
Version: 5.0-rc3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: iphlpapi
Assignee: wine-bugs(a)winehq.org
Reporter: ez(a)vajn.icu
Distribution: ---
Created attachment 66389
--> https://bugs.winehq.org/attachment.cgi?id=66389
C source
This is the same bug as 40247 which was marked as "CLOSED FIXED"
All flexnet based licensing fails to work under wine because it receives
a hardware MAC of 0 returned by the "lo" interface:
$ lmutil.exe lmhostid
lmutil - Copyright (c) 1989-2017 Flexera Software LLC. All Rights Reserved.
The FlexNet host ID of this machine is "ffffffff"
If you compile the attached C program and run it in wine you get:
$ mingw32-gcc -DMINGW -o get_mac get_mac.c -lnetapi32
$ ./get_mac.exe
MAC: 000000000000
In Linux the eth0 MAC is:
$ gcc -o get_mac get_mac.c
$ ./get_mac
Grabbing MAC address for interface eth0
MAC: e03619b3b50e
--
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.
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.
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.
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.
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.
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.
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.
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.
https://bugs.winehq.org/show_bug.cgi?id=51666
Bug ID: 51666
Summary: HiSuite
Product: Wine
Version: 6.15
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: aykutboray(a)gmail.com
Distribution: ---
I installed Huawei Husite 11.0.0.550_OVE a few days ago and today I connected
my phone but it cannot see my phone. I did all the settings on the phone.
--
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.