[issue24156] test.test_ssl.ThreadedTests unit test failed

[Ned Deily]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com