classification
Title: uuid1() fails if only 64-bit interface addresses are available
Type: crash Stage: needs patch
Components: Library (Lib) Versions: Python 3.6
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: anpetral, barry, ned.deily
Priority: normal Keywords:

Created on 2018-01-06 16:26 by anpetral, last changed 2018-01-13 00:56 by anpetral.

Messages (8)
msg309554 - (view) Author: Andres Petralli (anpetral) Date: 2018-01-06 16:26
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 0xff000000 \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 <module>
    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)
msg309556 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2018-01-06 17:01
On Jan 6, 2018, at 11:26, Andres Petralli <report@bugs.python.org> wrote:
> 
> Traceback (most recent call last):
>  File "/Users/andy/Desktop/test.py", line 3, in <module>
>    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)

Interesting.  This doesn’t fail for me on 10.13.2.
msg309562 - (view) Author: Andres Petralli (anpetral) Date: 2018-01-06 18:06
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 0xff000000 
	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 <full-duplex>
	status: inactive
msg309876 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-01-12 23:16
Thanks for your additional analysis.  So, assuming I understand it correctly, the problem here is that there can be hardware configurations where the only (or first?) hardware addresses available exceed 48 bits.  I'm not sure what might be different for your system when running 10.13, assuming uuid1() used to work on earlier versions of macOS; perhaps another network interface with a smaller address was supported and configured?  It seems like such configurations are pretty rare; there don't seem to be any prior bug reports on this and it would be unusual for Mac systems to only have a Firewire (non-loopback) network interface configured.  In any case, such configurations presumably are not limited to Macs so I'm removing the macOS tag.
msg309882 - (view) Author: Andres Petralli (anpetral) Date: 2018-01-13 00:19
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.
msg309883 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-01-13 00:23
(As a workaround, you *might* be able to reorder the network interfaces in the System Preferences -> Network control panel.)
msg309884 - (view) Author: Andres Petralli (anpetral) Date: 2018-01-13 00:29
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.
msg309885 - (view) Author: Andres Petralli (anpetral) Date: 2018-01-13 00:56
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
History
Date User Action Args
2018-01-13 00:56:35anpetralsetmessages: + msg309885
2018-01-13 00:29:32anpetralsetmessages: + msg309884
2018-01-13 00:23:13ned.deilysetmessages: + msg309883
2018-01-13 00:19:34anpetralsetmessages: + msg309882
2018-01-12 23:16:54ned.deilysettitle: uuid1() broken on macos high sierra -> uuid1() fails if only 64-bit interface addresses are available
nosy: - ronaldoussoren

messages: + msg309876

components: + Library (Lib), - macOS
stage: needs patch
2018-01-06 18:06:48anpetralsetmessages: + msg309562
2018-01-06 17:01:40barrysetnosy: + barry
messages: + msg309556
2018-01-06 16:26:25anpetralcreate