uuid1 final segment all zeros about elixir-uuid

[zyro]

Interesting, the last segment should be populated with the local network interface address - the first one found that's not loopback. If there's no such interface, random bytes are used.

If you're seeing all zeros, the result of the network interface lookup must be weird. Can you paste here what :inet.getifaddrs() returns on your platform?

Also, can you give me any details on what platform, OS, environment, Erlang version, Elixir version etc you're seeing this problem on? And I'm curious what your use case for UUID v1 is?

[Lazarus404]

Hi Andrei,

I’m using UUID to create user tokens for sessions. I’m using Elixir 1.0.1 and Erlang 17.3 in Docker containers on a MacBook Pro, though I’ve seen the same thing happen on my CentOS test servers, too. Here’s the output of the IF addresses:

{:ok,
[{'lo0',
[flags: [:up, :loopback, :running, :multicast],
addr: {0, 0, 0, 0, 0, 0, 0, 1},
netmask: {65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535},
addr: {127, 0, 0, 1}, netmask: {255, 0, 0, 0},
addr: {65152, 0, 0, 0, 0, 0, 0, 1},
netmask: {65535, 65535, 65535, 65535, 0, 0, 0, 0}]},
{'gif0', [flags: [:pointtopoint, :multicast]]}, {'stf0', [flags: []]},
{'en0',
[flags: [:up, :broadcast, :running, :multicast],
hwaddr: [20, 16, 159, 213, 173, 35],
addr: {65152, 0, 0, 0, 5648, 40959, 65237, 44323},
netmask: {65535, 65535, 65535, 65535, 0, 0, 0, 0}, addr: {192, 168, 1, 66},
netmask: {255, 255, 255, 0}, broadaddr: {192, 168, 1, 255}]},
{'p2p0',
[flags: [:up, :broadcast, :running, :multicast],
hwaddr: [6, 16, 159, 213, 173, 35]]},
{'awdl0',
[flags: [:up, :broadcast, :running, :multicast],
hwaddr: [22, 39, 16, 145, 124, 241],
addr: {65152, 0, 0, 0, 5159, 4351, 65169, 31985},
netmask: {65535, 65535, 65535, 65535, 0, 0, 0, 0}]},
{'en1',
[flags: [:up, :broadcast, :running, :multicast],
hwaddr: [50, 0, 22, 78, 162, 96]]},
{'en2',
[flags: [:up, :broadcast, :running, :multicast],
hwaddr: [50, 0, 22, 78, 162, 97]]},
{'bridge0',
[flags: [:up, :broadcast, :running, :multicast],
hwaddr: [22, 16, 159, 93, 249, 0]]},
{'utun0',
[flags: [:up, :pointtopoint, :running, :multicast],
addr: {65152, 0, 0, 0, 49278, 50886, 17575, 459},
netmask: {65535, 65535, 65535, 65535, 0, 0, 0, 0}, dstaddr: {28, 30, 0, 0},
addr: {64861, 3611, 3017, 15038, 49278, 50886, 17575, 459},
netmask: {65535, 65535, 65535, 65535, 0, 0, 0, 0},
dstaddr: {24, 18, 11, 0}]},
{'vboxnet0',
[flags: [:up, :broadcast, :running, :multicast],
hwaddr: [10, 0, 39, 0, 0, 0], addr: {192, 168, 59, 3},
netmask: {255, 255, 255, 0}, broadaddr: {192, 168, 59, 255}]},
{'vboxnet1', [flags: [:broadcast, :multicast], hwaddr: [10, 0, 39, 0, 0, 1]]},
{'vboxnet2',
[flags: [:broadcast, :multicast], hwaddr: [10, 0, 39, 0, 0, 2]]}]}

Kind regards,
Lee

On 2 Jan 2015, at 15:18, Andrei Mihu [email protected] wrote:

Interesting, the last segment should be populated with the local network interface address - the first one found that's not loopback. If there's no such interface, random bytes are used.

If you're seeing all zeros, the result of the network interface lookup must be weird. Can you paste here what :inet.getifaddrs() returns on your platform?

Also, can you give me any details on what platform, OS, environment, Erlang version, Elixir version etc you're seeing this problem on? And I'm curious what your use case for UUID v1 is?

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

[zyro]

Interesting, I've plugged in that exact output instead of my call to :inet.getifaddrs() and I get a valid UUID, like so:

"cc8cdd5c-92d5-11e4-b5a9-14109fd5ad23"

To get the output you pasted above, I assume you opened a terminal and ran iex. Can you call UUID.uuid1 in that same space? If you get a valid UUID, then it may be something to do with how Docker exposes network interfaces to the application.

[zyro]

@Lazarus404 Do you still need help with this issue?

[zyro]

Closing this as not needed anymore. Please ping me if this changes!

[Lazarus404]

Hi Zyro,

Sorry, yes, still apparent. The OS is CentOS 7. We use UUID in multiple applications in many places, all of which are in Docker, and all have the same problem.

Maybe uuid1 could have an optional attribute to force random bytes?

Thanks,
Lee

[zyro]

If you're happy with random bytes, maybe uuid4 would give you better results?

Meanwhile I'll try and put together a small project in a Docker container and see how it behaves.

[Lazarus404]

Thanks. To be honest, I like the datetime based approach of uuid1. I’ve had issues with duplicate values from fully random bytes in the past, due to the way Erlang seeds its random values.

Lee

On 18 Mar 2015, at 19:17, Andrei Mihu [email protected] wrote:

If you're happy with random bytes, maybe uuid4 would give you better results?

Meanwhile I'll try and put together a small project in a Docker container and see how it behaves.

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