On Linux wwwwww-701SD 2.6.35-30-generic #59-Ubuntu SMP Tue Aug 30
15:58:00 UTC 2011 i686 GNU/Linux
with libnetfilter-conntrack3 Version: 0.0.101-1
Hi, my application uses libnetfiler_conntrack. When I want to set a mark
on a connection, I
nfct_set_attr_* all the necessary fields of struct nf_conntrack* and
then do
nfct_query(setmark_handle, NFCT_Q_GET, ct)
setmark_handle has a callback registered thusly:
if ((nfct_callback_register(setmark_handle, NFCT_T_ALL, setmark,
NULL) == -1)) {perror("cb_reg");}
So ct object lands here:
int setmark (enum nf_conntrack_msg_type type, struct nf_conntrack
*mct,void *data){
nfct_set_attr_u32(mct, ATTR_MARK, nfmark_to_set);
nfct_query(setmark_handle, NFCT_Q_UPDATE, mct); ***
return NFCT_CB_CONTINUE;
}
All works fine and dandy and i can see with "conntrack -L" marks being
set. At times I get EBUSY from nfct_query(...NFCT_Q_GET...) but I simply call nfct_query(...NFCT_Q_GET...) again and the query goes through.
Until at a seemingly random point, I start getting:
EILSEQ from nfct_query(...NFCT_Q_GET...) (Invalid or incomplete multibyte or wide
character). I don't resend this packet with nfct_query(...NFCT_Q_GET...), From then on every single nfct_query(...NFCT_Q_GET...) returns EILSEQ maybe for a 100 or so queries, until I finally get ENOBUFS and my app hangs.
Even calling "conntrack -L" at that point hangs - no output displayed
and prog doesn't return.
I hope that the line in the code above with *** is not the offending
one:NFCT_Q_UPDATE doesn't technically require a handle, yet the API says
it should be there, so I put the handle of this very callback.
Please let me know if there is any more info I could provide you with. I
am also willing to install conntrack_dbg package and investigate the
issue if need be.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
