[issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet

Trent Nelson added the comment: Fixed in 3.2: changeset: 78690:9c2af1f9 branch: 3.2 parent: 78686:8600ae913b63 user:Trent Nelson date:Mon Aug 20 21:22:59 2012 -0400 summary: Issue #15285: Refactor connect timeout test in test_timeout. Fixed in 3.x: changes

[issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet

Roundup Robot added the comment: New changeset 9c2af1f9 by Trent Nelson in branch '3.2': Issue #15285: Refactor connect timeout test in test_timeout. http://hg.python.org/cpython/rev/9c2af1f9 New changeset b86f3af4746c by Trent Nelson in branch 'default': Issue #15285: Refactor connect t

[issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet

Changes by Trent Nelson : -- assignee: -> trent ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet

Ned Deily added the comment: The patch looks good to me. Thanks for setting up the infrastructure to allow reproducible testing! -- stage: needs patch -> commit review ___ Python tracker _

[issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet

Trent Nelson added the comment: Proposed patch attached. -- keywords: +patch nosy: +trent Added file: http://bugs.python.org/file26890/test_timeout.patch ___ Python tracker ___ _

[issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet

Brian Brazil added the comment: There's already existing infrastructure not to run certain tests when there's no internet connection, no ipv6, no tk etc. -- ___ Python tracker _

[issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet

Nam Nguyen added the comment: Using a remote server such as python.org is a good idea when you have internet connection. When you don't, though, how will the test run? -- nosy: +Nam.Nguyen ___ Python tracker

[issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet

Brian Brazil added the comment: I don't think anything in 127/8 is going to work, all Debian/Ubuntu systems I'm aware of have all of 127/8 equivalent to 127.0.0.1. Maybe 192.0.2.0/24 per RFC 5737? A better solution might be to chose some host/port on a python.org server and set it to DROP tc

[issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet

Florent Xicluna added the comment: Something like 127.42.42.42 might be more reliable, because it does not depend on the LAN configuration, only on the local loopback settings. It is in 127.0.0.0/8 but not in 127.0.0.0/32. Tested OK here. 127.0.0.0/8 - This block is assigned for use as the In