All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.