> > Please use the NAT code's SO_ORIGINAL_DST. Yes, this means recoding
> > squid, and yes I've been bad for not fixing that, but please send me
> > the squid patch instead...
>
> Well, first of all I simply did not see SO_ORIGINAL_DST exists.
> While that means recoding applications, it is certainly the nicer
> way - and most applications like squid (or my patched ssh) need to do
> something special in that place anyway. The approach does pose some
> problems, though:
>
> - what should I #include to get at the SO_ORIGINAL_DST #define?
> The include/ directory from the netfilter distribution is not
> installed anywhere. The includes crossreference each other.
> so something like
> 'ln -s /some/where/netfilter-0.1.9/include /usr/include/netfilter'
> (and then #include <netfilter/NAT/ip_nat.h>) does not work.
> I don't see an elegant way out of this.
It should be included in the 2.3 standard includes. Please send a patch.
>
> Rusty, as an alternative to this approach, how would you like the
> kernel side getsockname() implementation to try SO_ORIGINAL_DST in-kernel?
> That way user level need not care, sk_buff and struct sock is left alone,
> and there's only that one place learning a small bit about NAT. Still a
> bit ugly and inconsequential, but I would prefer that.
The old transparent proxy hacks were never documented, nor did glibc
ever provide any support for it (it was always required to do pointer
hacks with sockaddr_in or declare an own sockaddr_in replacement). The
few applications that support it can be fixed. I vote to kill the old
interface. As soon as SO_ORIGINAL_DST works i'll document it in netman
(the networking part of the man pages)
-Andi
P.S.: rusty, your netwinder arrived. thanks a lot. It will be soon useful:
Russel King told me about some TCP timer bug that occurs on the arm 2.2.12
kernel under high load. As soon as I have a 240V power supply (tomorrow)
I'll start hacking on that.
-- This is like TV. I don't like TV.- 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/