Want to release 1.2.5 soon

[Jozsef Kadlecsik]

Hi Martin,

On Thu, 10 Jan 2002, Martin Josefsson wrote:

> and I missed that ip_conntrack_alter_reply() also in ip_conntrack_core.c
> is called from ip_nat_core.c and it searches the helper list again and
> replaces the helper-pointer unconditionally. I've changed it so it only
> changes the pointer if it actually finds a new helper that matches the new
> tuple after nat. It leaves the pointer alone if it doesn't find a helper.
> In the case where there was no helper to begin with it's still NULL after
> this function is called so no diffrence in behaviour here.

At the netfilter-workshop Rusty proposed to remove the re-setting of
the conntrack helper in ip_conntrack_alter_reply. In the
to-be-released-anytime-newnat patch I went with this solution.

> The only change in behaviour is that if you forward port 6667 to say 1234
> and you have ip_conntrack_irc loaded but no helper for port 1234 the irc
> helper is still the current helper for the connection even though it's
> probably not a irc connection.

It depends on what is the intention in forwardin the port:

- original way: alter_reply looked up a new helper unconditionally.

  If someone forwards port 6667 to 1234 as non-standard IRC port, then
  connection tracking will break if he/she forgets to define an irc
  conntrack helper for port 1234 (too).

- Rusty's proposal: alter_reply doesn't assign a new helper at all

  Reversed: if someone forwards port 1234 to 6667 as IRC port, then
  connection tracking will break if there is no irc conntrack helper on
  port 1234.

- your proposal: it seems to be just good if the intention was as in the
  examples above. But is there any sense in forwarding from/to a standard
  port, with the helper loaded on the standard port, without the context
  of the protocol belonging to that damned standard port? :-)

  Rusty proposed to leave out setting a new helper in alter_reply
  because of the complexity of H.323. In order to avoid dynamically
  generating helpers, in H.323 an expectfn sets the helper for
  the expected H.225 connections. The helper is not registered at all,
  because it works on random port(s). It seems that if there is no helper
  port clash between a registered helper and the unregistered H.225
  helper, then your proposal is just fine.

But! NAT sets the NAT helper always on the NATed port and this is
confusing. Shouldn't NAT set it's helper on the original port?

What's your opinion?

> One other solution is to check if it's an expected connection and skip the
> helper-lookup altogether. But one possible drawback of this is that it
> might break some weird conntrackhelpers (does it exist one that consists
> of dual conntrackhelpers? one normal and one for the expected connection)

Yes, it would break talk. And it would break H.323 in newnat.

> Which do you think is the best solution?

I think yours.

> Oh it just struck me.. if I ftp a file and my client happens to choose
> port 6667 as sourceport for the datatransfer, doesnt that mean that all
> data will pass through the irc helper? that seems like a big waste of cpu.

Would it worth to use flags for expectation like
SIMPLE_EXPECTED_CONNECTION and modify init_conntrack and ip_nat_setup_info
to add the checking wether it's an expected connection without the flag
set before assigning the helper? We would slow down a little bit *all*
connections to speed up a very few special cases.

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary