Reason for NLE_MSGTYPE_NOSUPPORT

[Yves Langisch]

The problem is that I don't have a request/response communication with 
the kernel module. I register my user space process in the kernel in 
order to receive subsequent unicast events:

register -->
event <--
event <--
...

As you only increase the excepted sequence number in case of an ACK (and 
some other types) we get out of sync when receiving events.

nl.c:
...
		if (hdr->nlmsg_type == NLMSG_DONE ||
		    hdr->nlmsg_type == NLMSG_ERROR ||
		    hdr->nlmsg_type == NLMSG_NOOP ||
		    hdr->nlmsg_type == NLMSG_OVERRUN) {
			/* We can't check for !NLM_F_MULTI since some netlink
			 * users in the kernel are broken. */
			handle->h_seq_expect++;
			NL_DBG(3, "recvmsgs(%p): Increased expected " \
			       "sequence number to %d\n",
			       handle, handle->h_seq_expect);
		}
...


On 05.11.2010 14:07, Thomas Graf wrote:
> On Fri, Nov 05, 2010 at 12:13:54AM +0100, Yves Langisch wrote:
>> This happens on the client side. After going through your source
>> code it turned out that there was a sequence number mismatch which
>> leads to a -22 (-EINVAL). After registering my own callback
>> everything works fine. Thanks!
>
> Sorry for not replying earlier. Still a bit congested at LPC.
>
> That's interesting, can you show me how to reproduce this? I'd
> like to fix this.
>
> _______________________________________________
> libnl mailing list
> libnl at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libnl
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20101106/5954343f/attachment.p7s>