You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test_uuid: test_getnode and test_windll_getnode fail if connected to the Internet via an Android phone #75824
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=Nonecreated_at=<Date2017-09-29.21:37:18.944>labels= ['type-bug', 'tests', '3.9', '3.10', '3.11']
title='test_uuid: test_getnode and test_windll_getnode fail if connected to the Internet via an Android phone'updated_at=<Date2021-06-14.21:55:20.385>user='https://github.com/native-api'
Ethernet emulation for some devices like Android phones' tethering use all-zero MAC addresses (which is okay since they don't actually pass Ethernet frames to other NICs). This results in a node ID of 0 if I'm currently connected to the Net via such a device. Which fails range checks in the corresponding tests.
RFC 4122 doesn't actually have any prohibitions of using a node ID of 0. Neither does IEEE 802.3 (or rather, whatever info I gathered on it since the standard's text is not freely available) assign any special meaning to an all-zero MAC address.
The patch also corrects the check call in test_windll_getnode since the tested function always generates UUID from a MAC address.
Traceback (most recent call last):
File "C:\Ivan\cpython\lib\test\test_uuid.py", line 501, in test_windll_getnode
self.check_node(node)
File"C:\Ivan\cpython\lib\test\test_uuid.py", line449, incheck_node"%s is not an RFC 4122 node ID"%hex)
AssertionError: Falseisnottrue : 000000000000isnotanRFC4122nodeID
I'm not sure that 000000000000 is better than a random address. Even if an all-zero MAC address is not explicitly prohibited it is used in a multiple independent devices. A random address looks more appropriate fore the purpose of generating a UUID.
xdegaye commented on Dec 12, 2017
xdegayemannequin
Mannequin
More actions
I'm not sure that 000000000000 is better than a random address.
I agree, getnode() when obtained from a MAC address should not return 0.
RFC 4122 states (emphasis on 'uniqueness' is mine):
This document specifies three algorithms to generate UUIDs: the
first leverages the unique values of 802 MAC addresses to
guarantee *uniqueness*, ...
I'm not sure that 000000000000 is better than a random address. Even if an all-zero MAC address is not explicitly prohibited it is used in a multiple independent devices. A random address looks more appropriate fore the purpose of generating a UUID.
The question is not whether it's good UUID source material. The
question, for the purpose of the test, is whether it's valid getnode()
output -- which it is for the current logic.
xdegaye commented on Dec 13, 2017
xdegayemannequin
Mannequin
More actions
C:\> ipconfig -all
So the all-zero MAC address occurs on a Windows box and that explains the test_windll_getnode failure (this test is skipped on Android). I missed that point in your initial post and knowing what Android device you are using is irrelevant.
According to my tests, on Android API level 21, getnode uses the ip command to return the actual MAC address of the device. On API level 34, the ip command no longer returns anything for an unprivileged user, so getnode falls back on a random address, as documented. Either way, the resulting address is non-zero.
Activity
native-api commentedon Sep 29, 2017
Ethernet emulation for some devices like Android phones' tethering use all-zero MAC addresses (which is okay since they don't actually pass Ethernet frames to other NICs). This results in a node ID of 0 if I'm currently connected to the Net via such a device. Which fails range checks in the corresponding tests.
RFC 4122 doesn't actually have any prohibitions of using a node ID of 0. Neither does IEEE 802.3 (or rather, whatever info I gathered on it since the standard's text is not freely available) assign any special meaning to an all-zero MAC address.
The patch also corrects the check call in test_windll_getnode since the tested function always generates UUID from a MAC address.
native-api commentedon Sep 29, 2017
Example failure:
======================================================================
FAIL: test_windll_getnode (test.test_uuid.TestInternals)
----------------------------------------------------------------------
======================================================================
FAIL: test_getnode (test.test_uuid.TestUUID)
----------------------------------------------------------------------
xdegaye commentedon Dec 12, 2017
On a Samsung device with Android 5.1 and tethering enabled, only one network device has a MAC address and it is not an all-zero MAC address.
Ivan can you please provide more information about this problem: which device, what Android version, what is the output of 'ip link' ?
serhiy-storchaka commentedon Dec 12, 2017
I'm not sure that 000000000000 is better than a random address. Even if an all-zero MAC address is not explicitly prohibited it is used in a multiple independent devices. A random address looks more appropriate fore the purpose of generating a UUID.
xdegaye commentedon Dec 12, 2017
I agree, getnode() when obtained from a MAC address should not return 0.
RFC 4122 states (emphasis on 'uniqueness' is mine):
This document specifies three algorithms to generate UUIDs: the
first leverages the unique values of 802 MAC addresses to
guarantee *uniqueness*, ...
Vano commentedon Dec 12, 2017
C:\> ipconfig -all
<...>
Samsung Galaxy S7 - Ethernet адаптер:
DNS-суффикс этого подключения . . :
Описание . . . . . . . . . . . . : Android USB Ethernet/RNDIS
Физический адрес. . . . . . . . . : 00-00-00-00-00-00
Dhcp включен. . . . . . . . . . . : да
Автонастройка включена . . . . . : да
IP-адрес . . . . . . . . . . . . : 192.168.42.2
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз . . . . . . . . . . : 192.168.42.129
DHCP-сервер . . . . . . . . . . . : 192.168.42.129
DNS-серверы . . . . . . . . . . . : 192.168.42.129
Device name: Samsung Galaxy S7
Model number: SM-G930F
Android version: 6.0.1
Firmware version: G930FXXU1APGJ
Baseband version: G930VVRS4APH1
Build number: MMB29M.G930VVRU2APG5
xdegaye commentedon Dec 13, 2017
So the all-zero MAC address occurs on a Windows box and that explains the test_windll_getnode failure (this test is skipped on Android). I missed that point in your initial post and knowing what Android device you are using is irrelevant.
mhsmith commentedon Mar 6, 2024
According to my tests, on Android API level 21,
getnodeuses theipcommand to return the actual MAC address of the device. On API level 34, theipcommand no longer returns anything for an unprivileged user, sogetnodefalls back on a random address, as documented. Either way, the resulting address is non-zero.@encukou: So I think this issue can be closed.