All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paweł Sikora" <pluto@agmk.net>
To: Pablo Neira <pablo@eurodev.net>
Cc: Netfilter Development Mailinglist <netfilter-devel@lists.netfilter.org>
Subject: Re: problems with libnetfilter_conntrack / cntl_test
Date: Wed, 16 Nov 2005 18:09:24 +0100	[thread overview]
Message-ID: <200511161809.25277.pluto@agmk.net> (raw)
In-Reply-To: <437B53E9.2080800@eurodev.net>

Dnia środa, 16 listopada 2005 16:44, napisałeś:
> Pawel Sikora wrote:
> > I have installed a 2.6.14.2 kernel + grsecurity-2.1.7-2.6.14.2-$latest,
> > libnfnetlink-0.0.13 and libnetfilter_conntrack-0.0.28.
> >
> > ./ctnl_test fails:
> >
> > Test for libnetfilter_conntrack
> >
> > NFNETLINK answers: Invalid argument
> > TEST 1: create conntrack (-22)
> > TEST 2: dump conntrack table and reset (-22)
> > TEST 3: dump conntrack table (-22)
> > TEST 4: get conntrack (-22)
> > TEST 5: update conntrack (-22)
> > NFNETLINK answers: Invalid argument
> > TEST 6: delete conntrack (-22)
> > nfnl_open: bind(netlink): Operation not permitted
> > Can't open handler
> > Test failed with error -2. Errors=7
> >
> > Is this a grsec issue?
>
> Hard to say, my last contact with grsec was years ago. That output is
> kind of weird. Could you try reverting the grsec patch?

currently I get the same error on 2.6.14.2 without grsec on root account.
first failure occurs at first call of nfnl_talk().

Breakpoint 2, nfnl_talk (nfnlh=0x804b0b0, n=0xbfcb2680, peer=0, groups=0, 
answer=0x0, junk=0, jarg=0x0)
    at libnfnetlink.c:384
384             struct iovec iov = {

(gdb) bt
#0  nfnl_talk (nfnlh=0x804b0b0, n=0xbfcb2680, peer=0, groups=0, answer=0x0,
              junk=0, jarg=0x0)
    at libnfnetlink.c:384
#1  0xb7f84072 in nfct_create_conntrack (cth=0x804b0b0, ct=0x804b008)
    at libnetfilter_conntrack.c:800
#2  0x08048b89 in main (argc=1, argv=0xbfcb3804)
    at ctnl_test.c:85

(gdb) p *nfnlh
$1 = {fd = 6, local = {nl_family = 16, nl_pad = 0, nl_pid = 5330, nl_groups = 
0}, peer = {nl_family = 16,
    nl_pad = 0, nl_pid = 0, nl_groups = 0}, subsys_id = 1 '\001', seq = 
1132160442, dump = 0,
  last_nlhdr = 0x0, cb_count = 4 '\004', cb = 0x804b0f8}

(gdb) p *n
$2 = {nlmsg_len = 156, nlmsg_type = 256, nlmsg_flags = 1541, nlmsg_seq = 
1132160442, nlmsg_pid = 0}

(gdb) s
387             struct msghdr msg = {
(gdb)
394             memset(&nladdr, 0, sizeof(nladdr));
(gdb)
395             nladdr.nl_family = AF_NETLINK;
(gdb)
396             nladdr.nl_pid = peer;
(gdb)
397             nladdr.nl_groups = groups;
(gdb)
399             n->nlmsg_seq = seq = ++nfnlh->seq;
(gdb)
401             if (!answer)
(gdb)
402                     n->nlmsg_flags |= NLM_F_ACK;
(gdb)
404             status = sendmsg(nfnlh->fd, &msg, 0);
(gdb) p msg
$3 = {msg_name = 0xbfcb0630, msg_namelen = 12, msg_iov = 0xbfcb0618, 
msg_iovlen = 1, msg_control = 0x0,
  msg_controllen = 0, msg_flags = 0}
(gdb) s
405             if (status < 0) {
(gdb)
409             iov.iov_base = buf;
(gdb)
410             iov.iov_len = sizeof(buf);
(gdb)
413                     status = recvmsg(nfnlh->fd, &msg, 0);
(gdb)
414                     if (status < 0) {
(gdb) p status
$4 = 36
(gdb) s
420                     if (status == 0) {
(gdb)
424                     if (msg.msg_namelen != sizeof(nladdr)) {
(gdb)
430                     for (h = (struct nlmsghdr *)buf; status >= 
sizeof(*h); ) {
(gdb)
431                             int len = h->nlmsg_len;
(gdb)
432                             int l = len - sizeof(*h);
(gdb)
435                             if (l < 0 || len > status) {
(gdb)
444                             if (h->nlmsg_pid != nfnlh->local.nl_pid ||
(gdb)
454                             if (h->nlmsg_type == NLMSG_ERROR) {
(gdb)
455                                     struct nlmsgerr *err = NLMSG_DATA(h);
(gdb) p *h
$5 = {nlmsg_len = 36, nlmsg_type = 2, nlmsg_flags = 0, nlmsg_seq = 1132160443, 
nlmsg_pid = 5330}


I can provide more info if you need.

BR,

-- 
The only thing necessary for the triumph of evil
  is for good men to do nothing.
                                           - Edmund Burke

  reply	other threads:[~2005-11-16 17:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-16 13:39 problems with libnetfilter_conntrack / cntl_test Paweł Sikora
2005-11-16 15:44 ` Pablo Neira
2005-11-16 17:09   ` Paweł Sikora [this message]
2005-11-17  1:38     ` Pablo Neira
2005-11-17  3:21       ` Paweł Sikora
2005-11-17 12:49         ` Harald Welte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200511161809.25277.pluto@agmk.net \
    --to=pluto@agmk.net \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=pablo@eurodev.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.