nl_send_sync returns without consuming ack message

[Thomas Haller]

On Fri, 2017-01-20 at 20:37 +0100, Christophe Gouault wrote:
> Hi,
> 
> I am trying to use the nl_send_sync() with auto-ack enabled, to
> retrieve the response to an XFRM_MSG_GETAE request.
> 
> In case of error (e.g. IPsec SA does not exist), the kernel sends a
> single NLMSG_ERROR netlink message (error message). nl_send_sync()
> returns a error value and the NLMSG_ERROR message is consumed (OK).
> 
> However, in case of success (IPsec SA found), the kernel sends 2
> distinct netlink messages (with same sequence number but not
> MULTIPART
> flag): an XFRM_MSG_NEWAE (response) + an NLMSG_ERROR (ack message)
> but
> nl_send_sync() only processes the first one.
> 
> The NL_CB_INVALID callback is properly invoked to process the
> XFRM_MSG_NEWAE message, but the ack message is not read.
> nl_send_sync() returns 0 without consuming the ack, which remains in
> the socket buffer. It will be read next time someone reads the
> socket,
> instead of reading a response to a new request.
> 
> I expected nl_send_sync() to process all messages until an error or
> ack is read. Am I missing something?
> 
> Regards,
> Christophe

Hi Chirstophe,

nl_send_sync() basically just sends the request and then calls
nl_wait_for_ack(). I assume you did not set NL_NO_AUTO_ACK -- because
then nl_wait_for_ack() is bypassed.

Then, nl_wait_for_ack() modifies the current socket handler 
  nl_cb_set(cb, NL_CB_ACK, NL_CB_CUSTOM, ack_wait_handler, NULL);
that means, if you have another handler installed which returns NL_STOP
before the ACK is received, it will not wait.

I would check if there are conflicting handlers present.
  https://github.com/thom311/libnl/blob/3dd2a0f26fa59896b4b4a262cf309a4be4aa70d3/lib/nl.c#L1112

best,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20170123/21a61f3e/attachment.sig>