|
Home > Archive > Red Hat Kernel > January 2004 > Re: 2.4.22: iptables/ipchains conflict
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: 2.4.22: iptables/ipchains conflict
|
|
|
|
Here is some make output, to see where it appears.
See how ipchains.o and ipfwadm.o get compiled in ?
rm -f netfilter.o
ld -m elf_i386 -r -o netfilter.o ip_conntrack.o ip_conntrack_ftp.o
ip_conntrack_irc.o ip_nat_ftp.o
ip_nat_irc.o ip_tables.o iptable_filter.o iptable_mangle.o
iptable_nat.o ipt_helper.o ipt_limit.o
ipt_mark.o ipt_mac.o ipt_pkttype.o ipt_multiport.o ipt_owner.o
ipt_tos.o ipt_ecn.o ipt_dscp.o ipt_ah.o
ipt_esp.o ipt_length.o ipt_ttl.o ipt_state.o ipt_conntrack.o
ipt_unclean.o ipt_tcpmss.o ipt_REJECT.o
ipt_MIRROR.o ipt_TOS.o ipt_ECN.o ipt_DSCP.o ipt_MARK.o
ipt_MASQUERADE.o ipt_REDIRECT.o
ip_nat_snmp_basic.o ipt_LOG.o ipt_ULOG.o ipt_TCPMSS.o arp_tables.o
arptable_filter.o ipchains.o ipfwadm.o
ip_queue.o
ipchains.o(.text.init+0x70): In function `ip_conntrack_init':
: multiple definition of `ip_conntrack_init'
ip_conntrack.o(.text.init+0x10): first defined here
ipchains.o(.text+0x83b0): In function `ip_nat_cleanup':
: multiple definition of `ip_nat_cleanup'
iptable_nat.o(.text+0x27b0): first defined here
ipchains.o(.text+0x7910): In function `place_in_hashes':
: multiple definition of `place_in_hashes'
iptable_nat.o(.text+0x1d10): first defined here
| |
|
| On Tue, 23 Sep 2003 16:13:04 +0200, the right honourable "J.O. Aho"
<user@example.net> wrote:
quote:
>€®ik wrote:
>
>ipchain is only in the kernel for backward compability, for networking to get
>work I guess you must have iptables in one or another way.
>I do suggest you do switch to iptables, as most of the modules for ipchains is
>kernel 2.2 only.
>
>
> //Aho
yes, sure, but when I do that, I get multiple definitions errors like
a waterfall...
The point is, you can have both ipchains and iptables when compiling
them as modules. But when compiling IPtables into the kernel, you must
exclude Ipchains.
This exlcuding is done automatically in menuconfig.
I think incorrectly, because when you do that in 2.4.22, you get
multiple definitions of a lot of variable..
frgr
Erik
| |
|
| On Tue, 23 Sep 2003 16:13:04 +0200, the right honourable "J.O. Aho"
<user@example.net> wrote:
quote:
>€®ik wrote:
>
>ipchain is only in the kernel for backward compability, for networking to get
>work I guess you must have iptables in one or another way.
>I do suggest you do switch to iptables, as most of the modules for ipchains is
>kernel 2.2 only.
>
>
> //Aho
yes, sure, but when I do that, I get multiple definitions errors like
a waterfall...
The point is, you can have both ipchains and iptables when compiling
them as modules. But when compiling IPtables into the kernel, you must
exclude Ipchains.
This exlcuding is done automatically in menuconfig.
I think incorrectly, because when you do that in 2.4.22, you get
multiple definitions of a lot of variable..
frgr
Erik
| |
|
| On Tue, 23 Sep 2003 16:13:04 +0200, the right honourable "J.O. Aho"
<user@example.net> wrote:
quote:
>€®ik wrote:
>
>ipchain is only in the kernel for backward compability, for networking to get
>work I guess you must have iptables in one or another way.
>I do suggest you do switch to iptables, as most of the modules for ipchains is
>kernel 2.2 only.
>
>
> //Aho
yes, sure, but when I do that, I get multiple definitions errors like
a waterfall...
The point is, you can have both ipchains and iptables when compiling
them as modules. But when compiling IPtables into the kernel, you must
exclude Ipchains.
This exlcuding is done automatically in menuconfig.
I think incorrectly, because when you do that in 2.4.22, you get
multiple definitions of a lot of variable..
frgr
Erik
| |
|
| right now, i'm trying the 2.4.23-pre5 patches.
| |
|
| right now, i'm trying the 2.4.23-pre5 patches.
| |
|
| right now, i'm trying the 2.4.23-pre5 patches.
| |
| J.O. Aho 2004-01-23, 7:26 pm |
| €®ik wrote:
quote:
> yes, sure, but when I do that, I get multiple definitions errors like
> a waterfall...
> The point is, you can have both ipchains and iptables when compiling
> them as modules. But when compiling IPtables into the kernel, you must
> exclude Ipchains.
> This exlcuding is done automatically in menuconfig.
> I think incorrectly, because when you do that in 2.4.22, you get
> multiple definitions of a lot of variable..
Maybe the .config file don't get clean enough from the ipchain setting, just
that the menuconfig (or xconfig) disables ipchain option in the "GUI". Do a
bug report (check www.kernel.org to how to do that).
I don't see the point of having both compiled into the kernel, as you can't
use both at the same time. While when you have modules, you can choose which
one to use, but still not be able to use both at the same time.
//Aho
| |
| J.O. Aho 2004-01-23, 7:26 pm |
| €®ik wrote:
quote:
> yes, sure, but when I do that, I get multiple definitions errors like
> a waterfall...
> The point is, you can have both ipchains and iptables when compiling
> them as modules. But when compiling IPtables into the kernel, you must
> exclude Ipchains.
> This exlcuding is done automatically in menuconfig.
> I think incorrectly, because when you do that in 2.4.22, you get
> multiple definitions of a lot of variable..
Maybe the .config file don't get clean enough from the ipchain setting, just
that the menuconfig (or xconfig) disables ipchain option in the "GUI". Do a
bug report (check www.kernel.org to how to do that).
I don't see the point of having both compiled into the kernel, as you can't
use both at the same time. While when you have modules, you can choose which
one to use, but still not be able to use both at the same time.
//Aho
| |
| J.O. Aho 2004-01-23, 7:26 pm |
| €®ik wrote:
quote:
> yes, sure, but when I do that, I get multiple definitions errors like
> a waterfall...
> The point is, you can have both ipchains and iptables when compiling
> them as modules. But when compiling IPtables into the kernel, you must
> exclude Ipchains.
> This exlcuding is done automatically in menuconfig.
> I think incorrectly, because when you do that in 2.4.22, you get
> multiple definitions of a lot of variable..
Maybe the .config file don't get clean enough from the ipchain setting, just
that the menuconfig (or xconfig) disables ipchain option in the "GUI". Do a
bug report (check www.kernel.org to how to do that).
I don't see the point of having both compiled into the kernel, as you can't
use both at the same time. While when you have modules, you can choose which
one to use, but still not be able to use both at the same time.
//Aho
| |
|
| quote:
>I don't see the point of having both compiled into the kernel, as you can't
>use both at the same time. While when you have modules, you can choose which
>one to use, but still not be able to use both at the same time.
>
>
that's exactly one of the reasons I just want IPTables in the kernel:
I will never use ipchains and always iptables. No reason to make it a
module.
But it won't let me...
| |
|
| quote:
>I don't see the point of having both compiled into the kernel, as you can't
>use both at the same time. While when you have modules, you can choose which
>one to use, but still not be able to use both at the same time.
>
>
that's exactly one of the reasons I just want IPTables in the kernel:
I will never use ipchains and always iptables. No reason to make it a
module.
But it won't let me...
| |
|
| quote:
>I don't see the point of having both compiled into the kernel, as you can't
>use both at the same time. While when you have modules, you can choose which
>one to use, but still not be able to use both at the same time.
>
>
that's exactly one of the reasons I just want IPTables in the kernel:
I will never use ipchains and always iptables. No reason to make it a
module.
But it won't let me...
| |
| J.O. Aho 2004-01-23, 7:26 pm |
| €®ik wrote:quote:
[QUOTE][color=darkred]
> that's exactly one of the reasons I just want IPTables in the kernel:
> I will never use ipchains and always iptables. No reason to make it a
> module.
> But it won't let me...
Okey, what about iptables into the kernel and module of ipchains (this you
could delete later on) ?
I do suggest you file a bug report.
//Aho
| |
| J.O. Aho 2004-01-23, 7:26 pm |
| €®ik wrote:quote:
[QUOTE][color=darkred]
> that's exactly one of the reasons I just want IPTables in the kernel:
> I will never use ipchains and always iptables. No reason to make it a
> module.
> But it won't let me...
Okey, what about iptables into the kernel and module of ipchains (this you
could delete later on) ?
I do suggest you file a bug report.
//Aho
| |
| J.O. Aho 2004-01-23, 7:26 pm |
| €®ik wrote:quote:
[QUOTE][color=darkred]
> that's exactly one of the reasons I just want IPTables in the kernel:
> I will never use ipchains and always iptables. No reason to make it a
> module.
> But it won't let me...
Okey, what about iptables into the kernel and module of ipchains (this you
could delete later on) ?
I do suggest you file a bug report.
//Aho
| |
|
| quote:
>I do suggest you file a bug report.
>
>
which I did.
btw. I find a lot of #warnings in the sources...
about unused stuff, uninitialized stuff etc.
The code is not very clean, I must say.
| |
|
| quote:
>I do suggest you file a bug report.
>
>
which I did.
btw. I find a lot of #warnings in the sources...
about unused stuff, uninitialized stuff etc.
The code is not very clean, I must say.
| |
|
| quote:
>I do suggest you file a bug report.
>
>
which I did.
btw. I find a lot of #warnings in the sources...
about unused stuff, uninitialized stuff etc.
The code is not very clean, I must say.
| |
| J.O. Aho 2004-01-23, 7:26 pm |
| €®ik wrote:quote:
>
> which I did.
> btw. I find a lot of #warnings in the sources...
> about unused stuff, uninitialized stuff etc.
> The code is not very clean, I must say.
Thats life, a lot of programs do give warnings and so while compiling,
sometimes is it a secret combile option that should have been invoced during
the config other times it can depend on the version of another package or that
the coder isn't caring to much about coding by the rules...
As long as you don't get an [Error X] while you compile, things usually gets
okey.
//Aho
| |
| J.O. Aho 2004-01-23, 7:26 pm |
| €®ik wrote:quote:
>
> which I did.
> btw. I find a lot of #warnings in the sources...
> about unused stuff, uninitialized stuff etc.
> The code is not very clean, I must say.
Thats life, a lot of programs do give warnings and so while compiling,
sometimes is it a secret combile option that should have been invoced during
the config other times it can depend on the version of another package or that
the coder isn't caring to much about coding by the rules...
As long as you don't get an [Error X] while you compile, things usually gets
okey.
//Aho
| |
| J.O. Aho 2004-01-23, 7:26 pm |
| €®ik wrote:quote:
>
> which I did.
> btw. I find a lot of #warnings in the sources...
> about unused stuff, uninitialized stuff etc.
> The code is not very clean, I must say.
Thats life, a lot of programs do give warnings and so while compiling,
sometimes is it a secret combile option that should have been invoced during
the config other times it can depend on the version of another package or that
the coder isn't caring to much about coding by the rules...
As long as you don't get an [Error X] while you compile, things usually gets
okey.
//Aho
| |
|
|
Here is some make output, to see where it appears.
See how ipchains.o and ipfwadm.o get compiled in ?
rm -f netfilter.o
ld -m elf_i386 -r -o netfilter.o ip_conntrack.o ip_conntrack_ftp.o
ip_conntrack_irc.o ip_nat_ftp.o
ip_nat_irc.o ip_tables.o iptable_filter.o iptable_mangle.o
iptable_nat.o ipt_helper.o ipt_limit.o
ipt_mark.o ipt_mac.o ipt_pkttype.o ipt_multiport.o ipt_owner.o
ipt_tos.o ipt_ecn.o ipt_dscp.o ipt_ah.o
ipt_esp.o ipt_length.o ipt_ttl.o ipt_state.o ipt_conntrack.o
ipt_unclean.o ipt_tcpmss.o ipt_REJECT.o
ipt_MIRROR.o ipt_TOS.o ipt_ECN.o ipt_DSCP.o ipt_MARK.o
ipt_MASQUERADE.o ipt_REDIRECT.o
ip_nat_snmp_basic.o ipt_LOG.o ipt_ULOG.o ipt_TCPMSS.o arp_tables.o
arptable_filter.o ipchains.o ipfwadm.o
ip_queue.o
ipchains.o(.text.init+0x70): In function `ip_conntrack_init':
: multiple definition of `ip_conntrack_init'
ip_conntrack.o(.text.init+0x10): first defined here
ipchains.o(.text+0x83b0): In function `ip_nat_cleanup':
: multiple definition of `ip_nat_cleanup'
iptable_nat.o(.text+0x27b0): first defined here
ipchains.o(.text+0x7910): In function `place_in_hashes':
: multiple definition of `place_in_hashes'
iptable_nat.o(.text+0x1d10): first defined here
| |
|
| On Tue, 23 Sep 2003 16:13:04 +0200, the right honourable "J.O. Aho"
<user@example.net> wrote:
quote:
>€®ik wrote:
>
>ipchain is only in the kernel for backward compability, for networking to get
>work I guess you must have iptables in one or another way.
>I do suggest you do switch to iptables, as most of the modules for ipchains is
>kernel 2.2 only.
>
>
> //Aho
yes, sure, but when I do that, I get multiple definitions errors like
a waterfall...
The point is, you can have both ipchains and iptables when compiling
them as modules. But when compiling IPtables into the kernel, you must
exclude Ipchains.
This exlcuding is done automatically in menuconfig.
I think incorrectly, because when you do that in 2.4.22, you get
multiple definitions of a lot of variable..
frgr
Erik
| |
|
| right now, i'm trying the 2.4.23-pre5 patches.
| |
| J.O. Aho 2004-01-23, 7:26 pm |
| €®ik wrote:
quote:
> yes, sure, but when I do that, I get multiple definitions errors like
> a waterfall...
> The point is, you can have both ipchains and iptables when compiling
> them as modules. But when compiling IPtables into the kernel, you must
> exclude Ipchains.
> This exlcuding is done automatically in menuconfig.
> I think incorrectly, because when you do that in 2.4.22, you get
> multiple definitions of a lot of variable..
Maybe the .config file don't get clean enough from the ipchain setting, just
that the menuconfig (or xconfig) disables ipchain option in the "GUI". Do a
bug report (check www.kernel.org to how to do that).
I don't see the point of having both compiled into the kernel, as you can't
use both at the same time. While when you have modules, you can choose which
one to use, but still not be able to use both at the same time.
//Aho
| |
|
| quote:
>I don't see the point of having both compiled into the kernel, as you can't
>use both at the same time. While when you have modules, you can choose which
>one to use, but still not be able to use both at the same time.
>
>
that's exactly one of the reasons I just want IPTables in the kernel:
I will never use ipchains and always iptables. No reason to make it a
module.
But it won't let me...
| |
| J.O. Aho 2004-01-23, 7:26 pm |
| €®ik wrote:quote:
[QUOTE][color=darkred]
> that's exactly one of the reasons I just want IPTables in the kernel:
> I will never use ipchains and always iptables. No reason to make it a
> module.
> But it won't let me...
Okey, what about iptables into the kernel and module of ipchains (this you
could delete later on) ?
I do suggest you file a bug report.
//Aho
| |
|
| quote:
>I do suggest you file a bug report.
>
>
which I did.
btw. I find a lot of #warnings in the sources...
about unused stuff, uninitialized stuff etc.
The code is not very clean, I must say.
| |
| J.O. Aho 2004-01-23, 7:26 pm |
| €®ik wrote:quote:
>
> which I did.
> btw. I find a lot of #warnings in the sources...
> about unused stuff, uninitialized stuff etc.
> The code is not very clean, I must say.
Thats life, a lot of programs do give warnings and so while compiling,
sometimes is it a secret combile option that should have been invoced during
the config other times it can depend on the version of another package or that
the coder isn't caring to much about coding by the rules...
As long as you don't get an [Error X] while you compile, things usually gets
okey.
//Aho
| |
|
|
Here is some make output, to see where it appears.
See how ipchains.o and ipfwadm.o get compiled in ?
rm -f netfilter.o
ld -m elf_i386 -r -o netfilter.o ip_conntrack.o ip_conntrack_ftp.o
ip_conntrack_irc.o ip_nat_ftp.o
ip_nat_irc.o ip_tables.o iptable_filter.o iptable_mangle.o
iptable_nat.o ipt_helper.o ipt_limit.o
ipt_mark.o ipt_mac.o ipt_pkttype.o ipt_multiport.o ipt_owner.o
ipt_tos.o ipt_ecn.o ipt_dscp.o ipt_ah.o
ipt_esp.o ipt_length.o ipt_ttl.o ipt_state.o ipt_conntrack.o
ipt_unclean.o ipt_tcpmss.o ipt_REJECT.o
ipt_MIRROR.o ipt_TOS.o ipt_ECN.o ipt_DSCP.o ipt_MARK.o
ipt_MASQUERADE.o ipt_REDIRECT.o
ip_nat_snmp_basic.o ipt_LOG.o ipt_ULOG.o ipt_TCPMSS.o arp_tables.o
arptable_filter.o ipchains.o ipfwadm.o
ip_queue.o
ipchains.o(.text.init+0x70): In function `ip_conntrack_init':
: multiple definition of `ip_conntrack_init'
ip_conntrack.o(.text.init+0x10): first defined here
ipchains.o(.text+0x83b0): In function `ip_nat_cleanup':
: multiple definition of `ip_nat_cleanup'
iptable_nat.o(.text+0x27b0): first defined here
ipchains.o(.text+0x7910): In function `place_in_hashes':
: multiple definition of `place_in_hashes'
iptable_nat.o(.text+0x1d10): first defined here
| |
|
| On Tue, 23 Sep 2003 16:13:04 +0200, the right honourable "J.O. Aho"
<user@example.net> wrote:
quote:
>€®ik wrote:
>
>ipchain is only in the kernel for backward compability, for networking to get
>work I guess you must have iptables in one or another way.
>I do suggest you do switch to iptables, as most of the modules for ipchains is
>kernel 2.2 only.
>
>
> //Aho
yes, sure, but when I do that, I get multiple definitions errors like
a waterfall...
The point is, you can have both ipchains and iptables when compiling
them as modules. But when compiling IPtables into the kernel, you must
exclude Ipchains.
This exlcuding is done automatically in menuconfig.
I think incorrectly, because when you do that in 2.4.22, you get
multiple definitions of a lot of variable..
frgr
Erik
| |
|
| right now, i'm trying the 2.4.23-pre5 patches.
| |
| J.O. Aho 2004-01-23, 7:27 pm |
| €®ik wrote:
quote:
> yes, sure, but when I do that, I get multiple definitions errors like
> a waterfall...
> The point is, you can have both ipchains and iptables when compiling
> them as modules. But when compiling IPtables into the kernel, you must
> exclude Ipchains.
> This exlcuding is done automatically in menuconfig.
> I think incorrectly, because when you do that in 2.4.22, you get
> multiple definitions of a lot of variable..
Maybe the .config file don't get clean enough from the ipchain setting, just
that the menuconfig (or xconfig) disables ipchain option in the "GUI". Do a
bug report (check www.kernel.org to how to do that).
I don't see the point of having both compiled into the kernel, as you can't
use both at the same time. While when you have modules, you can choose which
one to use, but still not be able to use both at the same time.
//Aho
| |
|
| quote:
>I don't see the point of having both compiled into the kernel, as you can't
>use both at the same time. While when you have modules, you can choose which
>one to use, but still not be able to use both at the same time.
>
>
that's exactly one of the reasons I just want IPTables in the kernel:
I will never use ipchains and always iptables. No reason to make it a
module.
But it won't let me...
| |
| J.O. Aho 2004-01-23, 7:27 pm |
| €®ik wrote:quote:
[QUOTE][color=darkred]
> that's exactly one of the reasons I just want IPTables in the kernel:
> I will never use ipchains and always iptables. No reason to make it a
> module.
> But it won't let me...
Okey, what about iptables into the kernel and module of ipchains (this you
could delete later on) ?
I do suggest you file a bug report.
//Aho
| |
|
| quote:
>I do suggest you file a bug report.
>
>
which I did.
btw. I find a lot of #warnings in the sources...
about unused stuff, uninitialized stuff etc.
The code is not very clean, I must say.
| |
| J.O. Aho 2004-01-23, 7:27 pm |
| €®ik wrote:quote:
>
> which I did.
> btw. I find a lot of #warnings in the sources...
> about unused stuff, uninitialized stuff etc.
> The code is not very clean, I must say.
Thats life, a lot of programs do give warnings and so while compiling,
sometimes is it a secret combile option that should have been invoced during
the config other times it can depend on the version of another package or that
the coder isn't caring to much about coding by the rules...
As long as you don't get an [Error X] while you compile, things usually gets
okey.
//Aho
| |
|
|
Here is some make output, to see where it appears.
See how ipchains.o and ipfwadm.o get compiled in ?
rm -f netfilter.o
ld -m elf_i386 -r -o netfilter.o ip_conntrack.o ip_conntrack_ftp.o
ip_conntrack_irc.o ip_nat_ftp.o
ip_nat_irc.o ip_tables.o iptable_filter.o iptable_mangle.o
iptable_nat.o ipt_helper.o ipt_limit.o
ipt_mark.o ipt_mac.o ipt_pkttype.o ipt_multiport.o ipt_owner.o
ipt_tos.o ipt_ecn.o ipt_dscp.o ipt_ah.o
ipt_esp.o ipt_length.o ipt_ttl.o ipt_state.o ipt_conntrack.o
ipt_unclean.o ipt_tcpmss.o ipt_REJECT.o
ipt_MIRROR.o ipt_TOS.o ipt_ECN.o ipt_DSCP.o ipt_MARK.o
ipt_MASQUERADE.o ipt_REDIRECT.o
ip_nat_snmp_basic.o ipt_LOG.o ipt_ULOG.o ipt_TCPMSS.o arp_tables.o
arptable_filter.o ipchains.o ipfwadm.o
ip_queue.o
ipchains.o(.text.init+0x70): In function `ip_conntrack_init':
: multiple definition of `ip_conntrack_init'
ip_conntrack.o(.text.init+0x10): first defined here
ipchains.o(.text+0x83b0): In function `ip_nat_cleanup':
: multiple definition of `ip_nat_cleanup'
iptable_nat.o(.text+0x27b0): first defined here
ipchains.o(.text+0x7910): In function `place_in_hashes':
: multiple definition of `place_in_hashes'
iptable_nat.o(.text+0x1d10): first defined here
| |
|
| On Tue, 23 Sep 2003 16:13:04 +0200, the right honourable "J.O. Aho"
<user@example.net> wrote:
quote:
>€®ik wrote:
>
>ipchain is only in the kernel for backward compability, for networking to get
>work I guess you must have iptables in one or another way.
>I do suggest you do switch to iptables, as most of the modules for ipchains is
>kernel 2.2 only.
>
>
> //Aho
yes, sure, but when I do that, I get multiple definitions errors like
a waterfall...
The point is, you can have both ipchains and iptables when compiling
them as modules. But when compiling IPtables into the kernel, you must
exclude Ipchains.
This exlcuding is done automatically in menuconfig.
I think incorrectly, because when you do that in 2.4.22, you get
multiple definitions of a lot of variable..
frgr
Erik
| |
|
| right now, i'm trying the 2.4.23-pre5 patches.
| |
| J.O. Aho 2004-01-23, 7:28 pm |
| €®ik wrote:
quote:
> yes, sure, but when I do that, I get multiple definitions errors like
> a waterfall...
> The point is, you can have both ipchains and iptables when compiling
> them as modules. But when compiling IPtables into the kernel, you must
> exclude Ipchains.
> This exlcuding is done automatically in menuconfig.
> I think incorrectly, because when you do that in 2.4.22, you get
> multiple definitions of a lot of variable..
Maybe the .config file don't get clean enough from the ipchain setting, just
that the menuconfig (or xconfig) disables ipchain option in the "GUI". Do a
bug report (check www.kernel.org to how to do that).
I don't see the point of having both compiled into the kernel, as you can't
use both at the same time. While when you have modules, you can choose which
one to use, but still not be able to use both at the same time.
//Aho
| |
|
| quote:
>I don't see the point of having both compiled into the kernel, as you can't
>use both at the same time. While when you have modules, you can choose which
>one to use, but still not be able to use both at the same time.
>
>
that's exactly one of the reasons I just want IPTables in the kernel:
I will never use ipchains and always iptables. No reason to make it a
module.
But it won't let me...
| |
| J.O. Aho 2004-01-23, 7:28 pm |
| €®ik wrote:quote:
[QUOTE][color=darkred]
> that's exactly one of the reasons I just want IPTables in the kernel:
> I will never use ipchains and always iptables. No reason to make it a
> module.
> But it won't let me...
Okey, what about iptables into the kernel and module of ipchains (this you
could delete later on) ?
I do suggest you file a bug report.
//Aho
| |
|
| quote:
>I do suggest you file a bug report.
>
>
which I did.
btw. I find a lot of #warnings in the sources...
about unused stuff, uninitialized stuff etc.
The code is not very clean, I must say.
| |
| J.O. Aho 2004-01-23, 7:28 pm |
| €®ik wrote:quote:
>
> which I did.
> btw. I find a lot of #warnings in the sources...
> about unused stuff, uninitialized stuff etc.
> The code is not very clean, I must say.
Thats life, a lot of programs do give warnings and so while compiling,
sometimes is it a secret combile option that should have been invoced during
the config other times it can depend on the version of another package or that
the coder isn't caring to much about coding by the rules...
As long as you don't get an [Error X] while you compile, things usually gets
okey.
//Aho
|
|
|
|
|