Re: [PATCH] getsockopt() on netfilter-redirected socket

Andi Kleen (ak@muc.de)
Sun, 3 Oct 1999 22:07:34 +0200

On Sun, Oct 03, 1999 at 09:48:44PM +0200, Patrick Schaaf wrote:
> > > - 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.
>
> I don't know. Right now no part of the kernel knows about SO_ORIGINAL_DST;
> it is a feature of the NAT part of Rusty's netfilter package, which is
> seperately distributed. Unless the intent is to distribute that package
> along with the kernel, putting the #define into kernel headers seems wrong.
>
> On the other hand, if SO_ORIGINAL_DST were declared an integral part of
> the kernel IP implementation, that would be OK. In that case, what about
> making the SOL_IP handling code provide a standard implementation returning
> the same thing as getsockname(), and allowing the netfilter getsockopt
> handling to override that handler? i.e. make the netfilter option registration
> code aware of a 'DECLINE' return value, call the nf_sockopt() code before the
> switch in ip_getsockopt(), and run the standard options (now including
> SO_ORIGINAL_DST) if the nf handler returned e.g. -ENOPROTOPT.
> I'll cook up a patch for that way to run things. If it proves acceptable,
> we might want to extract the "register another sockopt" stuff out of
> netfilter into a more generic location.

Sounds like a good idea. SO_ORIGINAL_DST should be an integral part
of networking with some hooks for netfilter/nat, and on the long term
the kernel could have the generic register sockopt hooks.

>
> While we're here: right now, SO_ORIGINAL_DST is implemented in the NAT
> part of the netfilter code, using information stored in the (supposedly)
> seperate ip_conntrack module. Furthermore, a special check is made
> for the protocol being TCP. I think it would be more intuitive if the
> ip_conntrack module itself were the implementor of SO_ORIGINAL_DST,
> and it would implement it regardless of protocol. Is that feasible?

rusty?

>
> > 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).
>
> Huh? Could you explain that, maybe in private email? I was under the
> impression that with the old transproxy stuff, an ordinary getsockopt()
> would return "the right thing".

The old transparent proxy returned the original destination address in
the unused part of sockaddr_in in accept for TCP sockets. In case of UDP
it returned it in the sockaddr_in passed from recvmsg per packet. For the
TCP case this should be replaced with SO_ORIGINAL_DST, for UDP sockets
SO_ORIGINAL_DST can be implemented for connected sockets, for the generic
case it is cleanest to replace it with a IP control message that can be
passed in msg->msg_control.

-Andi

-- 
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/