Take 2: includes initial modularisation (untested; I'll test it at home
this weekend when I get my tproxy box back online) and configure magic
(with placeholders for tproxy4/freebsd.)
http://www.creative.net.au/diffs/20080408-tproxy-fix-2.diff
TODO:
* pull out the capabilities stuff, removing
tis 2008-04-08 klockan 17:59 +1200 skrev Amos Jeffries:
Currently:
fde::flags::transparent == 'intercept/non-intercept'
fde::flags::tproxy == real-transparent/non-transparent
(new) COMM_TRANSPARENT == real-transparent
Their use is currently good for what they do. A small re-naming
tis 2008-04-08 klockan 14:28 +0800 skrev Adrian Chadd:
Take 2: includes initial modularisation (untested; I'll test it at home
this weekend when I get my tproxy box back online) and configure magic
(with placeholders for tproxy4/freebsd.)
On Tue, Apr 08, 2008, Henrik Nordstrom wrote:
tis 2008-04-08 klockan 14:28 +0800 skrev Adrian Chadd:
Take 2: includes initial modularisation (untested; I'll test it at home
this weekend when I get my tproxy box back online) and configure magic
(with placeholders for tproxy4/freebsd.)
On Tue, 2008-04-08 at 15:15 +0200, Henrik Nordstrom wrote:
tis 2008-04-08 klockan 17:59 +1200 skrev Amos Jeffries:
Currently:
fde::flags::transparent == 'intercept/non-intercept'
fde::flags::tproxy == real-transparent/non-transparent
(new) COMM_TRANSPARENT == real-transparent
tis 2008-04-08 klockan 22:17 +0800 skrev Adrian Chadd:
* make sure upstream/peer-forwarded requests aren't thrown to the tproxy
code.
I read the current code as don't do that; its the behaviour I'd like to
maintain. We can always add the functionality later.
Yes, it is not something
On Tue, Apr 08, 2008, Adrian Chadd wrote:
Take 3:
http://www.creative.net.au/diffs/20080408-tproxy-fix-2.diff
* restored the global flag which indicates tproxyness; renamed to
enable_spoof_srv
* moved the tproxy bind stuff into comm.c, with a flag to comm_openex()
* changed forward.c to try
On Tue, 2008-04-08 at 15:15 +0200, Henrik Nordstrom wrote:
tis 2008-04-08 klockan 17:59 +1200 skrev Amos Jeffries:
Currently:
fde::flags::transparent == 'intercept/non-intercept'
fde::flags::tproxy == real-transparent/non-transparent
(new) COMM_TRANSPARENT == real-transparent
Adrian Chadd wrote:
On Mon, Mar 31, 2008, Alex Rousskov wrote:
What about Adrian plans (if I understood them correctly) to add
TPROXY-like support to FreeBSD but not for TPROXY4-like API? Is that a
good enough reason to continue supporting unsupported TPROXY versions?
The FreeBSD API will be
mån 2008-04-07 klockan 23:11 +1200 skrev Amos Jeffries:
We have come up with a 'final-beta' patch for squid-3 now.
http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch
Just waiting on Laszlo final approval.
Some comments...
There should be a general TPROXY define, shared
In fact, there shouldn't be any LINUX_TPROXY* defines in the main codetree.
There should be a SERVER_SPOOF define which ties in all of the connection
tracking stuff, and a clean cut API for doing TPROXY2/TPROXY4/etc socket
manipulation.
Gah, this makes me want to just ignore more classwork and
tis 2008-04-08 klockan 01:16 +0800 skrev Adrian Chadd:
In fact, there shouldn't be any LINUX_TPROXY* defines in the main codetree.
There should be a SERVER_SPOOF define which ties in all of the connection
tracking stuff, and a clean cut API for doing TPROXY2/TPROXY4/etc socket
manipulation.
Henrik Nordstrom wrote:
tis 2008-04-08 klockan 01:16 +0800 skrev Adrian Chadd:
In fact, there shouldn't be any LINUX_TPROXY* defines in the main codetree.
There should be a SERVER_SPOOF define which ties in all of the connection
tracking stuff, and a clean cut API for doing TPROXY2/TPROXY4/etc
tis 2008-04-08 klockan 09:57 +1200 skrev Amos Jeffries:
But, baby steps people:
- Get it in
- Get it tested.
- Polish into a class.
So far we are at #1
And I won't approve the change of sprinkling #if LINUX_TPROXY4 over the
code, even if it's just adding to the existing #if..
Get
On Tue, Apr 08, 2008, Henrik Nordstrom wrote:
tis 2008-04-08 klockan 09:57 +1200 skrev Amos Jeffries:
But, baby steps people:
- Get it in
- Get it tested.
- Polish into a class.
So far we are at #1
And I won't approve the change of sprinkling #if LINUX_TPROXY4 over the
On Mon, Apr 07, 2008, Amos Jeffries wrote:
We have come up with a 'final-beta' patch for squid-3 now.
http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch
Just waiting on Laszlo final approval.
It's pretty much:
* adding a COMM_TRANSPARENT flag to comm_openex(...)
Adrian Chadd wrote:
On Mon, Apr 07, 2008, Amos Jeffries wrote:
We have come up with a 'final-beta' patch for squid-3 now.
http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch
Just waiting on Laszlo final approval.
It's pretty much:
* adding a COMM_TRANSPARENT flag to
On Mon, Mar 31, 2008, Alex Rousskov wrote:
What about Adrian plans (if I understood them correctly) to add
TPROXY-like support to FreeBSD but not for TPROXY4-like API? Is that a
good enough reason to continue supporting unsupported TPROXY versions?
The FreeBSD API will be almost like the
Between Balabit and TreeNet we have come up with a working TPROXY 4+ patch.
It'll be sent to trunk soon.
The merge It would be a whole lot cleaner and actually less change
overall if we could drop the TPROXY version 2 support from Squid-3.
I know we will likely need to keep the old support
On Tue, Apr 01, 2008, Amos Jeffries wrote:
Between Balabit and TreeNet we have come up with a working TPROXY 4+ patch.
It'll be sent to trunk soon.
The merge It would be a whole lot cleaner and actually less change
overall if we could drop the TPROXY version 2 support from Squid-3.
I
On Tue, 2008-04-01 at 00:18 +1300, Amos Jeffries wrote:
Between Balabit and TreeNet we have come up with a working TPROXY 4+ patch.
It'll be sent to trunk soon.
The merge It would be a whole lot cleaner and actually less change
overall if we could drop the TPROXY version 2 support from
tis 2008-04-01 klockan 00:18 +1300 skrev Amos Jeffries:
The merge It would be a whole lot cleaner and actually less change
overall if we could drop the TPROXY version 2 support from Squid-3.
+1
Regards
Henrik
mån 2008-03-31 klockan 08:26 -0600 skrev Alex Rousskov:
We may be able to provide better comments when we see the current code.
It does not have to be polished and ready for commit.
I see no reason to continue supporting now obsolete and no longer
supported TPROXY versions in new versions of
On Mon, 2008-03-31 at 20:28 +0200, Henrik Nordstrom wrote:
mån 2008-03-31 klockan 08:26 -0600 skrev Alex Rousskov:
We may be able to provide better comments when we see the current code.
It does not have to be polished and ready for commit.
I see no reason to continue supporting now
mån 2008-03-31 klockan 13:31 -0600 skrev Alex Rousskov:
What about Adrian plans (if I understood them correctly) to add
TPROXY-like support to FreeBSD but not for TPROXY4-like API? Is that a
good enough reason to continue supporting unsupported TPROXY versions?
FreeBSD and TPROXY4 uses pretty
25 matches
Mail list logo
