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