[IPv4] Kill remnant of ip_nat_dumb

[IPv4] Kill remnant of ip_nat_dumb

[Herbert Xu]

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

Hi Dave:

This line in net/ipv4/Makefile was left behind when the rest of the
dumb NAT option was taken out.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[-- Attachment #2: p --]
[-- Type: text/plain, Size: 409 bytes --]

===== net/ipv4/Makefile 1.24 vs edited =====
--- 1.24/net/ipv4/Makefile	2004-08-20 00:13:10 +10:00
+++ edited/net/ipv4/Makefile	2004-09-22 13:53:54 +10:00
@@ -11,7 +11,6 @@
 
 obj-$(CONFIG_PROC_FS) += proc.o
 obj-$(CONFIG_IP_MULTIPLE_TABLES) += fib_rules.o
-obj-$(CONFIG_IP_ROUTE_NAT) += ip_nat_dumb.o
 obj-$(CONFIG_IP_MROUTE) += ipmr.o
 obj-$(CONFIG_NET_IPIP) += ipip.o
 obj-$(CONFIG_NET_IPGRE) += ip_gre.o

Re: [IPv4] Kill remnant of ip_nat_dumb

[jamal]

Geez, I missed that we killed static NAT too. Whats wrong with it?
I know at least two users of this - did we ask or 
is posting on netdev == ask?

cheers,
jamal

On Wed, 2004-09-22 at 00:01, Herbert Xu wrote:
> Hi Dave:
> 
> This line in net/ipv4/Makefile was left behind when the rest of the
> dumb NAT option was taken out.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> Cheers,

Re: [IPv4] Kill remnant of ip_nat_dumb

[David S. Miller]

On 22 Sep 2004 08:10:39 -0400
jamal <hadi@cyberus.ca> wrote:

> Geez, I missed that we killed static NAT too. Whats wrong with it?
> I know at least two users of this - did we ask or 
> is posting on netdev == ask?

It's gone until someone fixes it up into working condition
once more.  It's been broken ever since the first bits
of IPSEC dst cache infrastructure went in.

The old code is in the source history if anyone wants to
resurrect it and try to get it going again, but frankly
my opinion is:

1) there are ways to do that with other technologies
   in the tree, hey even tc actions could do it (wink wink :-)

2) judging by the amount of complaints of it not working any-
   more (ie. nearly zero), I don't think it's worth spending
   time on it

But have at it if you want :-)

Re: [IPv4] Kill remnant of ip_nat_dumb

[Andi Kleen]

On Wed, Sep 22, 2004 at 11:09:31AM -0700, David S. Miller wrote:
> On 22 Sep 2004 08:10:39 -0400
> jamal <hadi@cyberus.ca> wrote:
> 
> > Geez, I missed that we killed static NAT too. Whats wrong with it?
> > I know at least two users of this - did we ask or 
> > is posting on netdev == ask?
> 
> It's gone until someone fixes it up into working condition
> once more.  It's been broken ever since the first bits
> of IPSEC dst cache infrastructure went in.

Also netfilter has a static NAT too these days, so it doesn't 
seem to be very useful to have another one.

-Andi

Re: [IPv4] Kill remnant of ip_nat_dumb

[Harald Welte]

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

On Wed, Sep 22, 2004 at 08:14:33PM +0200, Andi Kleen wrote:
> > It's gone until someone fixes it up into working condition
> > once more.  It's been broken ever since the first bits
> > of IPSEC dst cache infrastructure went in.
> 
> Also netfilter has a static NAT too these days, so it doesn't 
> seem to be very useful to have another one.

yes and no. 

From a functionality point of view: yes.  

From a performance point of view, there are applications for really dumb
static NAT where you don't want to pull all the dependencies from
ip_conntrack over ip_tables.

> -Andi

-- 
- Harald Welte <laforge@gnumonks.org>               http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime

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

Re: [IPv4] Kill remnant of ip_nat_dumb

[Herbert Xu]

Harald Welte <laforge@gnumonks.org> wrote:
> 
> From a functionality point of view: yes.  
> 
> From a performance point of view, there are applications for really dumb
> static NAT where you don't want to pull all the dependencies from
> ip_conntrack over ip_tables.

Well the problem is nobody is stepping forward to fix it.  It was removed
not because it was redundant, but because it was broken.

Until someone actually fixes it, it can't go back in.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [IPv4] Kill remnant of ip_nat_dumb

[Harald Welte]

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

On Thu, Sep 23, 2004 at 06:12:55PM +1000, Herbert Xu wrote:
> Harald Welte <laforge@gnumonks.org> wrote:
> > 
> > From a functionality point of view: yes.  
> > 
> > From a performance point of view, there are applications for really dumb
> > static NAT where you don't want to pull all the dependencies from
> > ip_conntrack over ip_tables.
> 
> Well the problem is nobody is stepping forward to fix it.  It was removed
> not because it was redundant, but because it was broken.
> 
> Until someone actually fixes it, it can't go back in.

I fully understand this, and I support that decision.  

Independent of this, I just wanted to note that if there was working
and compatible code, it had it's use for high performance static nat
applications.

> Cheers,

-- 
- Harald Welte <laforge@gnumonks.org>               http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime

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

Re: [IPv4] Kill remnant of ip_nat_dumb

[jamal]

On Thu, 2004-09-23 at 04:29, Harald Welte wrote:
> On Thu, Sep 23, 2004 at 06:12:55PM +1000, Herbert Xu wrote:
[..]
> Independent of this, I just wanted to note that if there was working
> and compatible code, it had it's use for high performance static nat
> applications.

indeed. 
What happened to he who breaketh fixeth?
I may take a crack at it when i get the cycles.

cheers,
jamal