OSError("a valid MAC could not be determined.")

[dvirtz]

I started getting this error on every login attempt on a Windows 10 machine.
Until a couple of days before it didn't complain and when I try this on a VirtualBox runnig Ubuntu it works perfectly.
Any idea?

[simon-weber]

Huh, weird. We don't really get any more debugging information from python about this, so I'd suggest just picking a mac and sticking with it.

My best guess: it has something to do with permission levels. Maybe try running the script as an admin and see if it works?

[dvirtz]

Thanks but admin doesn't work.

[thebigmunch]

Not sure if you're using WiFi with a controller that supports MAC address randomization. If so, go to Manage WiFi Settings in your settings and check if the Use random hardware addresses is enabled. I haven't read anything on it, but it seems like it could potentially cause an issue.

[dvirtz]

I don't have this option so I guess my hardware doesn't support it.

On 8 February 2016 at 22:50, thebigmunch [email protected] wrote:

Not sure if you're using WiFi with a controller that supports MAC address
randomization. If so, go to Manage WiFi Settings in your settings and
check if the Use random hardware addresses is enabled. I haven't read
anything on it, but it seems like it could potentially cause an issue.

—
Reply to this email directly or view it on GitHub
#408 (comment)
.

[simon-weber]

^ #418 is showing the same problem off of windows. I'm thinking maybe the python 3 changes broke mac address detection? It seems weird to have a bunch of people run into this at once.

[tjstum]

I can take a look later tonight and see if I can repro this on Windows.

[simon-weber]

Great; thanks.

[thebigmunch]

Unless you've been contacted by a lot of people through email, I don't think 2 really counts as a bunch : P

My desktop (and main development/testing machine) is Windows 8.1, and I commonly use a remote server running Gentoo as my Linux testing machine. I've been testing a lot recently and haven't come across this. Up until after I made those last bytes/unicode fixes, I was using both Python 2.7.11 and Python 3.5. Though now I only use Python 3.5.

@dvirtz @lelandbatey: What version of Python are you guys using?

If this isn't Python 2-specific, it sounds a lot more like a some kind of system issue/quirk.

[dvirtz]

I've tested both Python 2.7.11 and 3.5 and the issue reproduces. However,
it seems I have the same network adapter as the other guy.
On Feb 24, 2016 19:48, "thebigmunch" [email protected] wrote:

Unless you've been contacted by a lot of people through email, I don't
think 2 really counts as a bunch : P

My desktop (and main development/testing machine) is Windows 8.1, and I
commonly use a remote server running Gentoo as my Linux testing machine.
I've been testing a lot recently and haven't come across this. Up until
after I made those last bytes/unicode fixes, I was using both Python 2.7.11
and Python 3.5. Though now I only use Python 3.5.

@dvirtz https://github.com/dvirtz @lelandbatey
https://github.com/lelandbatey: What version of Python are you guys
using?

If this isn't Python 2-specific, it sounds a lot more like a some kind of
system issue/quirk.

—
Reply to this email directly or view it on GitHub
#408 (comment)
.

[tjstum]

I looked into this and didn't really learn anything (I couldn't reproduce this on a Windows 7 or 10 VM). uuid is implemented in Python and has a variety of things it will try to resolve getnode. They're all very platform specific, so I'm baffled as to what could be causing the same issue across multiple platforms.

On Windows, the routines look basically identical (modulo some bytes/long changes) between 2.7 and master. It tries a system call (using ctypes), then netbios, then ipconfig.
On other platforms, the routines also look very similar (though there is one extra method that python 3 will try).

