[issue24156] test.test_ssl.ThreadedTests unit test failed
Ned Deily added the comment: Thanks for the additional info. I don't know what possible configuration options might affect this other than that I would expect to see 127.0.0.1 as the primary IPv4 address on the loopback interface, like: # ifconfig [...] loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 [...] Since this does seem to be unique to your configuration, I'm going to close this issue for now. If you do discover the root cause and it appears to be something that might be seen by other users and, thus, should be handled in the test suite, please re-open. -- resolution: - works for me stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24156] test.test_ssl.ThreadedTests unit test failed
Roman Rader added the comment: You're right, it does not reproduces on any machine. I'm using Arch Linux, still trying to figure out the repro steps. My hosts file doesn't contain such entries for localhost, it's pretty standard. If I disable my external network interface, it retrieves my second IP from virtual interface. And only when I disable all interfaces, I can get 127.0.0.1 on source in IP packet. The problem is, even if I enforce client to bind to 127.0.0.1, it substitutes as well (see https://gist.github.com/rrader/3e575cde56827b1f74a1). strace is clean, Python calls all kernel functions with 127.0.0.1 IP. So, I suppose, the problem not in the Python code itself, but somewhere deeper (however it can be lack of some flags?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24156] test.test_ssl.ThreadedTests unit test failed
Ned Deily added the comment: There are places in the test suite that assume 127.0.0.1 is the standard loopback address and will fail if the system under test doesn't follow that convention; see, for example, the discussion in Issue22753. I suspect that, in your case, the system's host configuration (/etc/hosts, DNS configuration, or similar) is such that the loopback address (127.0.0.1) is round-tripped as the actual address (192.168.1.103) of the interface. What platform are you running this on? Can you check what the addresses association with localhost and the names associated with the two IP addresses? For example, on many POSIX-y platforms, the following might work: dig localhost dig -x 127.0.0.1 dig -x 192.168.1.103 ifconfig -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24156] test.test_ssl.ThreadedTests unit test failed
New submission from Roman Rader:
==
FAIL: test_server_accept (test.test_ssl.ThreadedTests)
--
Traceback (most recent call last):
File /home/roma/Documents/MY/cpython/Lib/test/test_ssl.py, line 2904, in
test_server_accept
self.assertEqual(peer, client_addr)
AssertionError: Tuples differ: ('192.168.1.103', 43446) != ('127.0.0.1', 43446)
--
components: +Tests
title: unit test - test.test_ssl.ThreadedTests unit test failed
versions: +Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24156
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
