[prev in list] [next in list] [prev in thread] [next in thread]
List: ulogd
Subject: Re: [ulogd] ulogd-1.00 segfault on rh9 WAS: ulogd 0.98 segfault on
From: Curtis Doty <Curtis () GreenKey ! net>
Date: 2003-04-26 21:40:52
[Download RAW message or body]
Yesterday Harald Welte said:
>On Wed, Apr 23, 2003 at 08:06:45AM -0700, Curtis Doty wrote:
>> Also, packets ULOG'd off the OUTPUT chain seem to be missing a proper
>> timestamp in the ulogd_PCAP output. Could this be a time.h related issue?
>
>please read the list archives and the docs for ulogd_LOCAL.so. This is
>not a bug, it is due to the architecture.
>
>How could a locally-generated packet have a skb receive timestamp? It
>never was received by any network interface.
Aha, I wasn't clear enough. I was referring to the PCAP output plugin
which does not make use of the LOCAL interpreter.
I dug deeper, and the PCAP plugin appears to test ULOGD_RETF_VALID but my
kernel is returning a valid (but bogus) timestamp in the skb. Find a
workaround attached.
Debian et al., the OPRINT plugin *will* make use of the LOCAL interpreter.
../C
["ulogd-notime.patch" (TEXT/PLAIN)]
Fix broken OUTPUT timestamping since apparently kernel inits the sk_buff
with a stamp.tv_sec of 0 and junk in stamp.tv_usec. Curtis@GreenKey.net
--- pcap/ulogd_PCAP.c.orig 2002-12-09 06:42:44.000000000 -0800
+++ pcap/ulogd_PCAP.c 2003-04-26 14:02:02.000000000 -0700
@@ -88,7 +88,8 @@
pchdr.len = GET_VALUE(2).ui32;
if (GET_FLAGS(3) & ULOGD_RETF_VALID
- && GET_FLAGS(4) & ULOGD_RETF_VALID) {
+ && GET_FLAGS(4) & ULOGD_RETF_VALID
+ && GET_VALUE(3).ui32 != 0) {
pchdr.ts.tv_sec = GET_VALUE(3).ui32;
pchdr.ts.tv_usec = GET_VALUE(4).ui32;
} else {
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic