[issue28728] test_host_resolution in test_socket fails

Xiang Zhang added the comment: New changeset d36a71637cefdddc02efd884f1b2c204f370afaa by Xiang Zhang in branch 'master': bpo-28728: clarify possible test failure due to ISP (GH-412) https://github.com/python/cpython/commit/d36a71637cefdddc02efd884f1b2c204f370afaa -- _

[issue28728] test_host_resolution in test_socket fails

Xiang Zhang added the comment: New changeset 284a2ba140cf11216e9804573d8cea6674ab90d9 by Xiang Zhang in branch '3.6': bpo-28728: clarify possible test failure due to ISP (GH-412) (GH-531) https://github.com/python/cpython/commit/284a2ba140cf11216e9804573d8cea6674ab90d9 -- ___

[issue28728] test_host_resolution in test_socket fails

Changes by Xiang Zhang : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-li

[issue28728] test_host_resolution in test_socket fails

Changes by Xiang Zhang : -- pull_requests: +440 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue28728] test_host_resolution in test_socket fails

Changes by Xiang Zhang : -- pull_requests: +343 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue28728] test_host_resolution in test_socket fails

Xiang Zhang added the comment: Ohh, sorry. > I was wondering if there was a separate way to detect the troublesome ISP > environment. How could you differentiate the failure between ISP environment caused and function behaved wrongly? Successfully resolve an invalid ip address doesn't mean y

[issue28728] test_host_resolution in test_socket fails

Martin Panter added the comment: I think the original test is trying to ensure that an invalid numeric IP address results in an OSError. So changing it to skip the test on OSError does not seem wise. Also, Silent Ghost said that the problem was with gethostbyaddr(), not gethostbyname(). I was

[issue28728] test_host_resolution in test_socket fails

Changes by Xiang Zhang : Added file: http://bugs.python.org/file45714/test_host_resolution.patch ___ Python tracker ___ ___ Python-bugs-list m

[issue28728] test_host_resolution in test_socket fails

Martin Panter added the comment: Maybe you could factor out the first part of test_bad_address() that skips the test. It would only need to be used by negative test cases (that purposefully test invalid names). I presume positive tests would not need to be wrapped. --

[issue28728] test_host_resolution in test_socket fails

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue28728] test_host_resolution in test_socket fails

Xiang Zhang added the comment: The three ipv6 addresses are all invalid addresses if we conform to spec. "::1q" non hex characteres "::1::2"two "::" but at most one is allowed "1:1:1:1:1:1:1:1:1" 144 bits > 128 bits > Perhaps this is similar to the problems encountered

[issue28728] test_host_resolution in test_socket fails

SilentGhost added the comment: I get either ('ec2-54-88-107-140.compute-1.amazonaws.com', [], ['54.88.107.140']) or ('ec2-54-84-80-173.compute-1.amazonaws.com', [], ['54.84.80.173']). It indeed seems to be related to ISP, as I get a regular socket.gaierror raised when I try this on another ma

[issue28728] test_host_resolution in test_socket fails

Martin Panter added the comment: I’m curious what the result of gethostbyaddr() is in your case, Silent Ghost. import socket socket.gethostbyaddr("::1q") socket.gethostbyaddr("::1::2") socket.gethostbyaddr("1:1:1:1:1:1:1:1:1") On my computer, I get “socket.gaierror: [Errno -2] Name or service n

[issue28728] test_host_resolution in test_socket fails

SilentGhost added the comment: > Does test_host_resolution still stably fails? Yes. -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue28728] test_host_resolution in test_socket fails

Xiang Zhang added the comment: > hosts: files mdns4_minimal [NOTFOUND=return] resolve > [!UNAVAIL=return] dns I think this is the default config. Same as mine. Does test_host_resolution still stably fails? -- ___ Python tracker

[issue28728] test_host_resolution in test_socket fails

SilentGhost added the comment: > My guess is you have a plugin which is resolving these ip-address lookalikes. That probably is the reason. My hosts line looks like: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns I guess there isn't much that could be done

[issue28728] test_host_resolution in test_socket fails

Martin Panter added the comment: Maybe worth looking at what name resolution stuff is enabled in /etc/nsswitch.conf. On the hosts line, my current computer (v basic setup) has hosts: files dns myhostname My guess is you have a plugin which is resolving these ip-address lookalikes. --

[issue28728] test_host_resolution in test_socket fails

Xiang Zhang added the comment: Hi SilentGhost. I'm also using Ubuntu 16.10 but the test case doesn't fail. cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.10 DISTRIB_CODENAME=yakkety DISTRIB_DESCRIPTION="Ubuntu 16.10" ./python -Wa -m test -v test_socket | grep test_host_resolution te

[issue28728] test_host_resolution in test_socket fails

SilentGhost added the comment: Of course, you're right, that was my mistake. The last three addresses fail to raise, namely: '::1q', '::1::2' and '1:1:1:1:1:1:1:1:1'. -- stage: patch review -> title: test_host_resolution in test_socket fails on duplicate assert -> test_host_resolution

[issue28728] test_host_resolution in test_socket fails on duplicate assert

Changes by SilentGhost : Removed file: http://bugs.python.org/file45524/test_socket.diff ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue28728] test_host_resolution in test_socket fails on duplicate assert

R. David Murray added the comment: It might be interesting to stick a 'with subtest' in there and see which address is failing to raise. -- nosy: +r.david.murray ___ Python tracker

[issue28728] test_host_resolution in test_socket fails on duplicate assert

Martin Panter added the comment: That’s not exactly a duplicate; one is host-by-NAME, the other host-by-ADDR -- nosy: +martin.panter ___ Python tracker ___ __

[issue28728] test_host_resolution in test_socket fails on duplicate assert

New submission from SilentGhost: Commit 540a9c69c2ea introduced double assertRaises which now is failing on ubuntu 16.10 If it is necessary, then it's not obvious why and there is no comment, but here is the one-line patch that removes the duplicated line and makes the test pass for me.