Date: Wed, 22 Aug 2001 06:00:02 -0700 (PDT) From: Peter Pentchev <roam@ringlet.net> To: freebsd-ports@FreeBSD.org Subject: Re: ports/29954: Tircproxy breaks in transparent proxy mode under 4.3R & higher (IP Filter 3.4.x). Message-ID: <200108221300.f7MD02g60298@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/29954; it has been noted by GNATS. From: Peter Pentchev <roam@ringlet.net> To: Michael Nottebrock <nottebrock@crosswinds.net> Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: ports/29954: Tircproxy breaks in transparent proxy mode under 4.3R & higher (IP Filter 3.4.x). Date: Wed, 22 Aug 2001 15:47:03 +0300 On Wed, Aug 22, 2001 at 05:37:16AM -0700, Michael Nottebrock wrote: > > >Number: 29954 > >Category: ports > >Synopsis: Tircproxy breaks in transparent proxy mode under 4.3R & higher (IP Filter 3.4.x). > >Originator: Michael Nottebrock > >Release: 4.3-STABLE > >Organization: > >Environment: > FreeBSD lofi.dyndns.org 4.3-STABLE FreeBSD 4.3-STABLE #8: Wed Jul 11 15:50:34 CEST 2001 root@lofi.dyndns.org:/usr/obj/usr/src/sys/MY > KERNEL i386 > >Description: > Tircproxy, when used in transparent proxy mode, looks up the original destination of the redirected packets in /dev/ipnat. This lookup fails in FreeBSD 4.3R and later because IP Filter 3.4.x expects a different argument to the natlookup ioctrl call than IP Filter 3.3.x. If a connection is made, tircproxy prints out "ioctrl: Bad address" and refuses the connection. > >How-To-Repeat: > Set up a redirection rule in /etc/ipnat.rules like > > 'rdr dc0 0.0.0.0/0 port 6667 -> 127.0.0.1 port 7776' > > and run '/usr/local/sbin/tircproxy -s 7666 -MRH -i <internal-ip>' Then try to connect to an IRC Server from a machine connecting to the proxy via the dc0 interface. > >Fix: > With this patch, the port checks the version of FreeBSD at build time and makes the appropriate calls if the machine is running 4.3R or higher. Great analysis there! However, a compile-time check would break if the port is built on an IPF 3.3.x system, which is later updated to IPF 3.4.x. Granted, this would be a case of improper system administration, but I wonder if a runtime check would not fix it better - check the result of the kern.osreldate sysctl instead of __FreeBSD_version? G'luck, Peter -- If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108221300.f7MD02g60298>