All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amin Azez <azez@ufomechanic.net>
To: netfilter-devel@lists.netfilter.org
Subject: Re: ipt_ulog.h versus ebt_ulog.h
Date: Wed, 19 Oct 2005 10:41:58 +0100	[thread overview]
Message-ID: <435614E6.1080200@ufomechanic.net> (raw)
In-Reply-To: <dj519g$ke6$1@sea.gmane.org>

This becomes more important when I see that ebt_ulog and upt_ULOG
modules can't both be loaded into the kernel at the same time, and it
must be confusing for ULOG clients to have different structs passed
through depending whether ebtables or iptables sent the message.

Sam

Amin Azez wrote:
> Is there a strong reason why ebt_ulog.h log structure has
> 
>        char physindev[IFNAMSIZ];
>        char physoutdev[IFNAMSIZ];
> 
> and ipt_ulog.h structure does not support physdev?
> 
> Also interesting that ebt_ulog has
>        struct timeval stamp;
> 
> but ipt_ulog has
>        long timestamp_sec;
>        long timestamp_usec;
> 
> 
> I'd like to supply a patch to address these issues for kernel space and
> user-space ulog tools, but I am soliciting feedback first.
> 
> I think the first addition is more important than the second change.
> 
> As a general principle although ebt_* /ipt_* network layer associations
> exist, these exist for matching criteria and it seems a bit strong to
> assume that just because the selection critera for the -J ULOG target
> was impemented in ipt_* or ebt_* that the ULOG reader is not interested
> in the entire frame. I mean this only to justify the change. I do also
> realise the ulog is to some degree now depracated.
> 
> Sam
> 
> 
> 

  reply	other threads:[~2005-10-19  9:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-19  8:49 ipt_ulog.h versus ebt_ulog.h Amin Azez
2005-10-19  9:41 ` Amin Azez [this message]
2005-10-19 13:05   ` PATCH " Amin Azez
2005-10-19 13:10     ` Harald Welte
2005-10-21 12:42 ` Harald Welte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=435614E6.1080200@ufomechanic.net \
    --to=azez@ufomechanic.net \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.