hi, there is no support for patch-o-matic netfilter modules. what i have to do if i want to use several patch-o-matic modules? which parts of code has to be changed and will that changed be included into the main shorewall tree in future or not? best regards claus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Claus Rosenberger wrote: | there is no support for patch-o-matic netfilter modules. what i have to do | if i want to use several patch-o-matic modules? In some cases, you can use Extension Scripts (http://shorewall.net/shorewall_extension_scripts.htm). | | which parts of code has to be changed and will that changed be included | into the main shorewall tree in future or not? The modifications depend on what the patch-0-matic module does and how you decide to integrate it into Shorewall. I will only include such changes in the main shorewall tree at such time as the module is available in the kernel.org tree. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBPxwZO/MAbZfjDLIRAgr+AKCrWZh8ZvV1irJ8WhNtSyRk7AIDpwCfdG4s MXedMhPdNwfUdhu4j93NqrU=jmeH -----END PGP SIGNATURE-----
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Claus Rosenberger wrote: > > | there is no support for patch-o-matic netfilter modules. what i have to > do > | if i want to use several patch-o-matic modules? > > In some cases, you can use Extension Scripts > (http://shorewall.net/shorewall_extension_scripts.htm).ok> | > | which parts of code has to be changed and will that changed be included > | into the main shorewall tree in future or not? > > The modifications depend on what the patch-0-matic module does and how > you decide to integrate it into Shorewall. I will only include such > changes in the main shorewall tree at such time as the module is > available in the kernel.org tree.do you think that it will be possible in future to include special code like a plugin into shorewall? i.e. code for patch-o-matic modules. but interfaces between the core shorewall and a plugin system will be needed then. do you think it''s possible and realistic?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Claus Rosenberger wrote: | | | do you think that it will be possible in future to include special code | like a plugin into shorewall? i.e. code for patch-o-matic modules. but | interfaces between the core shorewall and a plugin system will be needed | then. do you think it''s possible and realistic? I don''t think so. Integrating support for a new netfilter module often requires rather sugrical changes to the code. The ''policy match'' changes to support Kernel 2.6 native IPSEC is a good example. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBPyArO/MAbZfjDLIRAgChAJsGIgsj3X8js7nnjw9XfE+WaouHAACeJfZC sW9OEO2KI07xi+a5r05pwfA=i80l -----END PGP SIGNATURE-----
> I don''t think so. Integrating support for a new netfilter module often > requires rather sugrical changes to the code. The ''policy match'' changes > to support Kernel 2.6 native IPSEC is a good example.hmm, i understand that it doesn''t make sense to include code for patch-o-matic modules because nobody know what will be changed in the future. how long patch-o-matic modules are seperated before being included into the kernel tree? i want to use h323 and in future ct_sync. any other ideas how it is possible to integrate these things without breaking the core shorewall code?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Claus Rosenberger wrote: |>I don''t think so. Integrating support for a new netfilter module often |>requires rather sugrical changes to the code. The ''policy match'' changes |>to support Kernel 2.6 native IPSEC is a good example. | | | hmm, i understand that it doesn''t make sense to include code for | patch-o-matic modules because nobody know what will be changed in the | future. how long patch-o-matic modules are seperated before being included | into the kernel tree? There seem to be no rules. Some of them seem to stay there indefinitely. i want to use h323 Two things: a) That is a module that will probably *never* be included in the kernel.org tree. The author of the module admits it is a miserable hack that doesn''t do the complete job. b) You should be able to use the H323 module with *no* change to Shorewall. ~ and in future ct_sync. I wouldn''t think that ct_sync would need any Shorewall support either. any other | ideas how it is possible to integrate these things without breaking the | core shorewall code? Again, if you need to add netfilter rules that are not possible using standard Shorewall file entries, then I would start with trying to do what you need to in Extension Scripts; that is the architected way for users to extend Shorewall safely. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBPy03O/MAbZfjDLIRAqYSAJsGQNzXJYYuNZuFpRkW1nE+xp9CLQCfQrS1 3avlVIKmwus/EL9PWK5EdEE=cjMz -----END PGP SIGNATURE-----
On Wed, 2004-09-08 at 17:13 +0200, Claus Rosenberger wrote:> > I don''t think so. Integrating support for a new netfilter module often > > requires rather sugrical changes to the code. The ''policy match'' changes > > to support Kernel 2.6 native IPSEC is a good example. > > hmm, i understand that it doesn''t make sense to include code for > patch-o-matic modules because nobody know what will be changed in the > future. how long patch-o-matic modules are seperated before being included > into the kernel tree? i want to use h323 and in future ct_sync. any other > ideas how it is possible to integrate these things without breaking the > core shorewall code? >I don''t think either of those would require any direct shorewall support. ct-sync would need a rule permitting the traffic (at most), and h323 would just need to be added to the modules list. If there were any specific tweaks for h323, that could be handled via extension scripts. -- David Hollis <dhollis@davehollis.com>