* Is this an ULOG error? @ 2005-02-01 6:28 serjio 2005-02-01 13:46 ` Harald Welte 0 siblings, 1 reply; 3+ messages in thread From: serjio @ 2005-02-01 6:28 UTC (permalink / raw) To: netfilter-devel Hello All, I would like to use ULOG and ULOGD for traffic accounting. But after I have installed these tools on my router I was surprised that I cannot check my traffic with 100% accuracy. I tested this by using a standart iptables counters. And there was always much more bytes than I got in ulogd. In addition to this I see that ulogd logfile is flooded by messages like this: ulogd.c:707 ipulog_read == -1! ipulog_errno == 6, errno = 105 strerr=No buffer space available I think that there are some problems in transmit data via kernel socket to userspace. Changing a socket network buffer size up to 4M didn't help me. sysctl -w net.core.rmem_max=8388608 sysctl -w net.core.rmem_default=4194304 sysctl -w net.core.wmem_max=8388608 sysctl -w net.core.wmem_default=4194304 I would be grateful if anyone can help me. Thanks, Sergei ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Is this an ULOG error? 2005-02-01 6:28 Is this an ULOG error? serjio @ 2005-02-01 13:46 ` Harald Welte 2005-02-02 9:30 ` serjio 0 siblings, 1 reply; 3+ messages in thread From: Harald Welte @ 2005-02-01 13:46 UTC (permalink / raw) To: serjio; +Cc: netfilter-devel [-- Attachment #1: Type: text/plain, Size: 1379 bytes --] On Tue, Feb 01, 2005 at 11:28:24AM +0500, serjio wrote: > Hello All, > > I would like to use ULOG and ULOGD for traffic accounting. This is not what ULOG is meant for. > But after I have installed these tools on my router I was surprised > that I cannot check my traffic with 100% accuracy. Please give more information, such as exact kernel version, exact ulogd version, any patches you might be using, ... > I think that there are some problems in transmit data via kernel socket > to userspace. probably. even if your buffers are large enough - if the system forwards more packets than it is able to ULOG, then you will have holes in your logs. ULOG is best-effort. > Changing a socket network buffer size up to 4M didn't help me. > sysctl -w net.core.rmem_max=8388608 > sysctl -w net.core.rmem_default=4194304 > sysctl -w net.core.wmem_max=8388608 > sysctl -w net.core.wmem_default=4194304 there are multiple buffers involved, please see the ulogd documentation. -- - Harald Welte <laforge@netfilter.org> http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Is this an ULOG error? 2005-02-01 13:46 ` Harald Welte @ 2005-02-02 9:30 ` serjio 0 siblings, 0 replies; 3+ messages in thread From: serjio @ 2005-02-02 9:30 UTC (permalink / raw) To: Harald Welte; +Cc: netfilter-devel Hello Harald, >>I would like to use ULOG and ULOGD for traffic accounting. >> >> > >This is not what ULOG is meant for.But after I have installed these tools on my router I was surprised >that I cannot check my traffic with 100% accuracy. > > > >Please give more information, such as exact kernel version, exact ulogd >version, any patches you might be using, ... > > Please look at the below description of what I am using: kernel 2.6.2-rc3 ulogd ver 1.02 CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz RAM: 256M Network loading is about 500K per sec. We are ISP and using this server as our primary shaper. I found this problem when I used a fresh 2.6.10 kernel without any patches as well. >>I think that there are some problems in transmit data via kernel socket >>to userspace. >> >> > >probably. even if your buffers are large enough - if the system >forwards more packets than it is able to ULOG, then you will have holes >in your logs. ULOG is best-effort. > > > I added to the ipt_ULOG.c file some debug information just after netlink_broadcast function. ret = netlink_broadcast(nflognl, ub->skb, 0, (1 << nlgroupnum), GFP_ATOMIC); if(ret!=0){ PRINTR("%s\n throwing %d packets","ipt_ULOG:netlink_broadcast error",ub->qlen); }; And I didn't get any errors from this function. So for my mind information is lost somewhere in the way between ulog kernel module and ulogd daemon. What do you think if I will change ULOG module so it will send data via proc fs? Can it solve a problem with lost data? >>Changing a socket network buffer size up to 4M didn't help me. >> >>sysctl -w net.core.rmem_max=8388608 >> >> >>sysctl -w net.core.rmem_default=4194304 >>sysctl -w net.core.wmem_max=8388608 >>sysctl -w net.core.wmem_default=4194304 >> >> > >there are multiple buffers involved, please see the ulogd documentation. > > Unfortunatelly I didn't find any related. There is only one place in the ulogd daemon when ulogd is receiving a data from ulog. Look at the below code: libipulog.c:81 status = recvfrom(h->fd, buf, len, 0, (struct sockaddr *)&h->peer,&addrlen); How I can trace this way between call netlink_broadcast function and recvfrom in the ulogd daemon? I would be grateful for any suggestions, information links or hints etc. Thanks, Sergei Filippov ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-02-02 9:30 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-02-01 6:28 Is this an ULOG error? serjio 2005-02-01 13:46 ` Harald Welte 2005-02-02 9:30 ` serjio
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.