Author kfrazier
Recipients kfrazier
Date 2011-03-14.20:31:27
SpamBayes Score 3.51702e-12
Marked as misclassified No
Message-id <>
If a virtual interface is present in the system, such as if the user is connected to a VPN, then there may be entries in ifconfig that do not conform to the expected `HWAddr 01:23:45:67:89:ab` MAC address format expected by uuid._find_mac. For instance, under Ubuntu 10.10 on my Acer Eee 1005HA, using Cisco's AnyConnect VPN client, I have the following entry in ifconfig:

cscotun0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 

Not only is this more than 6 bytes long, it also uses dashes as a delimiter rather than the colons used by MAC address. After reading the relevant parts of RFC4122's definition of the algorithm for UUID1, I think we probably should be ignoring these virtual interfaces, since I doubt they are guaranteed to be unique.

The attached patch assumes that it is correct to ignore these entries. If this is not appropriate, it might be better to strip all colons and dashes before the int conversion.

I tried to write a test to demonstrate this issue, but had difficulty figuring out how to make it work. The import of `os` is at the function level rather than at the top of the uuid module, so mocking out the module didn't seem feasible. I also tried replacing the call to ifconfig with a call to echo with the appropriate strings to emulate this result, but echo is typically not within any of the hard-coded list of directories that _find_mac looks in. If anyone has a good idea of how to write a test for this issue, I would be happy to write one with some guidance, but I was stumped.

This is my first patch submission to CPython, so if I did anything incorrectly, please let me know and I will try to correct my error.
Date User Action Args
2011-03-14 20:31:32kfraziersetrecipients: + kfrazier
2011-03-14 20:31:31kfraziersetmessageid: <>
2011-03-14 20:31:27kfrazierlinkissue11508 messages
2011-03-14 20:31:27kfraziercreate