Function pointers in conntrack structures

Function pointers in conntrack structures

[Kovacs Krisztian]

  Hi,

  I've found a weird looking function pointer in the connection tracking
system: the expectfn member of struct ip_conntrack_expect. AFAIK, this
function would be called by conntrack when a matching connection is found
for the registered expectation. However, I was unable to find any
conntrack helpers which use this functionality.

  My problem with this function pointer is that it cannot be replicated:
you cannot just send the function pointer over the wire, because on the
other nodes it may have completely different address. While there are
other pointers in the conntrack structures as well, all of them have some
kind of associated data which can be used as an ID. (For example: although
helpers -- which are function pointers of some kind -- are associated with
conntrack entries, however, they have to be registered, and the conntrack
entry is associated with the registered helper structure instead of just the
callback function. This is very important, because these structures all
contain a "name" field, which can be used as an ID.

  So, the only problem point I've found is the expectfn field of struct
ip_conntrack_expect, for which I've no idea how that could be handled. Is
the possibility of having more than one kind of callback function for
expectation creation really so important? (If only one kind of function
would be usable by conntrack helpers, its address could be stored in
struct ip_conntrack_helper, and we didn't have the whole problem.)

  Any ideas?

-- 
 Kovács Krisztián (Hidden)

Re: Function pointers in conntrack structures

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 3356 bytes --]

On Tue, Sep 02, 2003 at 03:16:16PM +0200, Kovacs Krisztian wrote:
> 
>   Hi,
> 
>   I've found a weird looking function pointer in the connection tracking
> system: the expectfn member of struct ip_conntrack_expect. AFAIK, this
> function would be called by conntrack when a matching connection is found
> for the registered expectation. However, I was unable to find any
> conntrack helpers which use this functionality.

There are at least three users... a quick grep in patch-o-matic/extra
gives:
ip_conntrack_h323.c in function h245_help()
ip_conntrack_pptp.c in function exp_gre()
ip_conntrack_talk.c in function talk_help_response()

>   My problem with this function pointer is that it cannot be replicated:
> you cannot just send the function pointer over the wire, because on the
> other nodes it may have completely different address. While there are
> other pointers in the conntrack structures as well, all of them have some
> kind of associated data which can be used as an ID. (For example: although
> helpers -- which are function pointers of some kind -- are associated with
> conntrack entries, however, they have to be registered, and the conntrack
> entry is associated with the registered helper structure instead of just the
> callback function. This is very important, because these structures all
> contain a "name" field, which can be used as an ID.

yes.  The expectfn is also associated with the conntrack helper (it is
part of the conntrack helper module).   However, there can be multiple
expectfn()'s in a single helper, and some expectations are dealt with
one expectfn(), other expectations [of the same connection] are dealth
with the other expectfn().

This exactly resembles the protocol-stacks used in protocols like H.323
or SIP.  You have a single control session that spawns multiple other
sessions.  for SIP you have the SIP session, and you spawn usually one
or more pairs of RTP/RTCP data sessions.  So depending of the kind of
'sibling', you want different expectfn's to be called.

>   So, the only problem point I've found is the expectfn field of struct
> ip_conntrack_expect, for which I've no idea how that could be handled. Is
> the possibility of having more than one kind of callback function for
> expectation creation really so important? (If only one kind of function
> would be usable by conntrack helpers, its address could be stored in
> struct ip_conntrack_helper, and we didn't have the whole problem.)

Yes, it is important.  I doubt we can support the more complex protocols
without it.

Maybe we'd have to introduce an API to register expectfn's with the
core (including a name).  And then we store a pointer to the registered
structure (much like the 'helper' field currently) and you can replicate
the name.

I still don't like this approach - but it's viable.  

Any further comments/ideas/suggestions?

>   Any ideas?
> 
> -- 
>  Kovács Krisztián (Hidden)

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Function pointers in conntrack structures

[Jozsef Kadlecsik]

On Fri, 5 Sep 2003, Harald Welte wrote:

> >   So, the only problem point I've found is the expectfn field of struct
> > ip_conntrack_expect, for which I've no idea how that could be handled. Is
> > the possibility of having more than one kind of callback function for
> > expectation creation really so important? (If only one kind of function
> > would be usable by conntrack helpers, its address could be stored in
> > struct ip_conntrack_helper, and we didn't have the whole problem.)
>
> Yes, it is important.  I doubt we can support the more complex protocols
> without it.
>
> Maybe we'd have to introduce an API to register expectfn's with the
> core (including a name).  And then we store a pointer to the registered
> structure (much like the 'helper' field currently) and you can replicate
> the name.

The situation is a little bit worse: we may have unregistered conntrack
helpers, which are attached to an expected conntrack entry by the expectfn
(see H.323 conntrack module). So we should have and API to register
expectfn's and unregistered helpers as well. Grrr.

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