1) Right, my most recent patch killed those, ip_fw_masq is smarter.
2) It looks like ip_masq_user is passed a control struct, which contains a
user struct, that has the maddr in it, which is further relayed down the
chain.
> > 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.
Heh okay. In route.c, it sets up the skb that is later passed to
ip_forward(). Since it's a forwarded packet it sets rt_src to iph->saddr,
and rt_gateway to iph->daddr, and then calls rt_set_nexthop which sets
rt_gateway to the proper address. To me it would make sense to set rt_src
to the local address that it would use for masquerading. The ip header
(iph) is passed with the skb anyway, if the source address is needed, a
child function can find it from there anyway. Of course, doing a
ip_route_output() instead of rt_set_nexthop is not necessary for packets
that are forwarded but not masqueraded.
> > 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".
Ok I did that. Just not sure if i broke anything else in the process. :)
> In any case, masquerading within policy routing is too late to remove
> in 2.2, so that the code should be correct.
Later
Joe
-
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/