Error connecting with Tryton client from Windows 8
Trying to connect with Tryton client from Windows 8,
I get this error: [Errno 11001] getaddrinfo failed
I disabled the firewall in Windows but I still get
the same error.
In Windows XP and Windows 7 I can connect to Tryton
server without any problem.
I realized the error is thrown when I it is put the
domain name in server (host) field. If I put the IP
number of that domain name, I can connect to the server
without problem.
Activity
>Did you try the proxy solution that has been given in the
stackoverflow question?
I did it.
There is not an unreachable proxy defined within Internet Explorer.
The error is thrown only in Windows 8. In Windows XP and Windows 7
all is OK.
The connection settings within IE in Win8 it is the same like in
WinXP and Win7.I did another tests and I realized when Tryton is running from sources,
it is possible to connect with the domain name. Seems to be the same
problem with Tryton bundled exe like with <a href="#5091 (closed)">#5091 (closed)</a>We found the same error on tryton 3.4.5, but it was not pressent on tryton 3.4.4, maybe its related to changeset b7b20b221b98 ??
Also we found the error on Windows 10, so I understand that this affects Window 8 and upwards versions.
I confirm that client on linux is working correctlyOn 2015-11-10 11:49, Sergi Almacellas Abellana wrote:
> We found the same error on tryton 3.4.5, but it was not pressent on tryton 3.4.4, maybe its related to changeset b7b20b221b98 ??
Could you bisect to the origin changeset to be sure?El 10/11/15 a les 12:40, Cédric Krier ha escrit:
> Cédric Krier<cedric.krier@b2ck.com> added the comment:
>
> On 2015-11-10 11:49, Sergi Almacellas Abellana wrote:
>> >We found the same error on tryton 3.4.5, but it was not pressent on tryton 3.4.4, maybe its related to changeset b7b20b221b98 ??
> Could you bisect to the origin changeset to be sure?
I recompiled it without the noted changeset, I'm waiting for the
confirmation that fixes (or not the problem). Will keep informed.Regarding to changeset b7b20b221b98, I modified this [1] for this one [2] and
it works correctly with Tryton bundled exe on Windows 8.
[1]
host, self._extra_headers, x509 = self.get_host_info(host)
[2]
host, self.extra_headers, x509 = self.get_host_info(host)@fabic changeing _extra_headers into extra_headers make just the extra_header being not used.
And indeed we just add the header "Connection: keep-alive", so it seems this header breaks windows8 but it is an important header for performance.
Can someone test if removing the append of 'keep-alive' in get_host_info make windows8 happy?El 16/02/16 a les 19:26, Cédric Krier ha escrit:
> Cédric Krier<cedric.krier@b2ck.com> added the comment:
>
> This is really weird because it means that Windows8 has a problem with hostname (not IP) and combination with 'keep-alive'.
> I have the feeling that we should not try to fix this broken Windows8.
So tryton is not usable with https on Windows 8 or Windows 10.
Maybe we should detect the windows version using the platform module [1]
[1] https://docs.python.org/2.7/library/platform.htmlOn 2016-02-18 14:53, Sergi Almacellas Abellana wrote:
> El 16/02/16 a les 19:26, Cédric Krier ha escrit:
> > This is really weird because it means that Windows8 has a problem with hostname (not IP) and combination with 'keep-alive'.
> > I have the feeling that we should not try to fix this broken Windows8.
>
> So tryton is not usable with https on Windows 8 or Windows 10.
Except if you use IP address apparently.
Indeed we need someone who has access to such Windows and dig to find
exactly what happens. Because the issue is correlated to two things
(hostname and keep-alive) that makes no sense.On 2016-02-25 17:54, Fabyc wrote:
> > Can someone test if removing the append of 'keep-alive' in get_host_info make windows8 happy?
>
> I removed 'keep-alive', I created the bundled exe and now I tested in a recently
> installed Windows 7 and it doesn't work. Same problem like in Windows8.
So you mean the problem doesn't depend at all of the keep-alive header.Yes. I do.
The weird thing is when Tryton is running from sources (with python installed),
it works fine.
The problem seems to be when it is executed from bundled, Windows doesn't get
the address info when it is used the domain name.
Similar problem to #5091 (closed) (works fine when it is executed from sources).On 2016-02-25 19:01, Fabyc wrote:
> > Did you test with a bundled version that you did yourself on the same machine?
>
> Yes.
>
> It works fine in both of them: Windows7 and Windows8.
How did you make your setup? Did you use:
http://git.tryton.org/?p=gtk-builder-win.git;a=summary> How did you make your setup? Did you use:
> http://git.tryton.org/?p=gtk-builder-win.git;a=summary
I did like it was in the old Tryton wiki on google. I had saved the steps
to create the setup.
- python setup.py py2exe> How did you make your setup? Did you use:
> http://git.tryton.org/?p=gtk-builder-win.git;a=summary
I did it with the steps in the guide:
http://hg.tryton.org/deprecated/tryton.wiki/file/e5cff9482830/BuildingWinInstall.wikiI did some research on this topic.
The error happens when socket.getaddrinfo() is called. The error occurs without any DNS request happening. It seems that there is a problem with the getaddrinfo implementation. So the problem lies in the python library itself.
If i build the Tryton client on a 32bit Windows 7. Then i got bitten by this issue.
If i build the Tryton client on a 64bit Windows 10. Then the issue is solved. Unfortunately such a build does no more work on Windows 7 (32bit and 64bit) :P
The build on Windows 10 is working on a Windows 8 64bit (had no 32bit windows 8 to test)
I tested this on Tryton 3.4 branch as i had to build a custom client for this version.
From my research i can say that it is really hard to debug the Tryton client on Windows. I added a new commandline arg to define a logconf file like it is used for the Tryton server as i needed to use a logfile to get some debug output. Is there any better way to get debug output on windows? Or should we add the parameter to define a logconf file?If we want to solve one day this issue, people must report tests with precise information. It is needed to know which *exact* Python version is run (and if it was compiled or using the python.org).
Also I think the first thing to do is to create a minimal python script that expose the issue. As far as I understand a simple call to socket.getaddrinfo should trigger the problem.
As far as I see, the error 11001 is "Host not found" [1].
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms740668%28v=vs.85%29.aspx#WSAHOST_NOT_FOUNDMaybe it is linked to https://bugs.python.org/#24684
I have updated the Python version on the build machine (it was 2.7.10 and now 2.7.12) which include this fix. So the release 4.0.2 will have it.
