[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