Ned Deily <n...@acm.org> added the comment:
Actually this is a real test case error. The problem is observed when the
system under test is connected to subnet "10.0.x.x". The requested address
(10.0.0.0) is then a broadcast address for the subnet. On OS X and (I believe)
BSD networking systems, the connect system call checks for this (see man 3
connect) and is documented to fail with:
[EACCES] The destination address is a broadcast address and the
socket option SO_BROADCAST is not set.
When running on a testing Debian Linux 3.2.0 kernel in a VM, the same connect
fails with: Errno 113] No route to host, which results in the test being
skipped with:
Resource '10.0.0.0' is not available
The test could be changed to pick a (hopefully unused) non-broadcast address or
support.transient_internet could add EACCES to its default_errnos, possibly
just for BSD/OSX platforms.
----------
assignee: ronaldoussoren ->
components: +Tests -Macintosh
nosy: +pitrou -ronaldoussoren
resolution: works for me ->
stage: -> needs patch
status: closed -> open
title: test_timeout failure on OSX -> test_timeout failure when system on IPv4
10.0.x.x subnet
versions: +Python 2.7, Python 3.2
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
