lkml.org 
[lkml]   [1999]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: IP Masq weirdness
Date
Hello!

> Well that IS what my modified ip_masq_select_addr() ends up doing. I don't
> like expanding the argument list like that, but i thought i'd follow what
> was there.

I wanted to say two things:

1. Those two lines in ip_forward.c must be deleted. They are wrong
as soon as ip_masq become more clever.
2. ip_masq_user does not get maddr, which is wrong.

> It occurs to me now that by the skb passing a rtable struct, and giving
> rt_src = to the actual source of the packet, it's only repeating data (as
> ip_forward() is passed the skb, ip_forward can check the iph->s_addr
> itself). Instead of route.c calling rt_set_nexthop() shouldn't it do a
> ip_route_output() and set rt_gateway rt_src via the result?

Parse error 8) I did not understand you, honestly.


> So the question here is why should ip_forward() choose a masquerading local
> address?

The only reason was that ip_masq was not enough clever to make this itself.
Reread my explanation again. If it is tought now, it can be removed
together with argument "maddr".

In any case, masquerading within policy routing is too late to remove
in 2.2, so that the code should be correct.


> It looks like the code in ip_masq_user drops out if maddr is set...
>
> if (ums->maddr)
> return 0;

If it were true, it would always return. Now maddr is always not zero
due to those lines in ip_forward.

Alexey

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.143 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site