lib/socket: use proper typed constant UINT32_MAX for uint32_t typed port

This was a bug on architectures with native int type less then 32 bit.

Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Thomas Haller <thaller@redhat.com>
lib/socket: don't fail if no more local ports can be assigned in nl_socket_alloc

By failing inside of nl_socket_alloc(), the user can not even work around
when running out of local ports. This patch changes that if there are no more
local ports, we set the port to UINT32_MAX. This is a consistent behavior
to calling nl_socket_set_local_port(sk, 0).

In general, since nl_socket_set_local_port() does not restict the generated
ports in any way we cannot assume to have a valid port. So the check in
the constructor was harmful and users who ever encountered it (because they
created 1024 libnl3 sockets) could not even work around it.

Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Thomas Haller <thaller@redhat.com>
lib/socket: retry generate local port in nl_connect on ADDRINUSE

It can easily happen that the generated local netlink port is alrady in
use. In that case bind will fail with ADDRINUSE.

Users of libnl3 could workaround this, by managing the local ports
themselves, but sometimes these users are libraries too and they also
don't know which ports might be used by other components.

This patch changes that nl_socket_alloc() no longer initilizes the local
port id immediately. Instead it will be initialized when the user calls
nl_socket_get_local_port() the first time and thereby shows interest in
the value.

If bind() fails with ADDRINUSE, check if the user ever cared about the
local port, i.e. whether the local port is still unset. If it is still
unset, assume that libnl should choose a suitable port and retry until
an unused port can be found.

Signed-off-by: Thomas Haller <thaller@redhat.com>
lib/socket: randomize the generated local port

Instead of always trying the same order of ports when
looking for an unused port, randomize the order (naively).

As libnl-1 uses the same function, it is likely that two applications
that are using both libraries generate the same ports. By chosing a
different order how to select the local port, the chances are smaller
for this to happen (however, it cannot avoid it entirely. The user
and/or libnl3 still has to cope with the situation, that somebody
else might already use the port).

Signed-off-by: Thomas Haller <thaller@redhat.com>
Merge branch 'socket_local_port'

Signed-off-by: Thomas Haller <thaller@redhat.com>