Hi James,
Dans un message du 07 Mar à 0:16, James Morris écrivait :
> > Dans un message du 06 Mar à 8:52, Harald Welte écrivait :
> > > I don't actually think that the unclean match should be widely delpoyed in
> > > production systems, honestly. I think it's just the wrong way to do
> > > packet filtering. It's a nice toy for some development and other
> > > 'experimental' use - but nothing more.
>
> I agree that it should be left as experimental; an option for advanced
> users and developers.
I still consider that "option for advanced users and developers" (I
agree that this description fits to Unclean) != CONFIG_EXPERIMENTAL.
Just look at the description "Prompt for incomplete or development
drivers". It is not a distinction between advanced users and "regular"
ones.
We could do something like :
diff -uNr linux-2.4.18-vanilla/net/ipv4/netfilter/Config.in
linux/net/ipv4/netfilter/Config.in
--- linux-2.4.18-vanilla/net/ipv4/netfilter/Config.in Mon Feb 25 20:38:14 2002
+++ linux/net/ipv4/netfilter/Config.in Tue Mar 5 14:36:11 2002
@@ -28,8 +28,8 @@
if [ "$CONFIG_IP_NF_CONNTRACK" != "n" ]; then
dep_tristate ' Connection state match support' CONFIG_IP_NF_MATCH_STATE
$CONFIG_IP_NF_CONNTRACK $CONFIG_IP_NF_IPTABLES
fi
+ dep_tristate ' Unclean match support (Advanced users only)'
+CONFIG_IP_NF_MATCH_UNCLEAN $CONFIG_IP_NF_IPTABLES
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
- dep_tristate ' Unclean match support (EXPERIMENTAL)' CONFIG_IP_NF_MATCH_UNCLEAN
$CONFIG_IP_NF_IPTABLES
dep_tristate ' Owner match support (EXPERIMENTAL)' CONFIG_IP_NF_MATCH_OWNER
$CONFIG_IP_NF_IPTABLES
fi
# The targets
The help text would explain the potention caveats of its use.
> Given that the module does not actually match all unclean IP packets,
Well, never heard of that. Could you tell me which ones we do not match
?
> and may later cause valid packets to be dropped, I don't feel that it
> should be a standard kernel option.
Following that very reason, a lot of kernel options would be
experimental like TCP ECN for instance.
> >
> > Well, I do not think that the experimental status fits this
> > description. Look at CONFIG_EXPERIMENTAL help : 'Some of the
> > various things that Linux supports (such as network drivers, file
> > systems, network protocols, etc.) can be in a state of development
> > where the functionality, stability, or the level of testing is not
> > yet high enough for general use.'
>
> I would say that the experimental nature of ipt_unclean is not
> appropriate for general use,
Wrt these aspects, ipt_unclean is NOT experimental. It is well tested,
functionnel and stable. I do agree with you when you claim it must be
used carefully BUT it is a matter of documentation, it is not linked to
"CONFIG_EXPERIMENTAL".
> where the focus should really be on
> deploying effective access control rules for network traffic. We
> should not be providing, as standard, modules with complicated
> semantics (e.g. "it doesn't actually work properly, but..."), which is
> likely to make the software and its deployment more complicted than it
> needs to be.
I agree with that principle, but it does not apply to ipt_unclean imho.
ipt_unclean semantics are very simple and clear, ipt_uncleans always
prints the very reason why it matches some packets (except for TCP
checksum error).
Anyway, you are the bosses here but imho the reasons you gave are
incorrect.
Regards,
--
Guillaume Morin <[EMAIL PROTECTED]>
Marry me girl, be my only fairy to the world (RHCP)
