[issue32502] uuid1() fails if only 64-bit interface addresses are available
Andres Petralli <anpet...@microsoft.com> added the comment: Re: rarity. There is at least one more person that ran into the same issue as seen in this report: https://github.com/Azure/azure-cli/issues/5184 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32502] uuid1() fails if only 64-bit interface addresses are available
Andres Petralli <anpet...@microsoft.com> added the comment: Moving doesn't work, but even removing the firewire adapter (which was unused on my system), doesn't remove it from the output of ifconfig. I did however work around the issue by just patching up uuid in a suboptimal manner (truncated the 64bit int to 48bit). A proper fix would probably need to discard EUI-64 addresses and look for EUI-48 specifically. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32502] uuid1() fails if only 64-bit interface addresses are available
Andres Petralli <anpet...@microsoft.com> added the comment: This could be purely incidental to have shown up in 10.13, but yes, the problem comes from the fact that the first hardware ID in the list of devices happens to be an EUI-64 address with 64 bits now. This is the Firewire interface of my Mac Pro and maybe one of the few that actually uses a EUI-64 addresses, hence relatively rare. Maybe the order changed in 10.13 and this now happens to be the first entry returned from 'ifconfig' when previously maybe it was the Ethernet adapter, but given the lookup algorithm in uuid reads in line by line until it finds the first hw id, this is bound to fail on my machine. Clearly, I don't think uuid should make assumptions about order of interfaces that could have mixed EUI-48 and EUI-64 addresses. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32502] uuid1() broken on macos high sierra
Andres Petralli <anpet...@microsoft.com> added the comment: Here's the output from my system. This is a Mac Pro with a firewire port. Looks as if the address was picked up from fw0: actually, not lo0. Guess _find_mac just iterates until it hits a matching word for a hw address: lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP> inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=201<PERFORMNUD,DAD> gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 UHC58: flags=0<> mtu 0 XHC0: flags=0<> mtu 0 UHC90: flags=0<> mtu 0 UHC61: flags=0<> mtu 0 UHC29: flags=0<> mtu 0 UHC26: flags=0<> mtu 0 UHC93: flags=0<> mtu 0 EHC253: flags=0<> mtu 0 EHC250: flags=0<> mtu 0 fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078 lladdr 70:cd:60:ff:ab:cd:ef:12 nd6 options=201<PERFORMNUD,DAD> media: autoselect status: inactive -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32502] uuid1() broken on macos high sierra
New submission from Andres Petralli <anpet...@microsoft.com>:
uuid.py is getting a 64 bit hardware address for the loopback adapter in High
Sierra, specifically in _ifconfig_getnode(). The function expects a 48 bit mac
address, but is instead getting 64 bits back and converting it to an int value
that is too long for the subsequent call in uuid.py. Apple must have moved to
using EUI-64 for the loopback adapters.
This is a sample output of the call to ifconfig that is being parsed:
b'lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384\n'
b'\toptions=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>\n'
b'\tinet 127.0.0.1 netmask 0xff00 \n'
b'\tinet6 ::1 prefixlen 128 \n'
b'\tlladdr 70:cd:60:ff:ab:cd:ef:12 \n'
As you can see, the lladdr is longer than the usual 48 bit mac address but is
nontheless returned for the node value, which then triggers
ValueError('field 6 out of range (need a 48-bit value)')
Full traceback:
Traceback (most recent call last):
File "/Users/andy/Desktop/test.py", line 3, in
str(uuid.uuid1())
File
"/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/uuid.py",
line 607, in uuid1
clock_seq_hi_variant, clock_seq_low, node), version=1)
File
"/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/uuid.py",
line 168, in __init__
raise ValueError('field 6 out of range (need a 48-bit value)')
ValueError: field 6 out of range (need a 48-bit value)
--
components: macOS
messages: 309554
nosy: anpetral, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: uuid1() broken on macos high sierra
type: crash
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32502>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
