Call for testing: patch-o-matic-ng

Call for testing: patch-o-matic-ng

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

Hi!

I've now gotten patch-o-matic-ng to a state where it is actually quite
useable.  

Everybody interested can check it out from CVS
(netfilter/patch-o-matic-ng).  Everything should look exactly like the
old patch-o-matic, including screen output and command syntax.

However, the implementation behind the curtain is completely different.
Interested people are invited to look into the perl source of
Netfilter_POM.pm and 'runme'.

I would like to have people start testing/using pom-ng and report errors
back to me (via email).

The differences from a user's point of view:

- dependencies are resolved recursively
- verbose error reporting
- new, more verbose './runme --man' documentation
- if you want to apply a specific set of patches, don't prefix them
  with the repository name (i.e. use
  	./runme pptp-conntrack-nat
  instead of
  	./runme extra/pptp-conntrack-nat

The differences from a developer's point of view:

- support for requirements (i.e. kernel >= 2.4.22)
- recursive dependencies
- support for multiple kernel build systems (i.e. 2.4.x and 2.6.x)
- automatic creation of Configure.help entries / Kconfig help sections
  from the patches 'help' file
- no wholefile-patches in CVS.  This means that entirely new files like
  net/ipv4/netfilter/ipt_foo.c / ipt_foo.h are not stored as patches but
  rather in their original form.   This in turn means real version
  control on the sourcecode!
- backend seperated from frontend (i.e. other user frontends could be
  implemented
- not limited to the linux sourcecode.  It is easy to add support for
  other projects (if a patchlet would have to patch other software, too)

However, some stuff is still missing (see the patch-o-matic/TODO file).
I'm working on implementing those missing features, though.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Call for testing: patch-o-matic-ng

[KOVACS Krisztian]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]


  Hi,

2003-12-21, v keltezéssel 13:24-kor Harald Welte ezt írta:
> I would like to have people start testing/using pom-ng and report errors
> back to me (via email).

  I've tried it, and had some problems with it. Namely, the following
error message (Debian woody and sid, perl 5.6.1 and 5.8.2):

hidden@big:~/patch-o-matic-ng$ ./runme 
Examining kernel in /usr/src/linux-2.4.22-tproxy113
Can't bless non-reference value at /usr/share/perl/5.6.1/Term/Cap.pm line 136.

  The patch attached fixed the problem.

-- 
 Regards,
   Krisztian KOVACS

[-- Attachment #2: tgetent.diff --]
[-- Type: text/x-patch, Size: 434 bytes --]

Index: runme
===================================================================
RCS file: /cvspublic/netfilter/patch-o-matic-ng/runme,v
retrieving revision 1.7
diff -u -r1.7 runme
--- runme	21 Dec 2003 19:03:23 -0000	1.7
+++ runme	22 Dec 2003 09:47:15 -0000
@@ -201,7 +201,7 @@
 }
 
 if (defined($ENV{TERM})) {
-	my $terminal = Term::Cap->Tgetent();
+	my $terminal = Tgetent Term::Cap {};
 	$clrscr = $terminal->Tputs('cl', 1);
 }
 

Re: Call for testing: patch-o-matic-ng

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

On Mon, Dec 22, 2003 at 10:56:26AM +0100, KOVACS Krisztian wrote:
>   I've tried it, and had some problems with it. Namely, the following
> error message (Debian woody and sid, perl 5.6.1 and 5.8.2):
> 
> hidden@big:~/patch-o-matic-ng$ ./runme 
> Examining kernel in /usr/src/linux-2.4.22-tproxy113
> Can't bless non-reference value at /usr/share/perl/5.6.1/Term/Cap.pm line 136.

thanks, I'll apply your fix.

>  Regards,
>    Krisztian KOVACS

-- 
- Harald Welte <laforge@netfilter.org>             http://www.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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Call for testing: patch-o-matic-ng (condition filter)

[Tim Gardner]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

Harald,

The condition filter (at least for 2.6) has extra files:

condition/linux/net/ipv6/Makefile.ladd
condition/linux/net/ipv6/Config.in.ladd

The presense of Makefile.ladd will not allow the filter to be applied. I 
suspect Config.in.ladd will cause a similar problem for 2.4.

Attached is a patch that removes these files as well as patches 
ipt_condition.c for 2.6.

ipv6/netfilter/ipt_condition.c compiles with warnings. Since I'm not using it 
(and I'm basically lazy), I'll leave it up to the authors to make it correct 
for 2.6

rtg
-- 
Tim Gardner - timg@tpi.com
www.tpi.com 406-443-5357

[-- Attachment #2: condition.diffs --]
[-- Type: text/x-diff, Size: 2285 bytes --]

diff -r -u --new-file netfilter/patch-o-matic-ng/condition/linux/net/ipv4/netfilter/ipt_condition.c netfilter.wrk/patch-o-matic-ng/condition/linux/net/ipv4/netfilter/ipt_condition.c
--- netfilter/patch-o-matic-ng/condition/linux/net/ipv4/netfilter/ipt_condition.c	2003-12-18 11:47:55.000000000 -0700
+++ netfilter.wrk/patch-o-matic-ng/condition/linux/net/ipv4/netfilter/ipt_condition.c	2003-12-23 07:45:30.000000000 -0700
@@ -17,6 +17,7 @@
 \*-------------------------------------------*/
 
 #include<linux/module.h>
+#include <linux/version.h>
 #include<linux/proc_fs.h>
 #include<linux/spinlock.h>
 #include<linux/string.h>
@@ -90,9 +91,17 @@
 
 
 static int
-match(const struct sk_buff *skb, const struct net_device *in,
-      const struct net_device *out, const void *matchinfo, int offset,
-      const void *hdr, u_int16_t datalen, int *hotdrop)
+match(
+	const struct sk_buff *skb,
+	const struct net_device *in,
+	const struct net_device *out,
+	const void *matchinfo,
+	int offset,
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)
+	const void *hdr,
+	u_int16_t datalen,
+#endif
+	int *hotdrop)
 {
 	const struct condition_info *info =
 	    (const struct condition_info *) matchinfo;
diff -r -u --new-file netfilter/patch-o-matic-ng/condition/linux/net/ipv6/Config.in.ladd netfilter.wrk/patch-o-matic-ng/condition/linux/net/ipv6/Config.in.ladd
--- netfilter/patch-o-matic-ng/condition/linux/net/ipv6/Config.in.ladd	2003-12-20 09:38:19.000000000 -0700
+++ netfilter.wrk/patch-o-matic-ng/condition/linux/net/ipv6/Config.in.ladd	1969-12-31 17:00:00.000000000 -0700
@@ -1,2 +0,0 @@
-  dep_tristate '  MAC address match support' CONFIG_IP6_NF_MATCH_MAC $CONFIG_IP6_NF_IPTABLES
-  dep_tristate '  Condition variable match support' CONFIG_IP6_NF_MATCH_CONDITION $CONFIG_IP6_NF_IPTABLES
diff -r -u --new-file netfilter/patch-o-matic-ng/condition/linux/net/ipv6/Makefile.ladd netfilter.wrk/patch-o-matic-ng/condition/linux/net/ipv6/Makefile.ladd
--- netfilter/patch-o-matic-ng/condition/linux/net/ipv6/Makefile.ladd	2003-12-20 09:38:19.000000000 -0700
+++ netfilter.wrk/patch-o-matic-ng/condition/linux/net/ipv6/Makefile.ladd	1969-12-31 17:00:00.000000000 -0700
@@ -1,2 +0,0 @@
-obj-$(CONFIG_IP6_NF_MATCH_MARK) += ip6t_mark.o
-obj-$(CONFIG_IP6_NF_MATCH_CONDITION) += ip6t_condition.o

Re: Call for testing: patch-o-matic-ng (fuzzy filter)

[Tim Gardner]

[-- Attachment #1: Type: text/plain, Size: 136 bytes --]

Harald,

Attached is a patch file that corrects ipt_fuzzy.c for 2.6.

rtg
-- 
Tim Gardner - timg@tpi.com
www.tpi.com 406-443-5357

[-- Attachment #2: fuzzy.diff --]
[-- Type: text/x-diff, Size: 816 bytes --]

diff -r -u --new-file netfilter/patch-o-matic-ng/fuzzy/linux/net/ipv4/netfilter/ipt_fuzzy.c netfilter.wrk/patch-o-matic-ng/fuzzy/linux/net/ipv4/netfilter/ipt_fuzzy.c
--- netfilter/patch-o-matic-ng/fuzzy/linux/net/ipv4/netfilter/ipt_fuzzy.c	2003-12-18 11:15:29.000000000 -0700
+++ netfilter.wrk/patch-o-matic-ng/fuzzy/linux/net/ipv4/netfilter/ipt_fuzzy.c	2003-12-23 08:07:52.000000000 -0700
@@ -17,6 +17,7 @@
 */
 
 #include <linux/module.h>
+#include <linux/version.h>
 #include <linux/skbuff.h>
 #include <linux/ip.h>
 #include <linux/random.h>
@@ -64,8 +65,10 @@
 	       const struct net_device *out,
 	       const void *matchinfo,
 	       int offset,
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)
 	       const void *hdr,
 	       u_int16_t datalen,
+#endif
 	       int *hotdrop)
 {
 	/* From userspace */

Re: Call for testing: patch-o-matic-ng (condition filter)

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Tue, Dec 23, 2003 at 07:57:23AM -0700, Tim Gardner wrote:
> Harald,
> 
> The condition filter (at least for 2.6) has extra files:
> 
> condition/linux/net/ipv6/Makefile.ladd
> condition/linux/net/ipv6/Config.in.ladd
> 
> The presense of Makefile.ladd will not allow the filter to be applied. I 
> suspect Config.in.ladd will cause a similar problem for 2.4.

thanks a lot, I'm removing them from CVS right now.

> Attached is a patch that removes these files as well as patches 
> ipt_condition.c for 2.6.

we'd need lots of fixes like this one.  Are there any volunteers for submitting patches like this and making sure that 2.4.x and 2.6.x compile ok ?

> Tim Gardner - timg@tpi.com
-- 
- Harald Welte <laforge@netfilter.org>             http://www.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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Call for testing: patch-o-matic-ng

[Gaël Le Mignot]

Hello,

I've tested pom-ng on 2.6.0  with USAGI patch, the patch-o-matic seems
to work, but the kernel doesn't compile (I put nearly all patches, and
select M in the kernel config wherever it was possible):

  CC      net/core/netfilter.o
net/core/netfilter.c: In function `nf_log_register':
net/core/netfilter.c:760: warning: implicit declaration of function `br_write_lock_bh'
net/core/netfilter.c:760: error: `BR_NETPROTO_LOCK' undeclared (first use in this function)
net/core/netfilter.c:760: error: (Each undeclared identifier is reported only once
net/core/netfilter.c:760: error: for each function it appears in.)
net/core/netfilter.c:765: warning: implicit declaration of function `br_write_unlock_bh'
net/core/netfilter.c: In function `nf_log_unregister':
net/core/netfilter.c:770: error: `BR_NETPROTO_LOCK' undeclared (first use in this function)
make[3]: *** [net/core/netfilter.o] Error 1


I think maybe some patches doesn't work with 2.6, would it possible to
add a way to select patch that works with 2.6 ? like ./runme extra-2.6
or such ?

-- 
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM         : 06.71.47.18.22 (in France)   ICQ UIN   : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA

Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org

Re: Call for testing: patch-o-matic-ng

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]

On Tue, Dec 23, 2003 at 02:13:15PM +0100, Gaël Le Mignot wrote:
> I've tested pom-ng on 2.6.0  with USAGI patch, the patch-o-matic seems
> to work, but the kernel doesn't compile (I put nearly all patches, and
> select M in the kernel config wherever it was possible):
> 
>   CC      net/core/netfilter.o
> net/core/netfilter.c: In function `nf_log_register':
> net/core/netfilter.c:760: warning: implicit declaration of function `br_write_lock_bh'
> net/core/netfilter.c:760: error: `BR_NETPROTO_LOCK' undeclared (first use in this function)
> net/core/netfilter.c:760: error: (Each undeclared identifier is reported only once
> net/core/netfilter.c:760: error: for each function it appears in.)
> net/core/netfilter.c:765: warning: implicit declaration of function `br_write_unlock_bh'
> net/core/netfilter.c: In function `nf_log_unregister':
> net/core/netfilter.c:770: error: `BR_NETPROTO_LOCK' undeclared (first use in this function)
> make[3]: *** [net/core/netfilter.o] Error 1
> 
> 
> I think maybe some patches doesn't work with 2.6, would it possible to
> add a way to select patch that works with 2.6 ? like ./runme extra-2.6
> or such ?

yes, indeed.  There are numerous patches that would not work in the
2.6.x kernels.  They have yet to be identified.  Once they are
identified, we can put a special "requires" tag into the 'info' file of
those patches.

This way the 2.4 only patches would only be offered if you have a 2.4.x
kernel source (and vice-versa).

You could help us in finding out which patches compile and which ones
don't.

> -- 
> Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr

-- 
- Harald Welte <laforge@netfilter.org>             http://www.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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Call for testing: patch-o-matic-ng

[Unknown, Alistair Tonner]

On December 23, 2003 12:30 pm, Harald Welte wrote:
> On Tue, Dec 23, 2003 at 02:13:15PM +0100, Gaël Le Mignot wrote:

<< much snippage >>
	
> yes, indeed.  There are numerous patches that would not work in the
> 2.6.x kernels.  They have yet to be identified.  Once they are
> identified, we can put a special "requires" tag into the 'info' file of
> those patches.
>
> This way the 2.4 only patches would only be offered if you have a 2.4.x
> kernel source (and vice-versa).
>
> You could help us in finding out which patches compile and which ones
> don't.
	Oh my ... more work for the weekend ... I'll go grab POM-ng shortly ... 
	(I'm building 2.6.0 kernel on a test basis at the moment)


> > --
> > Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr

Re: Call for testing: patch-o-matic-ng

[Gaël Le Mignot]

Hello Harald, hello netfiler list ;)

I did  some tests on which  patch from the patch-o-matic  works on 2.6
and which ones don't compile. Here is the complete result of my tests.

I just try compiling them (after applying patches on a vanilla 2.6.0),
I didn't try to load or use them.

I've noticed too that when  a patch doesn't apply, pom-ng doesn't seem
to display it - or do it so fast that I don't notice it.

Here is the list from 'base' and 'extra' sets:

**** BASE ****

Does not compile:

- pool, nf-log, raw:
  CC      net/core/netfilter.o
net/core/netfilter.c: In function `nf_log_register':
net/core/netfilter.c:760: warning: implicit declaration of function `br_write_lock_bh'
net/core/netfilter.c:760: error: `BR_NETPROTO_LOCK' undeclared (first use in this function)
net/core/netfilter.c:760: error: (Each undeclared identifier is reported only once
net/core/netfilter.c:760: error: for each function it appears in.)
net/core/netfilter.c:765: warning: implicit declaration of function `br_write_unlock_bh'
net/core/netfilter.c: In function `nf_log_unregister':
net/core/netfilter.c:770: error: `BR_NETPROTO_LOCK' undeclared (first use in this function)

- HOPLIMIT: 
  Does not compile, but exists has ip6t_hl.o in vanilla 2.6.0

- connlimit:
  CC [M]  net/ipv4/netfilter/ipt_connlimit.o
net/ipv4/netfilter/ipt_connlimit.c:214: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_connlimit.c: In function `init':
net/ipv4/netfilter/ipt_connlimit.c:219: error: `ip_conntrack_module' undeclared (first use in this function)
net/ipv4/netfilter/ipt_connlimit.c:219: error: (Each undeclared identifier is reported only once
net/ipv4/netfilter/ipt_connlimit.c:219: error: for each function it appears in.)
net/ipv4/netfilter/ipt_connlimit.c:220: warning: implicit declaration of function `__MOD_INC_USE_COUNT'
net/ipv4/netfilter/ipt_connlimit.c: In function `fini':
net/ipv4/netfilter/ipt_connlimit.c:227: error: `ip_conntrack_module' undeclared (first use in this function)
net/ipv4/netfilter/ipt_connlimit.c:228: warning: implicit declaration of function `__MOD_DEC_USE_COUNT'

It seems to be module initialisation stuff changes, probably easy to fix.

- NETLINK:
  CC [M]  net/ipv4/netfilter/ipt_NETLINK.o
net/ipv4/netfilter/ipt_NETLINK.c:90: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_NETLINK.c:91: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_NETLINK.c: In function `fini':
net/ipv4/netfilter/ipt_NETLINK.c:115: error: structure has no member named `socket'
net/ipv4/netfilter/ipt_NETLINK.c:115: error: structure has no member named `socket'
make[3]: *** [net/ipv4/netfilter/ipt_NETLINK.o] Error 1

Compiles with warning:

  CC [M]  net/ipv4/netfilter/ipt_quota.o
net/ipv4/netfilter/ipt_quota.c:65: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_dstlimit.o
net/ipv4/netfilter/ipt_dstlimit.c:468: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_mport.o
net/ipv4/netfilter/ipt_mport.c:99: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_time.o
net/ipv4/netfilter/ipt_time.c:124: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_random.o
net/ipv4/netfilter/ipt_random.c:75: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_psd.o
net/ipv4/netfilter/ipt_psd.c: In function `ipt_psd_match':
net/ipv4/netfilter/ipt_psd.c:178: warning: comparison of distinct pointer types lacks a cast
net/ipv4/netfilter/ipt_psd.c:178: warning: comparison of distinct pointer types lacks a cast
net/ipv4/netfilter/ipt_psd.c: At top level:
net/ipv4/netfilter/ipt_psd.c:336: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_nth.o
net/ipv4/netfilter/ipt_nth.c:144: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_ipv4options.o
net/ipv4/netfilter/ipt_ipv4options.c:155: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_fuzzy.o
net/ipv4/netfilter/ipt_fuzzy.c:171: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_u32.o
net/ipv4/netfilter/ipt_u32.c:198: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_TTL.o
net/ipv4/netfilter/ipt_TTL.c:97: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_TTL.c:97: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_IPV4OPTSSTRIP.o
net/ipv4/netfilter/ipt_IPV4OPTSSTRIP.c:66: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_IPV4OPTSSTRIP.c:66: warning: initialization from incompatible pointer type
  CC [M]  net/ipv6/netfilter/ip6table_mangle.o
net/ipv6/netfilter/ip6table_mangle.c: In function `ip6t_local_hook':
net/ipv6/netfilter/ip6table_mangle.c:162: warning: `skb_linearize' is deprecated (declared at include/linux/skbuff.h:1136)
  CC [M]  net/ipv6/netfilter/ip6t_REJECT.o
net/ipv6/netfilter/ip6t_REJECT.c: In function `reject6_target':
net/ipv6/netfilter/ip6t_REJECT.c:149: warning: passing arg 5 of `icmpv6_send' discards qualifiers from pointer target type
net/ipv6/netfilter/ip6t_REJECT.c:152: warning: passing arg 5 of `icmpv6_send' discards qualifiers from pointer target type
net/ipv6/netfilter/ip6t_REJECT.c:155: warning: passing arg 5 of `icmpv6_send' discards qualifiers from pointer target type
net/ipv6/netfilter/ip6t_REJECT.c:158: warning: passing arg 5 of `icmpv6_send' discards qualifiers from pointer target type
net/ipv6/netfilter/ip6t_REJECT.c:161: warning: passing arg 5 of `icmpv6_send' discards qualifiers from pointer target type
  CC [M]  net/ipv4/netfilter/ipt_osf.o
net/ipv4/netfilter/ipt_osf.c:83: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_realm.o
net/ipv4/netfilter/ipt_realm.c:55: warning: initialization from incompatible pointer type

Compiles without warning:

NETMAP SAME iprange 


**** EXTRA ****

Does not compile:

- rsh
  CC      net/ipv4/netfilter/ip_conntrack_standalone.o
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:26:
include/linux/netfilter_ipv4/ip_conntrack.h:88: error: field `ct_rsh_info' has incomplete type

- mms-conntrack-nat 
  CC      net/ipv4/netfilter/ip_conntrack_standalone.o
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:26:
include/linux/netfilter_ipv4/ip_conntrack.h:89: error: field `ct_mms_info' has incomplete type

- h323-conntrack-nat 
  CC      net/ipv4/netfilter/ip_conntrack_standalone.o
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:26:
include/linux/netfilter_ipv4/ip_conntrack.h:90: error: field `ct_h225_info' has incomplete type

- cuseemee-nat
oops forgot to copy/paste the error message, sorry

- rtsp-conntrack 
  CC      net/ipv4/netfilter/ip_conntrack_standalone.o
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:26:
include/linux/netfilter_ipv4/ip_conntrack.h:74: error: field `ct_rtsp_info' has incomplete type

- talk-conntrack-nat
  CC      net/ipv4/netfilter/ip_conntrack_standalone.o
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:26:
include/linux/netfilter_ipv4/ip_conntrack.h:89: error: field `ct_talk_info' has incomplete type


Compiles with warning:

  CC [M]  net/ipv4/netfilter/ipt_IPMARK.o
net/ipv4/netfilter/ipt_IPMARK.c:72: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_IPMARK.c:72: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_CONNMARK.o
net/ipv4/netfilter/ipt_CONNMARK.c:71: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_CONNMARK.c:71: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ip_conntrack_egg.o
net/ipv4/netfilter/ip_conntrack_egg.c: In function `init':
net/ipv4/netfilter/ip_conntrack_egg.c:207: warning: assignment from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_XOR.o
net/ipv4/netfilter/ipt_XOR.c:94: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_XOR.c:94: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ip_conntrack_rpc_tcp.o
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c: In function `alloc_request_p':
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:164: warning: missing braces around initializer
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:164: warning: (near initialization for `(anonymous).timeout.lock')
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:164: warning: excess elements in struct initializer
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:164: warning: (near initialization for `(anonymous).timeout.lock')
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:165: warning: initialization makes integer from pointer without a cast
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c: In function `check_rpc_packet':
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:252: warning: operation on `data' may be undefined
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c: In function `init':
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:457: warning: assignment from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ip_conntrack_rpc_udp.o
net/ipv4/netfilter/ip_conntrack_rpc_udp.c: In function `alloc_request_p':
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:164: warning: missing braces around initializer
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:164: warning: (near initialization for `(anonymous).timeout.lock')
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:164: warning: excess elements in struct initializer
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:164: warning: (near initialization for `(anonymous).timeout.lock')
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:165: warning: initialization makes integer from pointer without a cast
net/ipv4/netfilter/ip_conntrack_rpc_udp.c: In function `check_rpc_packet':
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:252: warning: operation on `data' may be undefined
net/ipv4/netfilter/ip_conntrack_rpc_udp.c: In function `init':
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:452: warning: assignment from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_rpc.o
net/ipv4/netfilter/ipt_rpc.c:76: warning: type defaults to `int' in declaration of `EXPORT_NO_SYMBOLS'
net/ipv4/netfilter/ipt_rpc.c:76: warning: data definition has no type or storage class
net/ipv4/netfilter/ipt_rpc.c:389: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_rpc.c: In function `init':
net/ipv4/netfilter/ipt_rpc.c:398: warning: implicit declaration of function `__MOD_INC_USE_COUNT'
net/ipv4/netfilter/ipt_rpc.c: In function `fini':
net/ipv4/netfilter/ipt_rpc.c:421: warning: implicit declaration of function `__MOD_DEC_USE_COUNT'

*** Warning: "__MOD_DEC_USE_COUNT" [net/ipv4/netfilter/ipt_rpc.ko] undefined!
*** Warning: "__MOD_INC_USE_COUNT" [net/ipv4/netfilter/ipt_rpc.ko] undefined!

  CC [M]  net/ipv4/netfilter/ipt_addrtype.o
net/ipv4/netfilter/ipt_addrtype.c:50: warning: initialization from incompatible pointer type

  CC [M]  net/ipv4/netfilter/ipt_TCPLAG.o
net/ipv4/netfilter/ipt_TCPLAG.c: In function `divide_down':
net/ipv4/netfilter/ipt_TCPLAG.c:102: warning: statement with no effect
net/ipv4/netfilter/ipt_TCPLAG.c: At top level:
net/ipv4/netfilter/ipt_TCPLAG.c:643: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_TCPLAG.c:644: warning: initialization from incompatible pointer type

Compiles without warning:

quake3-conntrack-nat
   


-- 
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM         : 06.71.47.18.22 (in France)   ICQ UIN   : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA

Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org

Re: Call for testing: patch-o-matic-ng

[Unknown, Alistair Tonner]

On December 23, 2003 07:26 pm, Gaël Le Mignot wrote:
> Hello Harald, hello netfiler list ;)
>
> I did  some tests on which  patch from the patch-o-matic  works on 2.6
> and which ones don't compile. Here is the complete result of my tests.
>
> I just try compiling them (after applying patches on a vanilla 2.6.0),
> I didn't try to load or use them.
>
> I've noticed too that when  a patch doesn't apply, pom-ng doesn't seem
> to display it - or do it so fast that I don't notice it.
>
>
	Agreed -- same here -- offlist to Harald as well since I think my perl is weirding out on us.

	Alistair

Re: Call for testing: patch-o-matic-ng

[Unknown, Alistair Tonner]

On December 23, 2003 07:26 pm, Gaël Le Mignot wrote:
> Hello Harald, hello netfiler list ;)
>
> I did  some tests on which  patch from the patch-o-matic  works on 2.6
> and which ones don't compile. Here is the complete result of my tests.
>
> I just try compiling them (after applying patches on a vanilla 2.6.0),
> I didn't try to load or use them.
>
> I've noticed too that when  a patch doesn't apply, pom-ng doesn't seem
> to display it - or do it so fast that I don't notice it.
>
>
	Agreed -- same here -- offlist to Harald as well since I think my perl is weirding out on us.

	Alistair

Re: Call for testing: patch-o-matic-ng

[Galtar]

Hi!

Can anybody can tell me where I can download Patch-o-magic-ng???

-- 
Best regards,
 Galtar                            mailto:galtar2@wp.pl

Re: Call for testing: patch-o-matic-ng

[Antony Stone]

On Thursday 25 December 2003 9:06 am, Galtar wrote:

> Hi!
>
> Can anybody can tell me where I can download Patch-o-magic-ng???

Quoting from Harald's original posting in this thread:

"Everybody interested can check it out from CVS
(netfilter/patch-o-matic-ng).  Everything should look exactly like the
old patch-o-matic, including screen output and command syntax."

See http://www.netfilter.org/downloads.html#cvs for more details.

Antony.

-- 
In science, one tries to tell people
in such a way as to be understood by everyone
something that no-one ever knew before.

In poetry, it is the exact opposite.

 - Paul Dirac

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Call for testing: patch-o-matic-ng

[Henrik Nordstrom]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2145 bytes --]

On Sun, 21 Dec 2003, Harald Welte wrote:

> - no wholefile-patches in CVS.  This means that entirely new files like
>   net/ipv4/netfilter/ipt_foo.c / ipt_foo.h are not stored as patches but
>   rather in their original form.   This in turn means real version
>   control on the sourcecode!

One idea for further improvement:

It would be nice if runme could support "wholefile modifications" where
both the whole original and patched files are stored rather than a diff
(patch generated on the fly when applying to the kernel source tree). This
simplifies the development phase of a extension requiring patching of
other files and also simplifies maintenance of major rewrites.

I have been using the above model for a number of kernel projects for a
long time and find it very successful at tracking the changes. What I do
is that my development tree only contains the changed files, and then a
script copies the changes over to the kernel tree. The script is designed
in such manner that it can be run multiple times to copy over new changes
to a already patched tree, completely eleminating the need to directly
modifying the full source tree directly during development.

The script I am using is attached to this message. to try it out grab for
example a copy of the user-mode-linux CVS tree or another project using
"full modified files" source layout, then place the script in the top 
level directory (the equivalence of the Linux top level source directory) 
and then run the script supplying the path to your full kernel tree as 
argument.

Note that agree that the main CVS repository probably should contain
patches like it is now rather than "wholefile patches".  But during
development I find maintaining a patch file is a little awkward and some
kind of changes easily get lost. And in the few cases where a patch mostly 
rewrites a existing file having it as a full file makes more sense than 
patch format.

> However, some stuff is still missing (see the patch-o-matic/TODO file).
> I'm working on implementing those missing features, though.

What is also missing is a equivalence to the NEWPATCHES document.

Regards
Henrik

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2397 bytes --]

#!/bin/sh
cd `dirname $0`

# This variable is used for backup copies to allow incremental patching
project=uml

KERNEL_DIR="${KERNEL_DIR:-/usr/src/linux-${project}}"
while [ $# -ge 1 ]; do
    case "$1" in
    -full)
	full=1;;
    -orig)
    	orig=1;;
    *)
    	break;;
    esac
    shift
done
KERNEL_DIR=${1:-${KERNEL_DIR}}
if [ ! -d ${KERNEL_DIR} ]; then
    echo "ERROR: No kernel directory"
    exit 1
fi
find . -name '.#*' -print0 | xargs -0 rm -f
# Create "original" copies of the Linux sources
if [ ! -d orig ] || [ $orig ]; then
  echo "First time. Creating \"pristine\" source copies in $PWD/orig"
  find . -type f -print -o -name 'orig' -prune | while read file; do
    if [ -f ${KERNEL_DIR}/$file ]; then
      mkdir -p orig/`dirname $file`
      cp -p ${KERNEL_DIR}/$file orig/$file
      echo "   $file"
    fi
  done
  if [ $orig ]; then
    exit
  fi
fi
# On full updates, get rid of all user-mode architecture files
if test $full; then
  rm -rf ${KERNEL_DIR}/arch/um ${KERNEL_DIR}/include/asm-um
fi
# Set up new UM kernel tree directories
find -name CVS -prune -o -name orig -prune -o -type d -print | (cd ${KERNEL_DIR} && xargs mkdir -p )
# Copy over UM kernel changes
echo "Patching kernel with UML changes"
find [^o]* -name CVS -prune -o -name .cvsignore -prune -o -name orig -prune -o -type f -print | while read f; do
  if test -f orig/$f; then
    first=
    # This is a patched file. Only copy over the changes, preserve
    # any other local modifications.
    if [ ! -f ${KERNEL_DIR}/$f.no${project} ]; then
      # First time. Make a backup copy of the original (possibly modified)
      # kernel source, so we can update it again later if needed
      cp -p ${KERNEL_DIR}/$f ${KERNEL_DIR}/$f.no${project}
      first=1
    fi
    if test $f -nt ${KERNEL_DIR}/$f || test $full || test $first; then
      # Apply the changes to the kernel tree
      if ! test $first; then
	rm -f ${KERNEL_DIR}/$f
	cp -p ${KERNEL_DIR}/$f.no${project} ${KERNEL_DIR}/$f
      fi
      diff -u orig/$f $f | patch -s ${KERNEL_DIR}/$f
      touch -r $f ${KERNEL_DIR}/$f
      echo "P   $f"
    fi
  else
    # This is a project specific file. Just copy it over.
    if ! test -f ${KERNEL_DIR}/$f || ! cmp -s $f ${KERNEL_DIR}/$f || test $full; then
      cp -p $f ${KERNEL_DIR}/$f
      echo "    $f"
    fi
  fi
done

ip_conntrack_pptp

[Jan Kaastrup]

Hi Harald and all on this list.

I have problems with ip_conntrack_pptp patch from POM-20031219

It seems the patch doesn't apply what it should:

"In the pptp-conntrack-nat.patch.configure.help it says something like
this:
CONFIG_IP_NF_CT_PROTO_GRE
  This module adds generic support for connection tracking and NAT of
the
  GRE protocol (RFC1701, RFC2784).  Please note that this will only work
  with GRE connections using the key field of the GRE header."

I do something like this for patching my kernel (2.4.21):
patch -p1 < ./path-o-mat.../ip_conntrack_pptp.patch, and everything
seems allright.

But I Never get the option in my kernelconfiguration - I want to make it
as a module.
I do have the ip_conntrack_pptp.c and .h file, maybe it is possible to
make my module out of them?


Does anyone know of this, or is it just me being stupid ?



Thanks a lot in regards

Jan

Re: ip_conntrack_pptp

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

On Thu, Jan 22, 2004 at 04:57:26PM +0100, Jan Kaastrup wrote:
> Hi Harald and all on this list.
> 
> I have problems with ip_conntrack_pptp patch from POM-20031219
> Does anyone know of this, or is it just me being stupid ?

*sigh* *sigh* *sigh*.  

Does anybody actually ponder reading the 'README' file included in the
patch-o-matic package?

> Jan

-- 
- Harald Welte <laforge@netfilter.org>             http://www.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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip_conntrack_pptp

[Unknown, Alistair Tonner]

On January 22, 2004 12:53 pm, Harald Welte wrote:
> On Thu, Jan 22, 2004 at 04:57:26PM +0100, Jan Kaastrup wrote:
> > Hi Harald and all on this list.
> >
> > I have problems with ip_conntrack_pptp patch from POM-20031219
> > Does anyone know of this, or is it just me being stupid ?
>
> *sigh* *sigh* *sigh*.
>
> Does anybody actually ponder reading the 'README' file included in the
> patch-o-matic package?


	I thought that was for padding to make the MD5 sums work??? 
	*grin*

	Alistair
>
> > Jan

Re: ip_conntrack_pptp

[Unknown, Alistair Tonner]

On January 22, 2004 12:53 pm, Harald Welte wrote:
> On Thu, Jan 22, 2004 at 04:57:26PM +0100, Jan Kaastrup wrote:
> > Hi Harald and all on this list.
> >
> > I have problems with ip_conntrack_pptp patch from POM-20031219
> > Does anyone know of this, or is it just me being stupid ?
>
> *sigh* *sigh* *sigh*.
>
> Does anybody actually ponder reading the 'README' file included in the
> patch-o-matic package?


	I thought that was for padding to make the MD5 sums work??? 
	*grin*

	Alistair
>
> > Jan

Re: ip_conntrack_pptp

[Unknown, Alistair Tonner]

On January 22, 2004 12:53 pm, Harald Welte wrote:
> On Thu, Jan 22, 2004 at 04:57:26PM +0100, Jan Kaastrup wrote:
> > Hi Harald and all on this list.
> >
> > I have problems with ip_conntrack_pptp patch from POM-20031219
> > Does anyone know of this, or is it just me being stupid ?
>
> *sigh* *sigh* *sigh*.
>
> Does anybody actually ponder reading the 'README' file included in the
> patch-o-matic package?


	I thought that was for padding to make the MD5 sums work??? 
	*grin*

	Alistair
>
> > Jan

Re: ip_conntrack_pptp

[Arnt Karlsen]

On Thu, 22 Jan 2004 12:53:45 -0500, 
Harald Welte <laforge@netfilter.org> wrote in message 
<20040122175345.GN1810@obroa-skai.de.gnumonks.org>:

> On Thu, Jan 22, 2004 at 04:57:26PM +0100, Jan Kaastrup wrote:
> > Hi Harald and all on this list.
> > 
> > I have problems with ip_conntrack_pptp patch from POM-20031219
> > Does anyone know of this, or is it just me being stupid ?
> 
> *sigh* *sigh* *sigh*.  
> 
> Does anybody actually ponder reading the 'README' file included in the
> patch-o-matic package?

..put it in the " *) " to bang it into our faces when we mistype, 
_some_ of it oughtta stick.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: ip_conntrack_pptp

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

On Mon, Jan 26, 2004 at 10:20:10AM +0100, Jan Kaastrup wrote:
> Hi Harald
> 
> I have read the README file for POM - and I cannot find anything that
> could tell what is wrong:(

The README doesn't tell you anywhere to apply that patchc manually.  It
tells you to run the './runme' script.

However, you are telling me, that you are manually applying the patch.
Witch will only give you about 90% of the required changes, not all of
them.

> >I do something like this for patching my kernel (2.4.21):
> >patch -p1 < ./path-o-mat.../ip_conntrack_pptp.patch, and everything
> >seems allright.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]