Problem: running out of free local 'ports'

Joerg Marx joerg.marx at secunet.com
Fri Jun 10 06:03:32 EDT 2011


Hi,

while implementing a library routine, which is able to give back all
local bound addresses in a list, I encountered a small problem with
libnl-2.1.

A long running process using that library got no list of local addresses
anymore after a while.

The culprit was the the following sequence:

...
sock = nl_socket_alloc();
nl_socket_set_local_port(sock, 0);
...

(Setting to '0' was to overcome another problem: the long running
process is using another private netlink-socket which gave an EEXIST for
the first socket instantiated by libnl due to both using the PID approach)

The problem is, that nl_socket_set_local_port will gladly fill in a new
local port effectively wasting one entry in the port-array managed by
generate_local_port.
So after a while no free entry is left and __alloc_socket fails due to that.

I expect this a bug, but this leads to the more important question: why
allocate a local port in __alloc_socket anyway? The man page IMHO says,
that the kernel will fill in a suitable value when provided a '0' in the
struct sockaddr_nl for nl_pid.
This way you can have more than one netlink socket without the risk of
collision and EEXIST.

So my suggestion is to eliminate
'sk->s_local.nl_pid = generate_local_port();' in __alloc_socket and set
nl_pid to '0'.
If someone wants to have an explicit local port, let him use
nl_socket_set_local_port(...).

What do you think?

best regards
Jörg.

-- 



More information about the libnl mailing list