nf-log update against latest 2.4-git
Subsystems (2)
PATCH 1/1 nf-log update against latest 2.4-git
Hello,
While updating my patchset I realised that the nf-log patch needed for the tcp window tracking feature does not properly apply anymore as-is.
So here is an updated version against the latest 2.4-git which should work also when 2.4.32 is released. It's compile tested.
Please consider applying,
Roberto Nibali, ratz
Signature · 6 lines
------------------------------------------------------------- addr://Kasinostrasse 30, CH-5001 Aarau tel://++41 62 823 9355 http://www.terreactive.com fax://++41 62 823 9356 ------------------------------------------------------------- terreActive AG Wir sichern Ihren Erfolg -------------------------------------------------------------
include/linux/netfilter_ipv4/ip_logging.h +20 -0
@@ -0,0 +1,20 @@ +/* IPv4 macros for the internal logging interface. */ +#ifndef __IP_LOGGING_H +#define __IP_LOGGING_H + +#ifdef __KERNEL__ +#include <linux/socket.h> +#include <linux/netfilter_logging.h> + +#define nf_log_ip_packet(pskb,hooknum,in,out,fmt,args...) \ + nf_log_packet(AF_INET,pskb,hooknum,in,out,fmt,##args) + +#define nf_log_ip(pfh,len,fmt,args...) \ + nf_log(AF_INET,pfh,len,fmt,##args) + +#define nf_ip_log_register (logging) nf_log_register(AF_INET,logging) +#define nf_ip_log_unregister (logging) nf_log_unregister(AF_INET,logging) + +#endif /*__KERNEL__*/ + +#endif /*__IP_LOGGING_H*/
include/linux/netfilter_ipv4/ipt_ULOG.h +3 -0
@@ -11,6 +11,9 @@#define NETLINK_NFLOG 5#endif +#define NFLOG_DEFAULT_NLGROUP 1 +#define NFLOG_DEFAULT_QTHRESHOLD 1 +#define ULOG_MAC_LEN 80#define ULOG_PREFIX_LEN 32
include/linux/netfilter_ipv6/ip6_logging.h +20 -0
@@ -0,0 +1,20 @@ +/* IPv6 macros for the nternal logging interface. */ +#ifndef __IP6_LOGGING_H +#define __IP6_LOGGING_H + +#ifdef __KERNEL__ +#include <linux/socket.h> +#include <linux/netfilter_logging.h> + +#define nf_log_ip6_packet(pskb,hooknum,in,out,fmt,args...) \ + nf_log_packet(AF_INET6,pskb,hooknum,in,out,fmt,##args) + +#define nf_log_ip6(pfh,len,fmt,args...) \ + nf_log(AF_INET6,pfh,len,fmt,##args) + +#define nf_ip6_log_register (logging) nf_log_register(AF_INET6,logging) +#define nf_ip6_log_unregister (logging) nf_log_unregister(AF_INET6,logging) + +#endif /*__KERNEL__*/ + +#endif /*__IP6_LOGGING_H*/
include/linux/netfilter_logging.h +33 -0
@@ -0,0 +1,33 @@ +/* Internal logging interface, which relies on the real +LOG target modules */ +#ifndef __LINUX_NETFILTER_LOGGING_H +#define __LINUX_NETFILTER_LOGGING_H + +#ifdef __KERNEL__ +#include <asm/atomic.h> + +struct nf_logging_t { +void (*nf_log_packet)(struct sk_buff **pskb, +unsigned int hooknum, +const struct net_device *in, +const struct net_device *out, +const char *prefix); +void (*nf_log)(char *pfh,size_t len, +const char *prefix); +}; + +extern void nf_log_register (int pf,const struct nf_logging_t *logging); +extern void nf_log_unregister (int pf,const struct nf_logging_t *logging); + +extern void nf_log_packet (int pf, +struct sk_buff **pskb, +unsigned int hooknum, +const struct net_device *in, +const struct net_device *out, +const char *fmt, ...); +extern void nf_log (int pf, +char *pfh,size_t len, +const char *fmt, ...); +#endif /*__KERNEL__*/ + +#endif /*__LINUX_NETFILTER_LOGGING_H*/
net/core/netfilter.c +72 -0
87 lines not on this page · raw message
net/ipv4/ipvs/ip_vs_conn.c +1 -1
@@ -246,7 +246,7 @@struct ip_vs_conn *ip_vs_ct_in_get (int protocol,__u32 s_addr,__u16 s_port,__u32 d_addr,__u16 d_port) { - unsigned hash: +unsigned hash;struct ip_vs_conn *cp; hash =ip_vs_conn_hashkey (protocol, s_addr, s_port);
net/ipv4/netfilter/ipt_LOG.c +67 -9
126 lines not on this page · raw message
net/ipv4/netfilter/ipt_ULOG.c +143 -11
214 lines not on this page · raw message
net/ipv6/netfilter/ip6t_LOG.c +41 -8
96 lines not on this page · raw message
net/netsyms.c +5 -0
@@ -594,6 +594,7 @@#endif #ifdef CONFIG_NETFILTER #include <linux/netfilter.h> +#include <linux/netfilter_logging.h> EXPORT_SYMBOL (nf_register_hook);EXPORT_SYMBOL (nf_unregister_hook);EXPORT_SYMBOL (nf_register_sockopt);
@@ -607,6 +608,10 @@EXPORT_SYMBOL (nf_getsockopt);EXPORT_SYMBOL (ip_ct_attach);EXPORT_SYMBOL (nf_ct_attach); +EXPORT_SYMBOL (nf_log_register); +EXPORT_SYMBOL (nf_log_unregister); +EXPORT_SYMBOL (nf_log_packet); +EXPORT_SYMBOL (nf_log);#ifdef CONFIG_INET #include <linux/netfilter_ipv4.h> EXPORT_SYMBOL (ip_route_me_harder);
Quoted 1 line · Roberto Nibali
Hello,
Hi Roberto!
Quoted 5 lines
While updating my patchset I realised that the nf-log patch needed for the tcp window tracking feature does not properly apply anymore as-is.
So here is an updated version against the latest 2.4-git which should work also when 2.4.32 is released. It's compile tested.
eek, a 2.4.x user ;)
Quoted 1 line
Please consider applying,
mh, we've recently decided not to officially support any other kernels than the latest released stable kernel (which is 2.6.14 now).
I know, we tried to be differernt for a long time, but most projects don't support 'new feature' patches for old kernel versions.
Soon we will be able have 'remote references' from patch-o-matic, so people can run their own repositories (like they can do now with apt, for example).
Signature · 5 lines
- 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
Hi Harald,
Summary in case you're short in time: I completely acknowledge and agree with your decision, but would still like to discuss a few issues regarding netfilter development in person.
Quoted 7 lines
Quoted 5 lines
While updating my patchset I realised that the nf-log patch needed for the tcp window tracking feature does not properly apply anymore as-is.
So here is an updated version against the latest 2.4-git which should work also when 2.4.32 is released. It's compile tested.
eek, a 2.4.x user ;)
We could go into a long argument as to why 2.6.x is not ready for use with our business cases, foremost it being too unstable API wise, along with a rather large list of things just not working 100% correctly yet.
But I think we should happily spare this list with this ;). I'd be inclined to state that there are far more 2.4.x nodes in productive environments (accounting for productivity per time unit, or adding to the revenue) than productive nodes in 2.6.x.
I'll be in Berlin between 27. Dec 2005, 22:25 and 30. Dec 2006 06:45. I'd be happy to have a meeting with you to discuss some netfilter issues, preferably in a quiet place at the CCC. Please contact me off-list if you're interested and have the time.
Quoted 4 lines
Quoted 1 line
Please consider applying,
mh, we've recently decided not to officially support any other kernels than the latest released stable kernel (which is 2.6.14 now).
I acknowledge that the netfilter core team has always been a bit short in supply of man-power, but always with excellent brain-power. It strikes me as particularly odd that the core netfilter code which should have been stable and mostly bug free has needed so much attention in the last couple of years (especially the 2.4.x kernel), depriving it somewhat of technical invention (opposed to now, where great effort is put into netlink related technology integration).
Obviously your team does not have the willingness nor time to further pursue in addressing 2.4.x kernel needs, which I understand. However I still hope to get some support in debugging my issues in the 2.4.x series regarding netfilter.
Quoted 2 lines
I know, we tried to be differernt for a long time, but most projects don't support 'new feature' patches for old kernel versions.
Indeed, in IPVS we also do not have backported several features from 2.6.x to 2.4.x although being available since 2.2.x series. This of course adds to the time needed to maintain two adjacent kernel trees, and in our case even yielded two user space branches ;(.
Quoted 3 lines
Soon we will be able have 'remote references' from patch-o-matic, so people can run their own repositories (like they can do now with apt, for example).
I will and must (as a company also in selling firewall services we a bound by the GPL) always put up my recent kernel patches, so nothing will be lost.
I quit my whining now :). Thanks for the heads-up and keep up the excellent work on state synchronisation, {ct,nf}netlink and x_tables.
Best regards,
Roberto Nibali, ratz
Signature · 2 lines
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc