On Thu, May 23, 2002 at 12:56:58PM +0200, Balazs Scheidler wrote: > > > I see two possibilities: > > > > > > * add a new argument to ip_nat_setup_info() to avoid helpers > > > > seems reasonable. it's only three arguments currently, having four wouldn't > > be a problem. add a 'int flags' argument and define a flag for > > 'BYPASS_HELPER'. > > ok, isn't this api change too intrusive to other netfilter parts? > ip_nat_setup_info() is referenced 11 times on an unpatched 2.4.18.
>From my point of view, Linux kernel API's have always been changing. And a simple one-argument-change doesn't hurt anybody. The patch may contain a huge number of lines (since it's 11 function call changes) - but looking at it from an abstract point of view, there is nothing intrusive about it. > A third solution would be to add new NFCT_ flag. Do you still prefer the > flags argument? no, nfct again looks like a hack. > > > This however wouldn't bypass the conntrack helper [which > > could already say INVALID because a packet doesn't match the layer5+ state > > of the connection, see for example the PPTP helper]. > > Don't forget that we have two conntrack entries if traffic is flown through > a transparent proxy, and conntrack processing is done prior to NAT > rewriting. > > Please tell me if I'm wrong, but CONNTRACK sees an unmodified PORT command > assigned to a session with unmodified destination address. Oh, I didn't make myself clear. There are no bad interactions with NAT. But in case there really is an out-of-state packet, the conntrack helper would mark it INVALID - which might not be what you want in case of transparent proxying, where such state violation should be detected by the proxy itself. > Bazsi -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
