Re: [proxyTools-users] escaping a very restrictive

[wayne <wa...@ny...>]

> From: Michael Foord <Mic...@tb...>
> To: wayne <wa...@ny...>,
>   "pro...@li..." <pro...@li...>
> Subject: Re: [proxyTools-users] escaping a very restrictive
> 
> > [..]
> > >
> > > Checking proxy capabilities ...
> > > send() on closed socket PROXY at statProxy.pl line 1016.
> > > Your vendor has not defined POSIX macro EWOULDBLOCK, used at statProxy.pl line
> > > 1
> > > 017
> >
> > This bug has been fixed. Get a new statProxy.pl
> >
> 
> New version got - localproxy, localproxy2, statproxy, findproxy and the new cgi
> stuff.

****
I updated localProxy2.pl about 0400 GMT. That fix is worth getting.
****

> master.pl returns the same result as last time - all ports `blocked` except 25 and
> 110 which are `open`. 

Sure, it was right. 
I didn't change anything that would affect tests of those two ports.

> Its possible that is partly to allow us to use yahoo messenger
> - annoying as I can`t actually get that to work - lol :-)

Those ports won't help there, but master.pl doesn't test all 65535 
ports, so maybe they have opened up some other odd ones for you.
Around master.pl line 144, you will see the list of ports it checks. 
It would be easy for you to edit any ports you want to be tested 
into there.

> C:\Program Files\localproxy>perl statproxy.pl -t 0 -a ,192.168.0.1:8080,******,
> ****** 192.168.0.1:8080
> Subroutine blocking redefined at statproxy.pl line 82.

I've removed this warning now.

> statProxy v4.104 report from 192.168.4.67:
> 192.168.0.1     :8080  T                    ?/?

That wasn't where your proxy was before.
Has it been changed?

> C:\Program Files\localproxy>
> 
> This was an interesting one !!
> 
> Localproxy now functions ok, picks up the right authentication details from the
> environment variables but still can`t find a way out. Haven`t played with it much
> yet though.... 

If you used that wrong (?) proxy address above, it will never get 
out with commStrat 1.

> haven`t looked at the cgi options yet but was intruiged  by this -
> have I used the right parameters ?

If I remember your setup correctly, it should have got out using 
commStrat 1 (CONNECT). Maybe that's not open any more. 

I didn't enable commStrat 2g (cgi) in the last release. I've just 
done that - get a new commStrats.xml, *or* do it in your own config 
(see the way I do it in config-wayne-ADSL.xml).

***
Megaproxy was too slow, so I changed to using Google translate. That 
one was hard coded into localProxy2.pl in the last release (in fact 
until a few days ago). Unfortunately, the UAE blocked that whole 
translation site a week after my release. :-)
So now it uses altavista translation. 

All of this is in a text file you may edit easily: cgiAmbles.txt

Google was better than Altavista, because with Altavista I can't 
translate English to English (had to use Japanese to English!) and 
some words actually collide with Japanese words apparently. 
The symptoms are that words like netBSD end up as netcBSD and 
'or' becomes 'OR' (no idea why). Like all CGI proxies, there are 
some sites it can't handle. Images are ok. 
Also like all CGI's it rewrites the links, so that when you click 
on them they take you back to the CGI proxy - that's often a 
nuisance when LP has better ways to get to sites. 
A reload of the page (ctrl-refresh, or shift-reload) 
is usually the best way to escape from it; maybe go back a page 
first.
In general, it does what people want, and it's usually much 
faster than commStrats 0 and 1.

In your case, you would want to use Google translate, probably, 
since they have allowed you to get there. Just remove the '#' 
at the beginning of that line in cgiAmbles.txt and put one in 
at the start of the altavista line (LP will only use *one* of 
these - so far).

I've just uploaded the new stuff.

> Mike

--
wa...@ny...
http://proxytools.sourceforge.net/