Sequence number mismatch

[Teto]

Hi,

Ok I found the problem.  I had changed some parameters because my
daemon would only answer the first time it recieved a request. I've
reset all sequence number to 0 and disabled seq checks and had a look
at the python binding though I was not that enthusiast ^^''' .
I added some pynl_debug to check what was going on ( btw the pynl_dbg
macro is not portable and doesn't work if you have no additionnal
arguments, a portable with 0 or more varargs is doable like this
https://github.com/teto/lispmob/blob/forwarding/lispd/lispd_log.h ).

When checking the callback return value in capi.i:nl_recv_msg_handler,
the code used PyArg_ParseTuple which only works with tuples or so it
seems: http://stackoverflow.com/questions/13636711/what-is-the-proper-usage-of-pyarg-parsetuple
So the daemon would answer the first request but then
:nl_recv_msg_handler could not parse the return value and would return
NL_STOP, thus preventing from answering other requests. Once you
replace PyArg_ParseTuple with PyLong_AsLong it works fine.

Here is  how I did it but it seems it's not the optimal solution if
referring to the previous stackoverflow answer.
    /* if (!PyArg_ParseTuple(resobj, "i:nl_recv_msg_handler", &result)) { */

    if(! PyLong_Check(resobj) ) {
        pynl_dbg("Result is not an integer : it should be ! %s\n","");
        return NL_STOP;
    }

    result = PyLong_AsLong(resobj);
    /*if (!PyArg_ParseTuple(resobj, "i:nl_recv_msg_handler", &result)) {
        pynl_dbg("could not parse tuple %s\n","");
        result = NL_STOP;
    }*/
    pynl_dbg("Callback result %ld\n",result);
    Py_DECREF(resobj);
    return result;

Regards
Matt

On Sat, Sep 7, 2013 at 5:07 PM, Teto <mattator at gmail.com> wrote:
> Hi,
>
> I have a kernel module creating a family and multicasting messages for
> a group of that family, always with the same seq number 0.
>
> In my userspace daemon, I subscribe to this very group, disable seq
> check  via nl.nl_socket_disable_seq_check(self.sk);
> and listens for notifications. The problem is as soons as a
> notification comes in I have an error -16 in libnl "Sequence number
> mismatch". What did I misunderstood ?
>
> Thanks in advance for any hints.
>
>
> Here is the part of the kernel module (with checks removed) and
> enclosed the python daemon (relevant part is the function
> send_rlocs_list_for_eid)
> =====
>     skb = genlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>
>     msg_head = genlmsg_put(
>                         skb,
>                         0,              /* pid : NL_AUTO_PID no de port  */
>                         0,    /* seq nb: ( ne marche pas) */
>                         &lig_gnl_family,    /* family */
>                         0,              /* Flags */
>                         ELC_REQUEST_RLOCS_FOR_EID   /* command */
>                         );
>
>
>    nla_put_u32( skb, ELA_MPTCP_TOKEN, token );
>    nla_put_u32( skb, ELA_EID, eid);
>
>
>     /* finalize the message */
>     genlmsg_end(skb, msg_head);
>
>
>     rc = genlmsg_multicast(
>         skb,
>         0,  /* set own pid to not recevie */
>         lig_multicast_group.id, /* group id */
>         GFP_KERNEL /* allocation */
>          );
> ====