I've just started playing with the ULOG target in
iptables, and I've noticed that the 'timestamp_sec'
member of the ulog_packet_msg_t struct paseed to
the user is always 0 for locally generated packets.
I was thinking of patching the ipt_ulog_target
function in net/ipv4/netfilter/ipt_ULOG.c to
check if timestamp_sec is 0 and if so, set it
to the current time by adding code to test
'timestamp_sec' after it's been set. E.g;
pm->timestamp_sec = (*pskb)->stamp.tv_sec;
pm->timestamp_usec = (*pskb)->stamp.tv_usec;
+ if ( pm->timestamp_sec == 0 ) {
+ pm->timestamp_sec = currrent time;
+ }
Any comments?
=====
I code, therefore I am
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
On Sun, Aug 24, 2003 at 07:16:00AM -0700, Alex Davis wrote:
> I've just started playing with the ULOG target in
> iptables, and I've noticed that the 'timestamp_sec'
> member of the ulog_packet_msg_t struct paseed to
> the user is always 0 for locally generated packets.
This is a well-known behaviour (see the list archives of
[email protected] or [email protected]).
This is _NOT_ considered a bug, but a feature.
> I was thinking of patching the ipt_ulog_target
> function in net/ipv4/netfilter/ipt_ULOG.c to
> check if timestamp_sec is 0 and if so, set it
> to the current time by adding code to test
> 'timestamp_sec' after it's been set. E.g;
so how would you then differentiate in userspace between
a) a skb receive timestamp
b) a timestamp created within the ULOG target (which can be very
different, think of async packets via QUEUE, etc.)
We definitely don't want to have one field in the packet that has
different semantics according from which hook it came in.
What ulogd currently does, is _always_ logging the userspace time,
disregarding the skb receive timestamp. This is way closer to the LOG
target behaviuor anyway, since in this case the time is prepended by
syslogd (which just calls gettimeofday() from userspace).
--
- Harald Welte <[email protected]> http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime
I understand. Thanks.
-Alex
--- Harald Welte <[email protected]> wrote:
> On Sun, Aug 24, 2003 at 07:16:00AM -0700, Alex Davis wrote:
> > I've just started playing with the ULOG target in
> > iptables, and I've noticed that the 'timestamp_sec'
> > member of the ulog_packet_msg_t struct paseed to
> > the user is always 0 for locally generated packets.
>
> This is a well-known behaviour (see the list archives of
> [email protected] or [email protected]).
>
> This is _NOT_ considered a bug, but a feature.
>
> > I was thinking of patching the ipt_ulog_target
> > function in net/ipv4/netfilter/ipt_ULOG.c to
> > check if timestamp_sec is 0 and if so, set it
> > to the current time by adding code to test
> > 'timestamp_sec' after it's been set. E.g;
>
> so how would you then differentiate in userspace between
>
> a) a skb receive timestamp
> b) a timestamp created within the ULOG target (which can be very
> different, think of async packets via QUEUE, etc.)
>
> We definitely don't want to have one field in the packet that has
> different semantics according from which hook it came in.
>
> What ulogd currently does, is _always_ logging the userspace time,
> disregarding the skb receive timestamp. This is way closer to the LOG
> target behaviuor anyway, since in this case the time is prepended by
> syslogd (which just calls gettimeofday() from userspace).
>
> --
> - Harald Welte <[email protected]> http://www.gnumonks.org/
> ============================================================================
> Programming is like sex: One mistake and you have to support it your lifetime
>
> ATTACHMENT part 2 application/pgp-signature
=====
I code, therefore I am
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com