Messages in this thread | | | From | Patrick Schaaf <> | Subject | Re: [PATCH] getsockopt() on netfilter-redirected socket | Date | Sun, 3 Oct 1999 21:48:44 +0200 (MEST) |
| |
> > - 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.
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?
> 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".
best regards Patrick
- 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/
| |