[PATCH pom-ng 0/5] RFC: ip_nat|conntrack_h323.c on 2.6,
roberti at GoNetworks.com
Wed Jan 19 14:08:36 CET 2005
Thank you, Max, for your patches and Jozsef and Herve for discussion.
The architecture where a part of job done in kernel and
another in user-space with communication
seems to have its performance penalties (although more flexibility
To layer-7 application classifier project on the top of netfilter).
Keeping in mind industry needs, user space intervention
better to be limited by just configuration/settings,
putting classification rules/filters like BPF does.
roberti at gonetworks.com
From: Jozsef Kadlecsik [mailto:kadlec at blackhole.kfki.hu]
Sent: Wednesday, January 19, 2005 12:00 PM
To: Herve Eychenne
Cc: Max Kellermann; netfilter-devel at lists.netfilter.org; Robert
Subject: Re: [PATCH pom-ng 0/5] RFC: ip_nat|conntrack_h323.c on 2.6,
On Wed, 19 Jan 2005, Herve Eychenne wrote:
> > If you want to write a decent helper, then ethereal has got a H.323
> > (ASN) decoder written in C, which could probably be re-used. :-)
> Yes... but do we really want a big ASN-1 parser in the kernel?
> Is there a nice way to have it rely on kernel facilities, while
> staying in userspace though?
We don't really need the complete parsing of H.225/H.245 and that'd make
the code a little bit simpler.
If ctnetlink would be in the vanilla kernel, we could rely on it as
the H.323 "helper" could just pass the packets to userspace for
inspection and the expectations would then set up from there.
E-mail : kadlec at blackhole.kfki.hu, kadlec at sunserv.kfki.hu PGP key :
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
More information about the netfilter-devel