I would ask @dvirtz and @lelandbatey to try running uuid.getnode() and try stepping through using pdb to see if something really crazy is happening (like we're actually getting one of these "invalid" addresses not as the fallback). I can write a simple script if it would help.

[dvirtz]

I did it and uuid.getnode() returns some value, but its bit 40 is set, so the line
if (mac_int >> 40) % 2:
fails.

[tjstum]

Right. That doesn't give us any more information, though.

Do you know how to use the python debugger to step into the call to getnode?

[dvirtz]

getnode just returns what the windows function UuidCreateSequential() returns.
if I delete _windll_getnode from the list of getters I can login successfully, but it also works if I delete the requirement on bit 40 and do use _windll_getnode.
What is the reason behind this requirement?

[thebigmunch]

uuid.getnode() returns a 48 bit integer representation of a MAC address if it was obtained or a random 48 bit integer if an address can't be obtained. if (mac >> 40) % 2 is a way to check if the result of getnode() was a random integer because getnode() will set the 8th bit to 1 per RFC 4122's recommendation. You can also call uuid.getnode() twice on your system to see if they give you the same result if you want some extra confirmation.

So, it's still a good idea to find out why Python doesn't seem to be getting a valid MAC from your systems.

[dvirtz]

seems like a problem on windows' UuidCreateSequential(). I tried all three methods to get MAC address on the article Three ways to get your MAC address and this is what I get:

usingCreateUuid
C3-XX-XX-XX-XX-XX
usingNetBios
00-XX-XX-XX-XX-XX
usingAdaptersInfo
0A-XX-XX-XX-XX-XX
00-XX-XX-XX-XX-XX

And the return value of UuidCreateSequential() is RPC_S_OK.

[tjstum]

In an effort to debug this further, I put up a gist that will print out what each method of getting the MAC address returns.

I would recommend running it by doing something like this (on a nix-like):

curl https://gist.github.com/tjstum/ac49e3e70dd302392564/raw/45c80b2641919a2eb7dbfb224f4a0354135f52e3/getnode.py > getnode.py
python getnode.py --anonymize

On Windows, you can download the raw python file, save it somewhere and then run it from the command prompt in the same way.

@dvirtz and @lelandbatey: can you run that and let us know what it prints? It won't actually give us your MAC address.

[dvirtz]

Addresses anonymized. Addresses will print out 0x### where ### is an incrementing number.                   Identical addresses will have the same number.
Trying _windll_getnode...
Result from _windll_getnode:0x0
That would fail
Trying _netbios_getnode...
Result from _netbios_getnode:0x1
Trying _ipconfig_getnode...
Result from _ipconfig_getnode:0x1

[tjstum]

It's interesting that the different methods return different addresses. Do you have several network adapters or virtual adapters or something? Just curious...

@simon-weber, do we need to check that bit? @dvirtz says that login succeeds even in this case.

@thebigmunch, I think that calls to uuid.getnode() are cached, so I don't think calling it twice would show anything. I could also be misreading the implementation of getnode.

[thebigmunch]

@tjstum: I should have specified to do it in different runs. The bit needs to be checked to prevent a new device from being created on your Google account and, in the case of Musicmanager, Google Music every time you login. I can't remember if the Mobileclient will create a new device on Google Music as well.

[tjstum]

@dvirtz, if you run that script without --anonymize, is the result you get from _windll_getnode an actual MAC address on your machine?

[dvirtz]

No, I don't see it on the output of 'ipconfig /all'
On Mar 2, 2016 05:10, "Tim Stumbaugh" [email protected] wrote:

@dvirtz https://github.com/dvirtz, if you run that script without
--anonymize, is the result you get from _windll_getnode an actual MAC
address on your machine?

—
Reply to this email directly or view it on GitHub
#408 (comment)
.

[lelandbatey]

Sorry to respond after so long, but here's the results from running your getnode.py script (both with --anonymize and without):

$ python getnode.py 
Trying _unixdll_getnode...
Result from _unixdll_getnode:0xC50CB038F354
That would fail
Trying _ifconfig_getnode...
Result from _ifconfig_getnode:0x8086F2C74043
Trying _arp_getnode...
_arp_getnode returned None!
Trying _lanscan_getnode...
_lanscan_getnode returned None!
Trying _netstat_getnode...
_netstat_getnode returned None!

$ python getnode.py --anonymize
Addresses anonymized. Addresses will print out 0x### where ### is an incrementing number. Identical addresses will have the same number.
Trying _unixdll_getnode...
Result from _unixdll_getnode:0x0
That would fail
Trying _ifconfig_getnode...
Result from _ifconfig_getnode:0x1
Trying _arp_getnode...
_arp_getnode returned None!
Trying _lanscan_getnode...
_lanscan_getnode returned None!
Trying _netstat_getnode...
_netstat_getnode returned None!

Additionally, here is the output of ip addr show and ifconfig:

$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 80:86:f2:c7:40:43 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.113/24 brd 192.168.1.255 scope global dynamic wlan0
       valid_lft 76227sec preferred_lft 76227sec
    inet6 fe80::8286:f2ff:fec7:4043/64 scope link 
       valid_lft forever preferred_lft forever

$ ifconfig
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:57816 errors:0 dropped:0 overruns:0 frame:0
          TX packets:57816 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:31019874 (31.0 MB)  TX bytes:31019874 (31.0 MB)

wlan0     Link encap:Ethernet  HWaddr 80:86:f2:c7:40:43  
          inet addr:192.168.1.113  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::8286:f2ff:fec7:4043/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1011448 errors:0 dropped:0 overruns:0 frame:0
          TX packets:454851 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1271920280 (1.2 GB)  TX bytes:68346099 (68.3 MB)

@tjstum it seems the get_node.py script is correctly finding the MAC address of wlan0 via the _ifconfig_getnode method. Don't know if that helps.

Thank you for doing all this debugging work so far, if there's anything else I can do to help with this bug, please let me know.

[tjstum]

@dvirtz and @lelandbatey, when you run without --anonymize repeatedly, are the addresses you get from the first method (either _unixdll_getnode or _windll_getnode) the same each time, or do they appear to be different each time?

This is sort of looking like a bug in uuid itself, tbh.

[simon-weber]

One thing that can cause weirdness with uuid is the system clock -- I actually managed to crash it with https://github.com/simon-weber/python-libfaketime once.

[lelandbatey]

@tjstum I get the same address repeatedly from _unixdll_getnode. I just ran it, two days on from my last comment, and I get the same result: _unixdll_getnode:0xC50CB038F354.

[tjstum]

I have no idea then 😞

If you're getting the same result from _unixdll_getnode that isn't a real address on the machine, where is it coming from? Do you maybe have some virtual interface?

Either way, I don't have a great suggestion for how this could be handled by gmusicapi. Overriding the internals of uuid.getnode does not strike me as a great idea.

[Forceflow]

I just started having this problem on an ubuntu 16.10 machine - all was working fine until a few days ago.

This was the error I was getting (using gmusicapi-scripts).

   MusicManagerWrapper authentication failed. Traceback (most recent call last): File 
   "/usr/local/lib/python3.5/dist-packages/gmusicapi_wrapper/musicmanager.py", line 54, in login if not 
   self.api.login(oauth_credentials=oauth_cred, uploader_id=uploader_id): File 
   "/usr/local/lib/python3.5/dist-packages/gmusicapi/clients/musicmanager.py", line 170, in login 
   self._perform_upauth(uploader_id, uploader_name)) File "/usr/local/lib/python3.5/dist-
   packages/gmusicapi/clients/musicmanager.py", line 207, in _perform_upauth raise OSError('a valid 
   MAC could not be determined.' OSError: a valid MAC could not be determined. Provide uploader_id 
   (and be sure to provide the same one on future runs).

