raw patch = kernel panic :(

raw patch = kernel panic :(

[c0g]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!
I applied raw-patch from CVS patch-o-matic (20031003), and it appears
that loading rule in PREROUTING chain of table raw causes kernel panic.
Specifing policy for this table doesn't.

So I was forced to use older POM, which fills my logs with "Frag of
proto" messages :(

Jozsef, could you look at it?

I have vanilla 2.4.22 kernel with following POM patches applied:
submitted/01_2.4.19
submitted/02_2.4.20
submitted/03_2.4.21
submitted/04_2.4.22
submitted/44_backport_ah_esp_fixes
submitted/54_ip_nat-macro-args
submitted/58-ip_conntrack-macro-args
submitted/60_nat_tftp-remove-warning
submitted/72_recent_procfs_fix
submitted/73_ipt_MASQUERADE-oif
submitted/74_nat-range-fix
submitted/75_REJECT_localpmtu-fix
submitted/76_snmp-checksum_h-fix
submitted/77_destroy-conntrack
submitted/78_nathelper-udp-csum
submitted/79_mangle_udp-sizecheck
submitted/80_ip_conntrack-proc
submitted/81_ipt_unclean-tcp-flag-table
submitted/82_irc-conntrack-mirc-serverlookup
submitted/83_nolocalout
submitted/84_local-nullbinding
submitted/85_ipv6header
submitted/86_getorigdst-tuple-zero
pending/40_nf-log
pending/59_ip_nat_h-unused-var
pending/61-remove-memsets
pending/64_masquerade-sameip-noflush
base/mport
extra/addrtype
extra/tcp-window-tracking
userspace/ipt_REJECT-fake-source
userspace/raw

- --
c0g@wp.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/gEWMPqmVt5WhbA8RAr7RAJ9VQQ113DigkI3z3RQmC1O0jLLABACdG+8J
1aWGhgAe91Ftgyvq+5g5cv0=
=+2Gf
-----END PGP SIGNATURE-----

raw patch = kernel panic :(

[c0g]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!
I applied raw-patch from CVS patch-o-matic (20031003), and it appears
that loading rule in PREROUTING chain of table raw causes kernel panic.
Specifing policy for this table doesn't.

So I was forced to use older POM, which fills my logs with "Frag of
proto" messages :(

Jozsef, could you look at it?

I have vanilla 2.4.22 kernel with following POM patches applied:
submitted/01_2.4.19
submitted/02_2.4.20
submitted/03_2.4.21
submitted/04_2.4.22
submitted/44_backport_ah_esp_fixes
submitted/54_ip_nat-macro-args
submitted/58-ip_conntrack-macro-args
submitted/60_nat_tftp-remove-warning
submitted/72_recent_procfs_fix
submitted/73_ipt_MASQUERADE-oif
submitted/74_nat-range-fix
submitted/75_REJECT_localpmtu-fix
submitted/76_snmp-checksum_h-fix
submitted/77_destroy-conntrack
submitted/78_nathelper-udp-csum
submitted/79_mangle_udp-sizecheck
submitted/80_ip_conntrack-proc
submitted/81_ipt_unclean-tcp-flag-table
submitted/82_irc-conntrack-mirc-serverlookup
submitted/83_nolocalout
submitted/84_local-nullbinding
submitted/85_ipv6header
submitted/86_getorigdst-tuple-zero
pending/40_nf-log
pending/59_ip_nat_h-unused-var
pending/61-remove-memsets
pending/64_masquerade-sameip-noflush
base/mport
extra/addrtype
extra/tcp-window-tracking
userspace/ipt_REJECT-fake-source
userspace/raw

- --
c0g@wp.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/gEWMPqmVt5WhbA8RAr7RAJ9VQQ113DigkI3z3RQmC1O0jLLABACdG+8J
1aWGhgAe91Ftgyvq+5g5cv0=
=+2Gf
-----END PGP SIGNATURE-----

Re: raw patch = kernel panic :(

[Jozsef Kadlecsik]

On Sun, 5 Oct 2003, c0g wrote:

> I applied raw-patch from CVS patch-o-matic (20031003), and it appears
> that loading rule in PREROUTING chain of table raw causes kernel panic.

Yes, that was due to a stupid bug in the NOTRACK target. I have applied
the fixed patch in p-o-m. Sorry for the previous buggy release.

Harald, I added the ported nf-log patch to the 2.5 p-o-m tree as
pending. But what to do with the port of the raw patch, which is ready?
Shall we introduce the userspace tree under patch-o-matic_2.5/?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: raw patch = kernel panic :(

[Harald Welte]

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

On Mon, Oct 06, 2003 at 12:44:17PM +0200, Jozsef Kadlecsik wrote:
> 
> Harald, I added the ported nf-log patch to the 2.5 p-o-m tree as
> pending. But what to do with the port of the raw patch, which is ready?
> Shall we introduce the userspace tree under patch-o-matic_2.5/?

No.  We just commit the userspace changes to the stock iptables package.

The changes are:
- add support for the raw table to libipt_conntrack.  This needs
  IPT_CONNTRACK_STATE_UNTRACKED defined.  It has an (ugly) section to
  libipt_conntrack.c to accomodate the fact that we might not have a
  patched kernel
- add support to libipt_state. The same for IPT_STATE_UNTRACKED
- add support for the raw table to libi4tc.c.  This has no compatibility
  implications.

So I don't really see the need for raw.patch having a userspace part at
all.

Did I miss something?

> Best regards,
> Jozsef

-- 
- 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: raw patch = kernel panic :(

[c0g]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

|>I applied raw-patch from CVS patch-o-matic (20031003), and it appears
|>that loading rule in PREROUTING chain of table raw causes kernel panic.
|
|
| Yes, that was due to a stupid bug in the NOTRACK target. I have applied
| the fixed patch in p-o-m. Sorry for the previous buggy release.

Great! Thanks.

- --
c0g@wp.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/gcLfPqmVt5WhbA8RAmEgAKCS62bNCPIBSBH8YufYDdBxoxTiXQCfaLUI
ygtDICgaQ5aaTj1l8b3LZ0A=
=eHLR
-----END PGP SIGNATURE-----

Re: raw patch = kernel panic :(

[Jozsef Kadlecsik]

On Mon, 6 Oct 2003, Harald Welte wrote:

> > Harald, I added the ported nf-log patch to the 2.5 p-o-m tree as
> > pending. But what to do with the port of the raw patch, which is ready?
> > Shall we introduce the userspace tree under patch-o-matic_2.5/?
>
> No.  We just commit the userspace changes to the stock iptables package.

OK. I added the patch as patch-o-matic_2.5/pending/71_raw.patch

> The changes are:
> - add support for the raw table to libipt_conntrack.  This needs
>   IPT_CONNTRACK_STATE_UNTRACKED defined.  It has an (ugly) section to
>   libipt_conntrack.c to accomodate the fact that we might not have a
>   patched kernel
> - add support to libipt_state. The same for IPT_STATE_UNTRACKED
> - add support for the raw table to libi4tc.c.  This has no compatibility
>   implications.

These are all covered by the patch-o-matic/userspace/raw.patch.userspace
part.

> So I don't really see the need for raw.patch having a userspace part at
> all.
>
> Did I miss something?

No, then there's no problem. I did not think of simply releasing a new
iptables snapshot.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: raw patch = kernel panic :(

[Harald Welte]

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

On Tue, Oct 07, 2003 at 12:12:12PM +0200, Jozsef Kadlecsik wrote:
> > So I don't really see the need for raw.patch having a userspace part at
> > all.
> >
> > Did I miss something?
> 
> No, then there's no problem. I did not think of simply releasing a new
> iptables snapshot.

I'm about to release 1.2.9 anyway, so I'll add the userspace part of the
raw patch now.

> Best regards,
> Jozsef

-- 
- 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 --]