[PATCH pom-ng 0/5] RFC: ip_nat|conntrack_h323.c on 2.6, first preview

[Robert Iakobashvili]

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
-similar 
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.

Sincerely,
Robert Iakobashvili
roberti at gonetworks.com
   

-----Original Message-----
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
Iakobashvili
Subject: Re: [PATCH pom-ng 0/5] RFC: ip_nat|conntrack_h323.c on 2.6,
first preview

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
well:
the H.323 "helper" could just pass the packets to userspace for
inspection and the expectations would then set up from there.

Best regards,
Jozsef
-
E-mail  : kadlec at blackhole.kfki.hu, kadlec at 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