msg71283 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2008-08-17 16:53 |
I get failures in test_uuid when run inside a qemu virtual machine. It
is related to the fake MAC address used by qemu.
======================================================================
FAIL: test_ipconfig_getnode (__main__.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib\test\test_uuid.py", line 326, in test_ipconfig_getnode
self.check_node(node, 'ipconfig')
File "Lib\test\test_uuid.py", line 288, in check_node
self.assertEqual(universal_local_bit, 0, message)
AssertionError: 525400123456 doesn't look like a real MAC address
======================================================================
FAIL: test_windll_getnode (__main__.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib\test\test_uuid.py", line 351, in test_windll_getnode
self.check_node(uuid._windll_getnode(), 'windll')
File "Lib\test\test_uuid.py", line 288, in check_node
self.assertEqual(universal_local_bit, 0, message)
AssertionError: 525400123456 doesn't look like a real MAC address
----------------------------------------------------------------------
|
msg87937 - (view) |
Author: Daniel Diniz (ajaksu2) * |
Date: 2009-05-16 21:39 |
Hmm, is this a bug in uuid._ifconfig_getnode or just a bad test assumption?
|
msg87941 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2009-05-16 22:16 |
Apparently, a bad test assumption.
|
msg102601 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-04-08 08:00 |
Confirmed on Windows 7 under qemu with a fresh trunk checkout.
|
msg102608 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-04-08 09:48 |
According to http://standards.ieee.org/regauth/groupmac/tutorial.html ,
the assertions in check_node are weeding out perfectly valid addresses:
>>> node = 0x525400123456
>>> universal_local_bit = (node >> 40L) & 2
>>> universal_local_bit
2L
This just means that the address is locally administered, but valid.
Similarly, shouldn't an individual_group_bit of 1 should just mean multicast mode?
See also: Issue 7650
|
msg102626 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-04-08 16:26 |
The new patch test_uuid.patch fixes issue 7650, issue 1481 and this one.
I've applied it to py3k-cdecimal in r79905 and test_uuid is passed
on all buildbots (I did not test on ARM and one FreeBSD bot is still hanging in test_subprocess).
Additionally, the patch works on Windows-qemu (this issue) and OpenBSD-qemu.
Changes:
1. check_node accepts addresses with universal_local_bit set to 1.
These addresses are valid (like the qemu one).
2. check_node accepts addresses with the multicast bit set to 1.
These addresses are used for valid random addresses per the RFC
and uuid.getnode() itself actually may return such a random address.
3. On some platforms, _uuid_generate_time can't be set, so
_unixdll_getnode fails with a TypeError. This exception
is now caught.
4. With these changes, there appear to be no more failures, so
all tests are enabled again.
Could this go into trunk, since the tests actually fail needlessly
on qemu setups?
|
msg102632 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-04-08 17:26 |
Ok, I trust you on the investigation.
> Could this go into trunk, since the tests actually fail needlessly
> on qemu setups?
Yes, but after the beta:
http://mail.python.org/pipermail/python-dev/2010-April/099132.html
|
msg102712 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-04-09 12:20 |
5. uuid.getnode() can fall back to creating a random 48 bit number and
so can _windll_getnode() (by using UuidCreateSequential). Therefore,
in unlucky cases 0xffffffffffff can be generated and the assert in
check_node() will fail.
check_node() is beginning to look quite pointless...
|
msg102718 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-04-09 12:59 |
I do not understand the semantics of uuid.getnode(). Per the docs
it's supposed to return a hardware address. This would reasonably
make it a UUID version 1.
But then the random fallback should be a 47 bit number as per
http://www.ietf.org/rfc/rfc4122.txt section 4.5.
The docs for UuidCreateSequential don't say if the random fallback
is a random version 1 UUID.
|
msg102727 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-04-09 15:38 |
I reread http://www.ietf.org/rfc/rfc4122.txt and I'm pretty sure that
if getnode() is supposed to return a hardware address, one of the
following should be used:
1) If ifconfig etc. returns successfully, we are fine.
2) If uuid_generate_time() or UuidCreateSequential() are used
to extract the node ID, we have to make sure that the returned
UUID is in fact RFC_4122 and version 1.
3) The fallback node ID should be 47 bits according to section 4.5.
I've got a new patch (getnode.patch) that takes care of these issues.
|
msg102763 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-04-10 09:32 |
Sorry, the random node id generation in uuid.py is correct. The least
significant bit of the first octet (which is set to 1) is the first
one transmitted on the network, then the "low 47 random bits" follow.
I assumed that the least significant bit of the first octet was part
of the low 47 bits.
Patch test_uuid3 addresses points 1-5 and is almost the same as
test_uuid.patch, so I reset the resolution to 'accepted'.
As I said, there isn't much left that check_node() can check. One
could possibly check that a MAC address retrieved by ifconfig does
not have the multicast bit set, but what if a user has set the
hardware MAC to a strange value? Correctly retrieving that value
can't be regarded as a failure of uuid.py.
Should the patch go into the maintenance branches as well (after the
beta is out)?
|
msg102775 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-04-10 12:48 |
> Should the patch go into the maintenance branches as well (after the
> beta is out)?
Yes, I think it would be nice (though not mandatory).
|
msg102929 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-04-12 09:19 |
Applied test_uuid3.patch to trunk (r79954), release26-maint (r79959),
py3k (r79960) and release31-maint (r79961).
No buildbot failures so far, so I'm closing this.
|
msg141143 - (view) |
Author: Karl Johan Kleist (kleist) |
Date: 2011-07-26 11:24 |
If it could be of interest to anybody:
When running "make test" after building Python 2.7.2, I get the error message "1 test failed: test_uuid".
> uname -a
Linux h1488277 2.6.18-028stab091.2 #1 SMP Fri Jun 3 00:02:40 MSD 2011 i686 athlon i386 GNU/Linux
This is a "virtual root server" (http://www.strato.de/server/virtual-linux-server/) which I believe is using "Parallels Virtuozzo Containers" (http://www.parallels.com/products/pvcl/).
|
msg141144 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2011-07-26 11:32 |
What is the output of this command?
./python -m test.regrtest -v test_uuid
|
msg141146 - (view) |
Author: Karl Johan Kleist (kleist) |
Date: 2011-07-26 11:39 |
== CPython 2.7.2 (default, Jul 26 2011, 12:29:47) [GCC 4.2.1 (SUSE Linux)]
== Linux-2.6.18-028stab091.2-i686-athlon-with-SuSE-10.3-i586 little-endian
== /home/kjk/local/src/Python-2.7.2/build/test_python_18037
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0)
test_uuid
testIssue8621 (test.test_uuid.TestUUID) ... ok
test_UUID (test.test_uuid.TestUUID) ... ok
test_exceptions (test.test_uuid.TestUUID) ... ok
test_getnode (test.test_uuid.TestUUID) ... ok
test_ifconfig_getnode (test.test_uuid.TestUUID) ... ERROR
test_ipconfig_getnode (test.test_uuid.TestUUID) ... ok
test_netbios_getnode (test.test_uuid.TestUUID) ... ok
test_random_getnode (test.test_uuid.TestUUID) ... ok
test_unixdll_getnode (test.test_uuid.TestUUID) ... ok
test_uuid1 (test.test_uuid.TestUUID) ... ok
test_uuid3 (test.test_uuid.TestUUID) ... ok
test_uuid4 (test.test_uuid.TestUUID) ... ok
test_uuid5 (test.test_uuid.TestUUID) ... ok
test_windll_getnode (test.test_uuid.TestUUID) ... ok
======================================================================
ERROR: test_ifconfig_getnode (test.test_uuid.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/kjk/local/src/Python-2.7.2/Lib/test/test_uuid.py", line 306, in test_ifconfig_getnode
node = uuid._ifconfig_getnode()
File "/home/kjk/local/src/Python-2.7.2/Lib/uuid.py", line 321, in _ifconfig_getnode
mac = _find_mac('ifconfig', args, ['hwaddr', 'ether'], lambda i: i+1)
File "/home/kjk/local/src/Python-2.7.2/Lib/uuid.py", line 311, in _find_mac
words[get_index(i)].replace(':', ''), 16)
ValueError: invalid literal for int() with base 16: '00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00'
----------------------------------------------------------------------
Ran 14 tests in 0.315s
FAILED (errors=1)
test test_uuid failed -- Traceback (most recent call last):
File "/home/kjk/local/src/Python-2.7.2/Lib/test/test_uuid.py", line 306, in test_ifconfig_getnode
node = uuid._ifconfig_getnode()
File "/home/kjk/local/src/Python-2.7.2/Lib/uuid.py", line 321, in _ifconfig_getnode
mac = _find_mac('ifconfig', args, ['hwaddr', 'ether'], lambda i: i+1)
File "/home/kjk/local/src/Python-2.7.2/Lib/uuid.py", line 311, in _find_mac
words[get_index(i)].replace(':', ''), 16)
ValueError: invalid literal for int() with base 16: '00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00'
1 test failed:
test_uuid
|
msg141147 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2011-07-26 11:51 |
hum, maybe an issue with the MAC address of your virtual server? What do you get if you run:
ifconfig -a | grep -i -e hwaddr -e ether
|
msg141148 - (view) |
Author: Karl Johan Kleist (kleist) |
Date: 2011-07-26 11:55 |
> /sbin/ifconfig -a | grep -i -e hwaddr -e ether
venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
|
msg141150 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2011-07-26 12:17 |
Well, without a valid MAC address the function cannot work...
On the other hand, I would not worry too much: uuid._ifconfig_getnode() is an internal function; and since all the other tests pass, uuid.getnode() probably has other ways to get a unique identifier for the machine.
And by the way, in python 3.2, the test function is skipped with this message:
"""WARNING: uuid._ifconfig_getnode is unreliable on many platforms.
It is disabled until the code and/or test can be fixed properly."""
|
msg156668 - (view) |
Author: (devurandom) |
Date: 2012-03-23 16:22 |
> Well, without a valid MAC address the function cannot work...
It should not break in such ugly way either, imo.
> On the other hand, I would not worry too much:
> uuid._ifconfig_getnode() is an internal function; and since all the
> other tests pass, uuid.getnode() probably has other ways to get a
> unique identifier for the machine.
Here test_uuid fails due to this issue. Which in turn prevents my python3 rpm from being build.
> And by the way, in python 3.2, the test function is skipped with this
> message:
> """WARNING: uuid._ifconfig_getnode is unreliable on many platforms.
> It is disabled until the code and/or test can be fixed properly."""
That does not seem to be true anymore in Python 3.2.2.
Would be nice if you could detect the all-zero case and just skip the test in that case.
|
|
Date |
User |
Action |
Args |
2022-04-11 14:56:37 | admin | set | github: 47831 |
2012-03-23 16:22:05 | devurandom | set | nosy:
+ devurandom messages:
+ msg156668
|
2011-07-26 12:17:01 | amaury.forgeotdarc | set | messages:
+ msg141150 |
2011-07-26 11:55:17 | kleist | set | messages:
+ msg141148 |
2011-07-26 11:51:30 | amaury.forgeotdarc | set | messages:
+ msg141147 |
2011-07-26 11:39:35 | kleist | set | messages:
+ msg141146 |
2011-07-26 11:32:41 | amaury.forgeotdarc | set | nosy:
+ amaury.forgeotdarc messages:
+ msg141144
|
2011-07-26 11:24:32 | kleist | set | nosy:
+ kleist messages:
+ msg141143
|
2010-04-12 09:22:36 | skrah | link | issue7650 dependencies |
2010-04-12 09:22:36 | skrah | link | issue7650 superseder |
2010-04-12 09:19:12 | skrah | set | status: open -> closed
stage: commit review -> resolved messages:
+ msg102929 versions:
+ Python 3.1, Python 3.2 |
2010-04-10 12:48:32 | pitrou | set | messages:
+ msg102775 |
2010-04-10 09:32:59 | skrah | set | resolution: accepted |
2010-04-10 09:32:47 | skrah | set | keywords:
+ patch, - needs review files:
+ test_uuid3.patch messages:
+ msg102763
|
2010-04-09 15:38:04 | skrah | set | keywords:
- patch files:
+ getnode.patch resolution: accepted -> (no value) messages:
+ msg102727
|
2010-04-09 13:08:47 | pitrou | set | nosy:
+ tim.peters, nnorwitz
|
2010-04-09 12:59:57 | skrah | set | messages:
+ msg102718 |
2010-04-09 12:20:59 | skrah | set | files:
+ test_uuid2.patch
messages:
+ msg102712 |
2010-04-08 17:26:04 | pitrou | set | assignee: skrah resolution: accepted messages:
+ msg102632 stage: commit review |
2010-04-08 16:26:25 | skrah | set | files:
+ test_uuid.patch
messages:
+ msg102626 |
2010-04-08 09:48:06 | skrah | set | keywords:
+ needs review, patch files:
+ uuid_mac.patch messages:
+ msg102608
|
2010-04-08 08:00:54 | skrah | set | priority: low -> high versions:
+ Python 2.7 nosy:
+ skrah
messages:
+ msg102601
|
2010-03-17 17:33:46 | pitrou | set | assignee: pitrou -> (no value) |
2009-05-16 22:16:21 | pitrou | set | messages:
+ msg87941 |
2009-05-16 21:39:05 | ajaksu2 | set | priority: normal -> low nosy:
+ ajaksu2 messages:
+ msg87937
|
2008-08-17 16:53:40 | pitrou | set | priority: normal assignee: pitrou type: behavior components:
+ Tests versions:
+ Python 2.6 |
2008-08-17 16:53:16 | pitrou | create | |