Re: [PATCH] add new nfnetlink_log subsystem
* Harald Welte <[EMAIL PROTECTED]> 2005-08-07 17:03 > On Sun, Aug 07, 2005 at 01:20:39PM +0200, Thomas Graf wrote: > > Same very minor issues as nfnetlink regarding some of the > > new netlink message construction policies. I'll "fix" them > > during the conversion to the generic netlink attributes. > > is this supposed to happen soon? I also need to update the userspace > side in case you make any changes, so I'd appreciate any changes going > in ASAP. Alternatively just tell me what needs to change and I'll > change it even before the generalization. Within the next days. It is compatible to the old macros so as long as we don't delete the old ones userspace can stay as-is for the moment. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new nfnetlink_log subsystem
On Sun, Aug 07, 2005 at 01:20:39PM +0200, Thomas Graf wrote: > * Harald Welte <[EMAIL PROTECTED]> 2005-07-30 12:30 > > This (long-awaited) patch adds the generic nfnetlink-based userspace > > logging. nfnetlink_log can be used for any protocol family, and > > supports upt to 65535 logging groups (that could go to separate logging > > daemons, e.g.). > > Same very minor issues as nfnetlink regarding some of the > new netlink message construction policies. I'll "fix" them > during the conversion to the generic netlink attributes. is this supposed to happen soon? I also need to update the userspace side in case you make any changes, so I'd appreciate any changes going in ASAP. Alternatively just tell me what needs to change and I'll change it even before the generalization. thanks -- - Harald Welte <[EMAIL PROTECTED]> http://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 pgp1ev23kZFgq.pgp Description: PGP signature
Re: [PATCH] add new nfnetlink_log subsystem
* Harald Welte <[EMAIL PROTECTED]> 2005-07-30 12:30 > This (long-awaited) patch adds the generic nfnetlink-based userspace > logging. nfnetlink_log can be used for any protocol family, and > supports upt to 65535 logging groups (that could go to separate logging > daemons, e.g.). Same very minor issues as nfnetlink regarding some of the new netlink message construction policies. I'll "fix" them during the conversion to the generic netlink attributes. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new nfnetlink_log subsystem
On Thu, Aug 04, 2005 at 06:49:46AM -0700, David S. Miller wrote: > From: Harald Welte <[EMAIL PROTECTED]> > Date: Thu, 4 Aug 2005 00:03:53 +0200 > > > However, all nfnetlink-based protocols are supposed to be both endian > > and 32/64 as well as alignment (*) safe. the protocol definitions > > always use u_intXX_t types, all network byte order, and no kernel pointers > > passed to userspace or similar crap ;) > > You cannot use "u64" objects, even though that is supposed to > be a portable type. i386 does not align u64's on an 8-byte > boundary, whereas every sane platform in the world (including > x86_64) does. > > This is where the compatability problems come from. We only have one case where 64byte types are used: timestamps. the structure consists of two u_int64_t members - nothing before that and nothing behind (so no padding required). This structure (nfqnl_msg_packet_timestamp and nfulnl_msg_packet_timestamp) is put into one nfattr (like rtattr). Also, this data structure is only passed from kernel->userspace, and kernel will always be 64bit (who has more stringend alignment rules). Even if we chose to send it from userspace to kernel at some point in the future, it would be something that i386 userspace would have to take care of, not the kernel. Unless I'm overlooking something, to the best of my knowledge I don't think we could still run into any trouble here. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpFkxSoOM0qe.pgp Description: PGP signature
Re: [PATCH] add new nfnetlink_log subsystem
> Unless I'm overlooking something, to the best of my knowledge I don't > think we could still run into any trouble here. Still risky. Here's a different idea. Define a new aligned u64 type and use that on i386 too. Like /* Must be #define because __attribute__ doesn't work on typedefs */ #define __aligned_u64 unsigned long long __attribute__((aligned(8))) Then use __aligned_u64 instead of plain __u64 in all user visible parts. Should DTRT in all cases. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new nfnetlink_log subsystem
On Thu, Aug 04, 2005 at 06:50:42AM -0700, David S. Miller wrote: > From: Andi Kleen <[EMAIL PROTECTED]> > Subject: Re: [PATCH] add new nfnetlink_log subsystem > Date: Thu, 4 Aug 2005 00:19:41 +0200 > > > > no, it hasn't. I am travelling and don't have the space for a > > > debian/i386 installation in addition to the debian/x86_64 on this box, > > > sorry :( > > > > That sounds risky. I would ask for this stuff not being merged before > > it isn't tested. > > Andi, stop this, you yourself, can test and verify this and suggest > changes to the protocol structure layout if you want to. I understand Andi's reasons and they're perfectly valid. When I started to get involved with netfilter/iptables, I didn't know about the 32/64bit and alignment issues that exist in kernel/userspace interfaces at all. During the years however, I've suffered enough of this for the rest of my life. At this time I can assure him that greatest care was taken to not run into any endian, 32/64, alignment or other issues - at least to the degree of my (maybe limited) knowledge of this matter. I have scheduled testing over the next week, although it's a bit exhausting (and I'm too lazy) to test all the possible arch/endian/... combinations. > [...] more than ample time to do this, as this feature is > scheduled to go into 2.6.14 and we haven't even gotten 2.6.13 out > the door yet :-) ACK. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpwjezAPI6l1.pgp Description: PGP signature
Re: [PATCH] add new nfnetlink_log subsystem
On Thu, Aug 04, 2005 at 06:49:46AM -0700, David S. Miller wrote: > From: Harald Welte <[EMAIL PROTECTED]> > Date: Thu, 4 Aug 2005 00:03:53 +0200 > > > However, all nfnetlink-based protocols are supposed to be both endian > > and 32/64 as well as alignment (*) safe. the protocol definitions > > always use u_intXX_t types, all network byte order, and no kernel pointers > > passed to userspace or similar crap ;) > > You cannot use "u64" objects, even though that is supposed to > be a portable type. i386 does not align u64's on an 8-byte > boundary, whereas every sane platform in the world (including > x86_64) does. Well you can, just you need to make sure they are properly aligned by hand. And a more subtle issue is that structures are padded to a multiple of the largest alignment of any member. So when a structure has an u64 member it must be padded at the end to 8 bytes too. But this is all relatively subtle, so some review and some testing before fixing the interface would be good. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new nfnetlink_log subsystem
From: Andi Kleen <[EMAIL PROTECTED]> Subject: Re: [PATCH] add new nfnetlink_log subsystem Date: Thu, 4 Aug 2005 00:19:41 +0200 > > no, it hasn't. I am travelling and don't have the space for a > > debian/i386 installation in addition to the debian/x86_64 on this box, > > sorry :( > > That sounds risky. I would ask for this stuff not being merged before > it isn't tested. Andi, stop this, you yourself, can test and verify this and suggest changes to the protocol structure layout if you want to. You will have more than ample time to do this, as this feature is scheduled to go into 2.6.14 and we haven't even gotten 2.6.13 out the door yet :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new nfnetlink_log subsystem
From: Harald Welte <[EMAIL PROTECTED]> Date: Thu, 4 Aug 2005 00:03:53 +0200 > However, all nfnetlink-based protocols are supposed to be both endian > and 32/64 as well as alignment (*) safe. the protocol definitions > always use u_intXX_t types, all network byte order, and no kernel pointers > passed to userspace or similar crap ;) You cannot use "u64" objects, even though that is supposed to be a portable type. i386 does not align u64's on an 8-byte boundary, whereas every sane platform in the world (including x86_64) does. This is where the compatability problems come from. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new nfnetlink_log subsystem
> no, it hasn't. I am travelling and don't have the space for a > debian/i386 installation in addition to the debian/x86_64 on this box, > sorry :( That sounds risky. I would ask for this stuff not being merged before it isn't tested. > However, all nfnetlink-based protocols are supposed to be both endian > and 32/64 as well as alignment (*) safe. the protocol definitions Well, there is theory and there is practice. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new nfnetlink_log subsystem
On Wed, Aug 03, 2005 at 10:02:28PM +0200, Andi Kleen wrote: > Harald Welte <[EMAIL PROTECTED]> writes: > > > Hi Dave! > > > > This (long-awaited) patch adds the generic nfnetlink-based userspace > > logging. nfnetlink_log can be used for any protocol family, and > > supports upt to 65535 logging groups (that could go to separate logging > > daemons, e.g.). > > Hi - I hope it has been tested with 32bit userland on x86-64 already, right? no, it hasn't. I am travelling and don't have the space for a debian/i386 installation in addition to the debian/x86_64 on this box, sorry :( However, all nfnetlink-based protocols are supposed to be both endian and 32/64 as well as alignment (*) safe. the protocol definitions always use u_intXX_t types, all network byte order, and no kernel pointers passed to userspace or similar crap ;) So the only part in host byte order are the nlmsghdr and the nfattr (similar rtattr). We wanted to make it netwokr byte order, too - but then we would be different then all other netlink users :( so for now, we go for host byte order of Tag and Length, but network byte order value. This way a simple, generic program can parse the structure and convert everything to network byte order without having to know the content of the attributes. > Just to avoid another similar problem with non compat compatible structures > like old style iptables or PF_KEY. We've learned our lesson, thanks :) (*) I've been told there are 64bit alignment issues with netlink on x86_64 in general. Thomas Graf is somehow working on this, IIRC. I didn't investigate this. We do pass 64bit values in attributes between kernel and userspace. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpSgU81VJ4uZ.pgp Description: PGP signature
Re: [PATCH] add new nfnetlink_log subsystem
Harald Welte <[EMAIL PROTECTED]> writes: > Hi Dave! > > This (long-awaited) patch adds the generic nfnetlink-based userspace > logging. nfnetlink_log can be used for any protocol family, and > supports upt to 65535 logging groups (that could go to separate logging > daemons, e.g.). Hi - I hope it has been tested with 32bit userland on x86-64 already, right? Just to avoid another similar problem with non compat compatible structures like old style iptables or PF_KEY. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new nfnetlink_log subsystem
Hi Acme!
On Mon, Aug 01, 2005 at 09:54:47PM -0300, Arnaldo Carvalho de Melo wrote:
> > Are you aware of this one? :-) Perhaps Dave commited some mistake
> > while merging, this is on 2.6.14.git latest.
>
> Ah, this is with 'make allyesconfig'.
Dave's tree is missing the attached patch.
--
- Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[NETFILTER] Extend netfilter logging API
This patch is in preparation to nfnetlink_log:
- loggers now have to register struct nf_logger instead of nf_logfn
- nf_log_unregister() replaced by nf_log_unregister_pf() and
nf_log_unregister_logger()
- add comment to ip[6]t_LOG.h to assure nobody redefines flags
- add /proc/net/netfilter/nf_log to tell user which logger is currently
registered for which address family
- if user has configured logging, but no logging backend (logger) is
available, always spit a message to syslog, not just the first time.
- split ip[6]t_LOG.c into two parts:
Backend: Always try to register as logger for the respective address family
Frontend: Always log via nf_log_packet() API
- modify all users of nf_log_packet() to accomodate additional argument
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
---
commit 3770e25a01055bfa8bee52ed1db1f3a5141f
tree bb6232f07be1a0ec617f99d0e479964ac2d66119
parent 70715270f9cedc76099ed628b5444a11127912ca
author laforge <[EMAIL PROTECTED]> Do, 28 Jul 2005 21:27:14 +0200
committer laforge <[EMAIL PROTECTED]> Do, 28 Jul 2005 21:27:14 +0200
include/linux/netfilter.h| 48 +-
include/linux/netfilter_ipv4/ipt_LOG.h |1
include/linux/netfilter_ipv6/ip6t_LOG.h |1
net/core/netfilter.c | 127 +++---
net/ipv4/netfilter/ip_conntrack_proto_icmp.c |8 +-
net/ipv4/netfilter/ip_conntrack_proto_tcp.c | 21 ++--
net/ipv4/netfilter/ip_conntrack_proto_udp.c |6 +
net/ipv4/netfilter/ipt_LOG.c | 84 +
net/ipv4/netfilter/ipt_ULOG.c| 33 +--
net/ipv6/netfilter/ip6t_LOG.c| 91 ++-
10 files changed, 295 insertions(+), 125 deletions(-)
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -114,15 +114,51 @@ void nf_unregister_sockopt(struct nf_soc
extern struct list_head nf_hooks[NPROTO][NF_MAX_HOOKS];
-typedef void nf_logfn(unsigned int hooknum,
+/* those NF_LOG_* defines and struct nf_loginfo are legacy definitios that will
+ * disappear once iptables is replaced with pkttables. Please DO NOT use them
+ * for any new code! */
+#define NF_LOG_TCPSEQ 0x01/* Log TCP sequence numbers */
+#define NF_LOG_TCPOPT 0x02/* Log TCP options */
+#define NF_LOG_IPOPT 0x04/* Log IP options */
+#define NF_LOG_UID 0x08/* Log UID owning local socket */
+#define NF_LOG_MASK0x0f
+
+#define NF_LOG_TYPE_LOG0x01
+#define NF_LOG_TYPE_ULOG 0x02
+
+struct nf_loginfo {
+ u_int8_t type;
+ union {
+ struct {
+ u_int32_t copy_len;
+ u_int16_t group;
+ u_int16_t qthreshold;
+ } ulog;
+ struct {
+ u_int8_t level;
+ u_int8_t logflags;
+ } log;
+ } u;
+};
+
+typedef void nf_logfn(unsigned int pf,
+ unsigned int hooknum,
const struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
+ const struct nf_loginfo *li,
const char *prefix);
+struct nf_logger {
+ struct module *me;
+ nf_logfn*logfn;
+ char*name;
+};
+
/* Function to register/unregister log function. */
-int nf_log_register(int pf, nf_logfn *logfn);
-void nf_log_unregister(int pf, nf_logfn *logfn);
+int nf_log_register(int pf, struct nf_logger *logger);
+void nf_log_unregister_pf(int pf);
+void nf_log_unregister_logger(struct nf_logger *logger);
/* Calls the registered backend logging function */
void nf_log_packet(int pf,
@@ -130,6 +166,7 @@ void nf_log_packet(int pf,
const struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
+ struct nf_loginfo *li,
const char *fmt, ...);
/* Activate hook; either okfn or kfree_skb called, unless a hook
@@ -221,6 +258,11 @@ struct nf_queue_rerouter {
extern int nf_register_queue_rerouter(int pf, struct nf_queue_rerouter *rer);
exte
Re: [PATCH] add new nfnetlink_log subsystem
On Mon, Aug 01, 2005 at 09:54:47PM -0300, Arnaldo Carvalho de Melo wrote: > On 8/1/05, Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote: > > CC net/netfilter/nfnetlink_queue.o > > net/netfilter/nfnetlink_queue.c: In function `init_or_cleanup': > > net/netfilter/nfnetlink_queue.c:1030: error: `proc_net_netfilter' > > undeclared (first use in this function) > > net/netfilter/nfnetlink_queue.c:1030: error: (Each undeclared > > identifier is reported only once > > net/netfilter/nfnetlink_queue.c:1030: error: for each function it appears > > in.) > > make[2]: ** [net/netfilter/nfnetlink_queue.o] Erro 1 > > make[1]: ** [net/netfilter] Erro 2 > > make: ** [net/] Erro 2 > > [EMAIL PROTECTED] net-2.6.14]$ > > > > Are you aware of this one? :-) Perhaps Dave commited some mistake > > while merging, this is on 2.6.14.git latest. Yes, it's a problem in davem's tree. my tree (and the patches I sent) contain that directory. I'll try to send a cleanup. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpYKFooIFxK0.pgp Description: PGP signature
Re: [PATCH] add new nfnetlink_log subsystem
On 8/1/05, Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote: > CC net/netfilter/nfnetlink_queue.o > net/netfilter/nfnetlink_queue.c: In function `init_or_cleanup': > net/netfilter/nfnetlink_queue.c:1030: error: `proc_net_netfilter' > undeclared (first use in this function) > net/netfilter/nfnetlink_queue.c:1030: error: (Each undeclared > identifier is reported only once > net/netfilter/nfnetlink_queue.c:1030: error: for each function it appears in.) > make[2]: ** [net/netfilter/nfnetlink_queue.o] Erro 1 > make[1]: ** [net/netfilter] Erro 2 > make: ** [net/] Erro 2 > [EMAIL PROTECTED] net-2.6.14]$ > > Are you aware of this one? :-) Perhaps Dave commited some mistake while > merging, > this is on 2.6.14.git latest. Ah, this is with 'make allyesconfig'. - Arnaldo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new nfnetlink_log subsystem
CC net/netfilter/nfnetlink_queue.o net/netfilter/nfnetlink_queue.c: In function `init_or_cleanup': net/netfilter/nfnetlink_queue.c:1030: error: `proc_net_netfilter' undeclared (first use in this function) net/netfilter/nfnetlink_queue.c:1030: error: (Each undeclared identifier is reported only once net/netfilter/nfnetlink_queue.c:1030: error: for each function it appears in.) make[2]: ** [net/netfilter/nfnetlink_queue.o] Erro 1 make[1]: ** [net/netfilter] Erro 2 make: ** [net/] Erro 2 [EMAIL PROTECTED] net-2.6.14]$ Are you aware of this one? :-) Perhaps Dave commited some mistake while merging, this is on 2.6.14.git latest. - Arnaldo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new nfnetlink_log subsystem
From: Harald Welte <[EMAIL PROTECTED]> Date: Sat, 30 Jul 2005 19:33:15 +0200 > [NETFILTER] add proc_net_remove() to nfnetlink_queue and nfnetlink_log > > Also fixes a typo inside a comment. > Thanks to Sven Schuster <[EMAIL PROTECTED]> > > Signed-off-by: Harald Welte <[EMAIL PROTECTED]> Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new nfnetlink_log subsystem
Thanks for your comments, Sven.
Dave: Please apply the attached patch on top of all other patches I sent
you. It also fixes the same bug in nfnetlink_queue. Thanks!
--
- Harald Welte <[EMAIL PROTECTED]> http://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
[NETFILTER] add proc_net_remove() to nfnetlink_queue and nfnetlink_log
Also fixes a typo inside a comment.
Thanks to Sven Schuster <[EMAIL PROTECTED]>
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
---
commit a04a82e4fe4be531383909217bcb2d4ad096ecda
tree 1424e9d687c2b5217d82bcf04abb97a2f8aced69
parent bd4123d85f932f9bd60da9d2ed3523dc7b792075
author laforge <[EMAIL PROTECTED]> Sa, 30 Jul 2005 19:30:32 +0200
committer laforge <[EMAIL PROTECTED]> Sa, 30 Jul 2005 19:30:32 +0200
net/netfilter/nfnetlink_log.c |3 ++-
net/netfilter/nfnetlink_queue.c |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -314,7 +314,7 @@ static struct sk_buff *nfulnl_alloc_skb(
UDEBUG("entered (%u, %u)\n", inst_size, pkt_size);
- /* alloc skb whihc should be big enough for a whole multipart
+ /* alloc skb which should be big enough for a whole multipart
* message. WARNING: has to be <= 128k due to slab restrictions */
skb = alloc_skb(inst_size, GFP_ATOMIC);
@@ -965,6 +965,7 @@ init_or_cleanup(int init)
cleanup:
nf_log_unregister_logger(&nfulnl_logger);
#ifdef CONFIG_PROC_FS
+ remove_proc_entry("nfnetlink_log", proc_net_netfilter);
cleanup_subsys:
#endif
nfnetlink_subsys_unregister(&nfulnl_subsys);
diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c
--- a/net/netfilter/nfnetlink_queue.c
+++ b/net/netfilter/nfnetlink_queue.c
@@ -1041,6 +1041,7 @@ cleanup:
nf_unregister_queue_handlers(nfqnl_enqueue_packet);
unregister_netdevice_notifier(&nfqnl_dev_notifier);
#ifdef CONFIG_PROC_FS
+ remove_proc_entry("nfnetlink_queue", proc_net_netfilter);
cleanup_subsys:
#endif
nfnetlink_subsys_unregister(&nfqnl_subsys);
pgp82Pd51eRIV.pgp
Description: PGP signature
Re: [PATCH] add new nfnetlink_log subsystem
From: Harald Welte <[EMAIL PROTECTED]> Date: Sat, 30 Jul 2005 12:30:05 +0200 > This (long-awaited) patch adds the generic nfnetlink-based userspace > logging. nfnetlink_log can be used for any protocol family, and > supports upt to 65535 logging groups (that could go to separate logging > daemons, e.g.). > > The patch is incremental to my nf_log update in > <[EMAIL PROTECTED]>. Applied, thanks Harald. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new nfnetlink_log subsystem
Hi Harald,
On Sat, Jul 30, 2005 at 12:30:05PM +0200, Harald Welte told us:
> diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c
> new file mode 100644
> --- /dev/null
> +++ b/net/netfilter/nfnetlink_log.c
> @@ -0,0 +1,992 @@
...
> +static struct sk_buff *nfulnl_alloc_skb(unsigned int inst_size,
> + unsigned int pkt_size)
> +{
> + struct sk_buff *skb;
> +
> + UDEBUG("entered (%u, %u)\n", inst_size, pkt_size);
> +
> + /* alloc skb whihc should be big enough for a whole multipart
typo, which
> + * message. WARNING: has to be <= 128k due to slab restrictions */
> +
...
> +
> +static int
> +init_or_cleanup(int init)
> +{
...
> +#ifdef CONFIG_PROC_FS
> + proc_nful = create_proc_entry("nfnetlink_log", 0440,
> + proc_net_netfilter);
> + if (!proc_nful)
> + goto cleanup_subsys;
> + proc_nful->proc_fops = &nful_file_ops;
> +#endif
> +
> + return status;
> +
> +cleanup:
> + nf_log_unregister_logger(&nfulnl_logger);
> +#ifdef CONFIG_PROC_FS
> +cleanup_subsys:
no remove_proc_entry??
> +#endif
> + nfnetlink_subsys_unregister(&nfulnl_subsys);
> +cleanup_netlink_notifier:
> + netlink_unregister_notifier(&nfulnl_rtnl_notifier);
> + return status;
> +}
> +
Kind regards,
Sven
--
Linux zion 2.6.13-rc3-mm1 #17 PREEMPT Thu Jul 28 02:56:37 CEST 2005 i686 athlon
i386 GNU/Linux
18:34:22 up 19:35, 2 users, load average: 0.28, 0.11, 0.03
pgp9CYkcccjzu.pgp
Description: PGP signature
[PATCH] add new nfnetlink_log subsystem
Hi Dave!
This (long-awaited) patch adds the generic nfnetlink-based userspace
logging. nfnetlink_log can be used for any protocol family, and
supports upt to 65535 logging groups (that could go to separate logging
daemons, e.g.).
The patch is incremental to my nf_log update in
<[EMAIL PROTECTED]>.
Please apply to net-2.6.14,
thanks.
--
- Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[NETFILTER] Add new "nfnetlink_log" userspace packet logging facility
This is a generic (layer3 independent) version of what ipt_ULOG is already
doing for IPv4 today. ipt_ULOG, ebt_ulog and finally also ip[6]t_LOG will
be deprecated by this mechanism in the long term.
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
---
commit 66ad9b079da5c6a181506fba350aa33d26417431
tree 4b4bda3788bf34d1946ff0239100a4f235cfa120
parent 3770e25a01055bfa8bee52ed1db1f3a5141f
author laforge <[EMAIL PROTECTED]> Sa, 30 Jul 2005 12:11:19 +0200
committer laforge <[EMAIL PROTECTED]> Sa, 30 Jul 2005 12:11:19 +0200
include/linux/netfilter/nfnetlink_log.h | 85 +++
net/netfilter/Kconfig | 11
net/netfilter/Makefile |1
net/netfilter/nfnetlink_log.c | 992 +++
4 files changed, 1089 insertions(+), 0 deletions(-)
diff --git a/include/linux/netfilter/nfnetlink_log.h
b/include/linux/netfilter/nfnetlink_log.h
new file mode 100644
--- /dev/null
+++ b/include/linux/netfilter/nfnetlink_log.h
@@ -0,0 +1,85 @@
+#ifndef _NFNETLINK_LOG_H
+#define _NFNETLINK_LOG_H
+
+/* This file describes the netlink messages (i.e. 'protocol packets'),
+ * and not any kind of function definitions. It is shared between kernel and
+ * userspace. Don't put kernel specific stuff in here */
+
+#include
+
+enum nfulnl_msg_types {
+ NFULNL_MSG_PACKET, /* packet from kernel to userspace */
+ NFULNL_MSG_CONFIG, /* connect to a particular queue */
+
+ NFULNL_MSG_MAX
+};
+
+struct nfulnl_msg_packet_hdr {
+ u_int16_t hw_protocol;/* hw protocol (network order) */
+ u_int8_thook; /* netfilter hook */
+ u_int8_t_pad;
+} __attribute__ ((packed));
+
+struct nfulnl_msg_packet_hw {
+ u_int16_t hw_addrlen;
+ u_int16_t _pad;
+ u_int8_thw_addr[8];
+} __attribute__ ((packed));
+
+struct nfulnl_msg_packet_timestamp {
+ u_int64_t sec;
+ u_int64_t usec;
+} __attribute__ ((packed));
+
+#define NFULNL_PREFIXLEN 30 /* just like old log target */
+
+enum nfulnl_attr_type {
+ NFULA_UNSPEC,
+ NFULA_PACKET_HDR,
+ NFULA_MARK, /* u_int32_t nfmark */
+ NFULA_TIMESTAMP,/* nfulnl_msg_packet_timestamp */
+ NFULA_IFINDEX_INDEV,/* u_int32_t ifindex */
+ NFULA_IFINDEX_OUTDEV, /* u_int32_t ifindex */
+ NFULA_HWADDR, /* nfulnl_msg_packet_hw */
+ NFULA_PAYLOAD, /* opaque data payload */
+ NFULA_PREFIX, /* string prefix */
+ NFULA_UID, /* user id of socket */
+
+ __NFULA_MAX
+};
+#define NFULA_MAX (__NFULA_MAX - 1)
+
+enum nfulnl_msg_config_cmds {
+ NFULNL_CFG_CMD_NONE,
+ NFULNL_CFG_CMD_BIND,
+ NFULNL_CFG_CMD_UNBIND,
+ NFULNL_CFG_CMD_PF_BIND,
+ NFULNL_CFG_CMD_PF_UNBIND,
+};
+
+struct nfulnl_msg_config_cmd {
+ u_int8_tcommand;/* nfulnl_msg_config_cmds */
+} __attribute__ ((packed));
+
+struct nfulnl_msg_config_mode {
+ u_int32_t copy_range;
+ u_int8_tcopy_mode;
+ u_int8_t_pad;
+} __attribute__ ((packed));
+
+enum nfulnl_attr_config {
+ NFULA_CFG_UNSPEC,
+ NFULA_CFG_CMD, /* nfulnl_msg_config_cmd */
+ NFULA_CFG_MODE, /* nfulnl_msg_config_mode */
+ NFULA_CFG_NLBUFSIZ, /* u_int32_t buffer size */
+ NFULA_CFG_TIMEOUT, /* u_int32_t in 1/100 s */
+ NFULA_CFG_QTHRESH, /* u_int32_t */
+ __NFULA_CFG_MAX
+};
+#define NFULA_CFG_MAX (__NFULA_CFG_MAX -1)
+
+#define NFULNL_COPY_NONE 0x00
+#define NFULNL_COPY_META 0x01
+#define NFULNL_COPY_PACKET 0x02
+
+#endif /* _NFNETLINK_LOG_H */
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -11,3 +11,14 @@ config NETFILTER_NETLINK_QUEUE
If this option isenabled, the kernel will include support
for queueing packets via NFNETLINK.
+config NETFILTER_NETLINK_LOG
+ tristate "Netfilter LOG over NFNETLINK interface"
+ depends on NETFILTER_NETLINK
+ help
+
