nd(tmp_sock, (struct sockaddr*)&tmp_ip6, sizeof(struct
sockaddr_in6)) == 0 ) {
+
+ debugs(3, 3, "IPv6 TPROXY support detected. Using.");
+shutdown(tmp_sock, SHUT_RDWR);
+return true;
Hmm... that shutdown should be a close(). If not you'll lose the
fil
d(tmp_sock, (struct sockaddr*)&tmp_ip6, sizeof(struct
> sockaddr_in6)) == 0 ) {
> +
> +debugs(3, 3, "IPv6 TPROXY support detected. Using.");
> +shutdown(tmp_sock, SHUT_RDWR);
> +return true;
Hmm... that shutdown should be a close(). I
On Wed, Apr 09, 2008, Henrik Nordstrom wrote:
> ons 2008-04-09 klockan 17:36 +0800 skrev Adrian Chadd:
> > > The ipt_bind call from forward.c should go into comm_openex. Kind of
> > > pointless with the new flag otherwise.. You said you had done this, but
> > > not in the -3 patch...
> >
> > That
ons 2008-04-09 klockan 17:36 +0800 skrev Adrian Chadd:
> > The ipt_bind call from forward.c should go into comm_openex. Kind of
> > pointless with the new flag otherwise.. You said you had done this, but
> > not in the -3 patch...
>
> That was done but I wasn't diff'ing comm.c
Don't forget to rem
On Tue, Apr 08, 2008, Henrik Nordstrom wrote:
> > http://www.creative.net.au/diffs/20080408-tproxy-fix-2.diff
>
> using -3 instead of -2 looks better... but incomplete.
Oops!
Try http://www.creative.net.au/diffs/20080409-squid2-tproxy-4.diff
> You need to add the new ipt_* files to the EXTRA_s
> 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-
ons 2008-04-09 klockan 00:19 +0800 skrev Adrian Chadd:
> On Tue, Apr 08, 2008, Adrian Chadd wrote:
> >
>
> Take 3:
>
> http://www.creative.net.au/diffs/20080408-tproxy-fix-2.diff
using -3 instead of -2 looks better... but incomplete.
You need to add the new ipt_* files to the EXTRA_squid_SOURCE
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 "tproxy"ness; renamed to
enable_spoof_srv
* moved the tproxy "bind" stuff into comm.c, with a flag to comm_openex()
* changed forward.c to
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 no
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-transpa
ies
> needed.. cache.log will now get filled with tons of errors in such
> setups., where you earlier only got a single warning about continuing
> without tproxy support..
Yes, I have to give that a little more thought. I may keep the global but
not call it "linux_tproxy"..
> &g
n the capabilities
needed.. cache.log will now get filled with tons of errors in such
setups., where you earlier only got a single warning about continuing
without tproxy support..
> * pull out the capabilities stuff, removing the last #ifdef LINUX_TPROXY
> from the source
TPROXY both version
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-na
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 th
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 com
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(
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
On Mon, Apr 07, 2008, Henrik Nordstrom wrote:
> I say it shouldn't even be a SERVER_SPOOF define. Make the generic parts
> always compiled, doing nothing if spoofing capabilities is not
> available.
That makes it easier to do then. I'll go off and start doing that to
Squid-2.HEAD.
Adrian
--
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..
G
Henrik Nordstrom wrote:
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 genera
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 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
> manipulati
e classwork and fix the tproxy
support in Squid-2 to show how it should be done..
Adrian
On Mon, Apr 07, 2008, Henrik Nordstrom wrote:
> 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://tre
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, share
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
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 TP
OXY4 uses pretty much the same API.
Earlier TPROXY versions is quite different.
Yes, having clean support for multiple APIs is nice, and for Squid-3 we
should have TPROXY4 + Adrians FreeBSD thing.
If either one want's to spend time on making the older TPROXY support
fit in a such framework
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
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
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
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 fr
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.
>
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 in
> Adrian Chadd wrote:
>> On Wed, Mar 05, 2008, Laszlo Attila Toth wrote:
>>> Okay, I simply add other hunks to squid code as Amos wrote:
- migrate defined LINUX_TPROXY -> LINUX_TPROXY2
- add defined LINUX_TPROXY4
>>
>> Well, LINUX_TPROXY defines a whole bunch of stuff relevant to generic
On Wed, Mar 05, 2008, Laszlo Attila Toth wrote:
> Hm. I don't know what would be the best way, because I am not familiar
> with the squid code. What I know is: TProxy4 requires minimal code
> change. My problem is: where to change and how to use ifdef-ed codes
> (LINUX_TPROXY and the two new: L
Adrian Chadd wrote:
On Wed, Mar 05, 2008, Laszlo Attila Toth wrote:
Okay, I simply add other hunks to squid code as Amos wrote:
- migrate defined LINUX_TPROXY -> LINUX_TPROXY2
- add defined LINUX_TPROXY4
Well, LINUX_TPROXY defines a whole bunch of stuff relevant to generic
"full" transparency
On Wed, Mar 05, 2008, Laszlo Attila Toth wrote:
> >There's a patch in the Squid bugzilla somewhere which implements tproxy
> >support against Squid-2. I'd like to include this into Squid-2, but:
>
> I know this patch, mine is based on it. But that is for tproxy 4.0
Adrian Chadd írta:
On Wed, Mar 05, 2008, Laszlo Attila Toth wrote:
Hello,
We only supports TProxy version 4.1 but in the squid "--enable-tproxy"
requires version 2 which is obsolete for a while.
G'day,
There's a patch in the Squid bugzilla somewhere which implements tp
On Wed, Mar 05, 2008, Laszlo Attila Toth wrote:
> Hello,
>
> We only supports TProxy version 4.1 but in the squid "--enable-tproxy"
> requires version 2 which is obsolete for a while.
G'day,
There's a patch in the Squid bugzilla somewhere which implements tpr
Laszlo Attila Toth wrote:
Hello,
We only supports TProxy version 4.1 but in the squid "--enable-tproxy"
requires version 2 which is obsolete for a while.
Current implementation doesn't require kernel support, only a new socket
option, IP_TRANSPARENT, also I made a patch which drops
"--enabl
Hello,
We only supports TProxy version 4.1 but in the squid "--enable-tproxy"
requires version 2 which is obsolete for a while.
Current implementation doesn't require kernel support, only a new socket
option, IP_TRANSPARENT, also I made a patch which drops
"--enable-tproxy" because TProxy 4.
Hi.
There are two patches in attachment that add new functionality to
squid. Both patches are used in my company.
1.
First patch (file zph_tos_acl.patch) is the extension of patch
available here http://www.it-academy.bg/zph/ used for setting TOS
value dependent of cache HIT/MISS. Attached patch ex
42 matches
Mail list logo
