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)

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.

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

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.

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.

(As a workaround, you *might* be able to reorder the network interfaces in the System Preferences -> Network control panel.)

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.

Re: rarity. There is at least one more person that ran into the same issue as seen in this report: Azure/azure-cli#5184

New changeset 6b273f7 by Barry Warsaw (Bo Bayles) in branch 'master':
bpo-32502: Discard 64-bit (and other invalid) hardware addresses (bpo-5254)
6b273f7

New changeset d69794f by Barry Warsaw (Bo Bayles) in branch '3.6':
[3.6] bpo-32502: Discard 64-bit (and other invalid) hardware addresses (GH-5254) (bpo-5290)
d69794f

Could the fix be backported to 2.7 branch? Apparently on macOS 2.7 is also affected macports/macports-ports#2456

I created the backport PR for 2.7 branch. Can anyone reopen this issue?

New changeset d919c60 by Benjamin Peterson (Chih-Hsuan Yen) in branch '2.7':
[2.7] bpo-32502: Discard 64-bit (and other invalid) hardware addresses (GH-9125)
d919c60