Weirdly enough, a reboot seems to have fixed it.

This is my ifconfig output:

   jeroen@yavin:~$ ifconfig
   eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
   inet 192.168.1.120  netmask 255.255.255.0  broadcast 192.168.1.255
   inet6 fe80::1a66:daff:fe36:2a00  prefixlen 64  scopeid 0x20<link>
   inet6 fd8b:b424:1214:0:1a66:daff:fe36:2a00  prefixlen 64  scopeid 0x0<global>
   ether 18:66:da:36:2a:00  txqueuelen 1000  (Ethernet)
   RX packets 2685  bytes 1775899 (1.7 MB)
   RX errors 0  dropped 0  overruns 0  frame 0
   TX packets 1795  bytes 419602 (419.6 KB)
   TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
   device interrupt 20  memory 0xf7c00000-f7c20000

Always found it a bit weird that no hwaddress is explicitly specified, but the ether is equivalent, no? Maybe a recent change to networkmanager fiddled this up?

[simon-weber]

Huh, very bizarre. Especially that it'd clear up after a reboot.

[Forceflow]

Trying to reproduce .... Maybe something did fudge up the ability for Python to grab a MAC address.
I'll watch it more closely from now on.

[Forceflow]

A quick update: I'm having this consistently on Ubuntu 17.04 now.
I can fix it by manually grabbing my MAC address and adding 1, then passing this to the script I'm using (and thus into the login function of gmusicapi)

./gmsync.py -U '18:66:DA:36:2A:01' /media/Music/

Just in case anyone else was struggling with this (bizarre) issue.

[simon-weber]

I'm going to close this since it's gone stale (and from_mac_address seems broken on Google's end anyway these days: #590).

[poleguy]

I'm getting this error on Centos 7. Is there any way to work around this?

[poleguy]

I just hacked mobileclient.py and musicmanager.py by replacing the line:
mac_int = get_mac()
with
mac_int = 123456789

and hackity, hack, it is uploading.

Since this is optional, it probably should not error out if it can't find a mac, especially since the uploader_id seems to be optional.

[simon-weber]

That will probably work, but I'd recommend passing the uploader_id param instead. There's more details as to why in the docs.