New address announcements in RTMGRP_IPV4_IFADDR netlink group

New address announcements in RTMGRP_IPV4_IFADDR netlink group

[Teemu Koponen]

Netlink developers and gurus,

While fine-tuning the handover speed for a certain L3 mobility daemon 
under Linux 2.6.11.10, I stumbled into the following behavior which 
intuitively does not follow the semantics of the RTMGRP_IPV4_IFADDR 
group:

0) A userspace daemon process is running and listening to the broadcast 
group.

1) Address is inserted to an interface (ip addr add ... at shell).

2) The daemon receives a NEWADDR message, just as is should, but the 
daemon is unable to bind to the address *immediately* (actually in the 
function that processes the netlink message). The result is "cannot 
assign an address" from the bind call. However, if I do insert a single 
nanosleep, even with an arbitrary low sleep value, before the bind 
call, the bind then succeeds.

So, what is the semantics of NEWADDR? Should the address be bindable 
right after receiving the message? Or is there a race-condition between 
userspace and kernel that the inserted sleep helps to overcome by 
letting the kernel to run again before the bind call?

TIA,
Teemu

--

Re: New address announcements in RTMGRP_IPV4_IFADDR netlink group

[Thomas Graf]

* Teemu Koponen <aa027950f2fc7f2ad640cac4a11fbe93@iki.fi> 2005-06-06 11:59
> 0) A userspace daemon process is running and listening to the broadcast 
> group.
> 
> 1) Address is inserted to an interface (ip addr add ... at shell).
> 
> 2) The daemon receives a NEWADDR message, just as is should, but the 
> daemon is unable to bind to the address *immediately* (actually in the 
> function that processes the netlink message). The result is "cannot 
> assign an address" from the bind call. However, if I do insert a single 
> nanosleep, even with an arbitrary low sleep value, before the bind 
> call, the bind then succeeds.
> 
> So, what is the semantics of NEWADDR? Should the address be bindable 
> right after receiving the message?

The bind() call doesn't fail because of the address being non-existant,
it fails because the route has not been created for it. The netlink
message is generated before we notify the other subsystems about the
addition of a new address so you try to bind to an adress for which
no route has been generated yet. The best solution is probably to wait
for the route addition notification message being received and then
bind to that address.