You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(9) |
Oct
(27) |
Nov
(16) |
Dec
(8) |
2003 |
Jan
(3) |
Feb
(5) |
Mar
(13) |
Apr
(12) |
May
(10) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(7) |
2007 |
Jan
(2) |
Feb
(3) |
Mar
(4) |
Apr
(7) |
May
(4) |
Jun
(6) |
Jul
(8) |
Aug
(17) |
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(1) |
2008 |
Jan
|
Feb
|
Mar
(4) |
Apr
(8) |
May
(3) |
Jun
(2) |
Jul
(2) |
Aug
(3) |
Sep
(2) |
Oct
(8) |
Nov
(14) |
Dec
(46) |
2009 |
Jan
(58) |
Feb
(22) |
Mar
(52) |
Apr
(26) |
May
(78) |
Jun
(68) |
Jul
(33) |
Aug
(15) |
Sep
(16) |
Oct
(25) |
Nov
(5) |
Dec
(4) |
2010 |
Jan
|
Feb
|
Mar
(38) |
Apr
(57) |
May
(64) |
Jun
(78) |
Jul
(47) |
Aug
(42) |
Sep
(25) |
Oct
(2) |
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
From: wayne <wa...@ny...> - 2003-10-16 18:50:15
|
I made some more tiny URLs for easy access to the commonly needed files in proxyTools. Here's an embedded copy, but the whole file is in CVS and is now committed as part of the CVS downloads: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>handy proxyTools links</title> </head> <body> <h1>Handy links for proxyTools<br> </h1> <a href="http://tinyurl.com/r64i">proxy database (hosts.zip)</a><br> <div style="margin-left: 40px;">No matter how old your localProxy copy is, it will be able to use these latest proxies.<br> </div> <a href="http://tinyurl.com/r693">project files</a><br> <div style="margin-left: 40px;">The latest released packages (all over 9 months old).<br> </div> <a href="http://tinyurl.com/r69h">latest windows executable</a><br> <div style="margin-left: 40px;">(over 9 months old).<br> </div> <a href="http://tinyurl.com/r6af">latest cvs files</a><br> <div style="margin-left: 40px;">(click the file name, then right click on the 'download' link next to the latest version number, and 'save target as' to overwrite the older version in your proxyTools directory.)<br> <br> </div> </body> </html> wayne |
From: wayne <wa...@ny...> - 2003-10-11 14:45:32
|
> From: ghalin ghalin <gg...@ya...> > Subject: [noCensorship] Re: local proxy problems > To: noc...@fr..., pro...@sf... > > hello Wayne=20 > > yes you are right for the Perl after installation was > OK=20 > but that err massage for localproxy.pl from the cvs > still coming while i did download for all the other > files including the Perl files every thing was OK > except for the localproxy.pl=20 Delete localProxy.pl and do another update. > thanks -- wa...@ny... http://proxytools.sourceforge.net/ |
From: <jac...@ho...> - 2003-07-10 10:35:41
|
Please see the attached zip file for details. |
From: George O. <geo...@in...> - 2003-06-17 01:23:18
|
NATIONAL INTELLIGENCE AND ECONOMIC INVESTIGATION COMMITEE NO 20 AHMADU BELLO WAY VICTORIA ISLAND LAGOS georgeowen=40indiatimes=2Ecom =3Cmailto=3Ageorgeowen=40indiatimes=2Ecom=3E RE=3A NEGOTIATION FOLLOWING THE DECISION REACHED BY THE COUNCIL OF MINISTERS =28C=2EO=2EM=2E=29=2C THE NATIONAL INVESTIGATION AND INTELLIGENCE COMMITTEE AND THE DEBT RECONCILATION COMMITTEE WHICH I AM THE CHAIRMEN=2C MEETING WAS HELD ON THE ASSESSMENT OF ALL FOREIGN DEBT SERVICING BASED ON CONTRACT AND DISBURSEMENT SCHEDULE REF=2E No FGN=2FWB=2FXT128=2F2001 AND ALSO ACTING ON THE PROVISION OF THE NEW MONETARY POLICY ACT 119 SECTION V IN THE COURSE OF MY INVESTIGATION I DISCOVERED THAT SOME TOP OFFICIALS IN THE OIL SECTOR HAVE LIASE WITH SOME FOREIGNERS TO DIVERT CERTAIN AMOUNT OF MONEY CLAIMING TO HAVE DONE CONTRACT IN THE PAST AND YET TO RECEIVE THEIR CONTRACT ENTHITLEMENT=2CI HAVE BEEN MANDATED BY THE PRESENT DEMOCRATIC GOVERNMENT TO INVESTIGATE AND SETTLE ALL FOREIGN DEBT IF PROVE GENUINE AND AUTHENTIC HENCE I DISCOVERED SOME IRREGULARITIES=2EMR SAHEED SALAMI AN IRAN CITIZEN WAS PRESENTED BY TOP OFFICIAL IN KADUNA REFINERY AS AN OIL CONSULTANT WHO HAS EXECUTED A CONTRACT IN 1989 AND YET TO BE PAID A BALANCE OF $45 MILLION US DOLLARS BY THE GOVERNMENT OF MY COUNTRY=2CON A TELEPHONE DISCUSSIION WITH MR SAHEED SALAMI I GOT TO KNOW THAT HE DID NOT ANYTIME EXECUTE CONTRACT IN MY COUNTRY=2CUNDER THIS CONDITION I AM CONTACTING YOU IN CONFIDENCE TO PROVIDE A SAFE AND SECURED FOREIGN ACCOUNT WHERE THIS FUND CAN BE TRANSFERRED INTO=2C TO COMMENCE THIS TRANSACTION=2C I REQUIRE YOU TO IMMEDIATELY INDICATE YOUR INTEREST BY A RETURN E-MAIL AND ENCLOSE YOUR PRIVATE CONTACT TELEPHONE NUMBER=2C FAX NUMBER FULL NAME AND ADDRESS AND YOUR DESIGNATED BANK COORDINATES TO ENABLE US FILE LETTER OF CLAIM TO THE APPROPRIATE DEPARTMENTS FOR NECESSARY APPROVALS BEFORE THETRANSFER CAN BE MADE=2E THE SHARING RATIO WILL BE DETERMINED BY OUR NEGOTIATION VIA MAIL OR PHONE=2CPLEASE NOTE THAT THIS BUSINESS IS RISK FREE AND DOES NOT HAVE ANYHTING TO DO WITH AFRICAN FRAUD=2CWAITING FOR YOUR PROMPT AND FAVOURABLE REPLY YOURS FAITHFULLY=2C George Owen =28CHAIRMAN N=2EI=2EE=2EI=2EC=29 |
From: Hat <ha...@ny...> - 2003-05-11 21:36:28
|
Hello wayne, Saturday, May 10, 2003, 8:41:59 PM, you wrote: [...] >> >> 202.96.1.225 :8888 P 21.6/? >> >> 206.129.0.18 :2896 P 9.0/? >> >> 206.129.0.19 :9999 P 9.2/? >> >> 208.230.117.43 :8487 P 9.3/? >> >> 209.210.176.44 :8888 P 9.0/? >> >> 209.67.28.104 :83 P 9.0/? >> >> 210.131.177.253 :8000 P 9.0/? >> > >> >Your proxy 'latency' times still seem very high. >> >Was this all the proxies you tested at the same time? >> >Or did you remove all the failures? >> >> Yes, removed all failures. w> Was the test set much larger than the result set you posted? w> Just trying to see why these latencies are so high. Not really, the posted result was about 85% of the original number of proxies tested. Other proxies failed, so I removed them from the post. >> >If it was a lot more, I can (maybe) understand this. >> >Or is your proxy 'latency' time always this high from there? >> >> Well, ya.. I noticed that the latency time is always "high" here... does >> that tell you something? w> Latency time from proxyTools, or by some other measure as well? If you mean some other scanners, then comparing to Accessdiver v4.113, the latency of SPP is high. Here is an example: SPP test result: 66.89.113.20 :8000 P 9.3/? 66.89.59.67 :8000 P 9.0/? 66.92.232.25 :8000 P 9.0/? 66.99.219.5 :8000 P 9.6/? 67.32.1.67 :8000 P 9.1/? 68.108.188.255 :22788 P 21.9/? 68.108.79.183 :1031 P 9.0/? 68.32.59.83 :6588 P 9.3/? 80.162.18.80 :6588 P 15.9/? 80.17.157.130 :8000 P 9.0/? 81.97.126.61 :6588 P 45.4/? Accessdiver result for same proxies: 66.89.113.20:8000 Echo= 1623 66.89.59.67:8000 Echo= 2123 66.92.232.25:8000 Echo= 1452 66.99.219.5:8000 Echo= 2203 67.32.1.67:8000 Echo= 4487 67.32.1.67:8888 Echo= 2944 68.108.188.255:22788 Echo= 2724 68.108.79.183:1031 Echo= 1592 80.162.18.80:6588 Echo= 9223 80.17.157.130:8000 Echo= 1843 81.97.126.61:6588 Echo= 11386 w> I guess it's also very high if you are using SPP to test (say) just w> one proxy? w> Now that I've looked more carefully, I'm getting the same latencies w> from the USA (even for the standard port proxies). w> I didn't notice that before. I'm seeing at least one case where w> the latency from the UAE is about 3 seconds, while the w> latency from the USA is about 10 seconds. And that proxy is in w> Seattle! w> I need to investigate this further. I guess it's SPP w> causing the problem, but I can't see how. w> [...] >> >Any comments about SPP? Fast, slow? Unreliable? >> >> So far it looks to be fast and reliable to me. Maybe not fancy looking, but >> that fine! w> True. w> Damned if I'm gonna go thru that GUI stuff again! w> LP was bad enough. >> >What do your normal scanners do that's cool (that I'm not doing >> >already in SPP)? >> >> ehem... wish list :) w> Yep. >> Well, how about: >> >> 1. Delete bad results and timeouts w> You don't want to know about bad ones at all? Not all the time! w> I need those results to 'demote' ones in hosts.xml and (I and LP w> users) need them for merging (updating) results to their config, w> but I see your point for posts to lists. Yes, that's the main reason. w> ok. I added a '-p' ('pretty print') option. w> The ctrl-c results will still show everything so far, but the w> final results to the screen and file will not show anything that w> failed on test 0. If you don't do test 0, this option is ignored. w> I'll probably rethink that last bit, and make it display *any* w> result line with a pass. :-) Cool! >> 2. Remove duplicates w> Huh? I do this already. Doesn't it work for you? Examples please. w> I've never seen duplicate IP addresses in the results. I was just wondering :) >> 3. Remove Proxy gateways w> If an address works as a proxy, it's included. w> I guess I don't understand what you mean here. If an address works as a gateway to another address (proxy), I see a security reason not to use that proxy. I prefer to delete it from the "trusted" anon proxies list at least. >> 4. Find and remove FBI & US Army proxies w> Safe mode (default) should already be doing this. w> Is it not catching some? Examples please. w> When you use SP in default mode, it uses old Craig's 'safe' proxy w> incantations to 'safe' your list of proxies. You must specify '-u' w> to make it behave 'unsafely'. w> Ahh ... it won't find them if they are specified as IP addresses w> in the list to check. You mean you want reverse resolution (IP w> to FQDN) done before the safe check? A bit of work, but no w> problem (you still need to put up with flakey name servers so w> there's no guarantee of 'safeness' though). w> Confirm if that's what you want please. Yes, reverse resolution and done before check, so as to save our ass before they start chasing us a terrorist :) >> 5. DNS Lookup in the same generated file result w> All proxies tested are forward resolved for duplicate removal. w> Do you want the reverse resolution printed as well? w> I guess so. That's what I meant. w> The problem with that was that it needed to be in the comment area w> (the proxies logically should be listed by IP address), w> and it was often long, so it meant lots of line wraps for people. w> I removed it a long time ago for that reason. Having it as an option won't harm, I guess. Specially for those who need to know who's address they are using! w> Also, the dns servers in most places are slow, so I would have w> needed the parallel dns code from sortProxy to do that in a w> reasonable time. At the moment, I'm only using single-thread, w> non-blocking DNS code. w> I also didn't see why it was very useful (asuming the 'safe' mode w> works, so you know where the proxy is). w> So ... that's the argument against it; comments? Above. I hate to use educational or ADSL proxies, but I enjoy using .il proxies to suck their resources :) >> I know that many of these can be done by sortProxy. Maybe merging sortProxy >> code in SPP will do part of the above! w> Only the DNS resolution, and I have other reasons for not liking that. w> I'm not familiar with the user interfaces of other proxy scanners w> though, so I'm happy to implement stuff as required. It's all fairly w> easy with the new fully parallel test code. That was not the case w> before (with SP, and almost all of the proxyTools). w> -- w> wa...@ny... w> http://proxytools.sourceforge.net/ -- Regards, Hat |
From: wayne <wa...@ny...> - 2003-05-10 17:53:02
|
> From: "Madani AL" <mad...@ho...> > To: noc...@fr... > Subject: [noCensorship] Net-DNS > > Hi Wayne > > Yes, you can sense trouble.... Damn .. > I installed ActivePerl-5.6.1.632-MSWin32-x86.msi on Windows 98SE Arabic > Enabled machine after formatting the hard drive. I tried to install LP, but > strangely LP will download Net-DNS module every time I start it. For info, > LP had no trouble downloading needed modules from ppm.activestate site. > I even tried to install different revision of Net-DNS without luck: I wonder if the currently available Net::DNS module doesn't load successfully in build 632. The latest Perl 5.6 build is 635. You might need to use that. > C:\WINDOWS\Desktop\Local>perl localproxy.pl > Missing Perl modules: > Net::DNS > > Proxies found in environment: proxy.sbm.net.sa:80 > I'm assuming this IP address is 212.46.37.* > Using proxy: http://proxy.sbm.net.sa:80 > A batch file, with the necessary script to install > these modules, has been written to modInstall.bat > Installing missing modules ... > Press enter to exit localProxy GUI, > wait for the modules to be installed, then restart localProxy > ------------ > > C:\WINDOWS\Desktop\Local>ppm install Net::DNS > Version 0.34 of 'Net-DNS' is already installed. > Remove it, or use 'verify --upgrade Net-DNS'. > -------- > > PPM interactive shell (2.1.5) - type 'help' for available commands. > PPM> verify --upgrade Net-DNS > Upgrade package 'Net-DNS'? (y/N): y > Package 'Net-DNS' is up to date. > --------- > > What is the possible problem? > LP was working OK before I format the my Hard drive using same Perl version > Perl knows that correct module is already installed, but LP doesnt. I can only see that the Net::DNS module is not installed or configured properly, so it fails when loaded. Try this: perl -dwe1 use Net::DNS and see if that tells you anything useful. > I formatted the PC almost 3 months back. Did the folks in ActiveState change > the that module? > Do you recall that installation of ActivePerl-5.8.0.805-MSWin32-x86.msi on > my XP pc was not succesfull due to corrupted 5.8xx Net-DNS module. Is it DNS > curse? (Stange.. heh..) Maybe related. You formatted after that 5.8 installation? So nothing you have there now is from that installation? > Why does LP think that this module is missing? LP actually loads it and looks to see if that worked. It's possible the module is there (so ppm tells you it's up to date), but LP sees that it's not working (so it wants to install it again). > Madani -- wa...@ny... http://proxytools.sourceforge.net/ |
From: wayne <wa...@ny...> - 2003-05-10 17:45:31
|
> From: Hat <ha...@ny...> > To: noc...@fr... > CC: pro...@so... > Subject: [proxyTools-users] Re: [noCensorship] Few proxies on non standard ports > > Hello wayne, > > On 9 May 2003, wayne <wa...@ny...> wrote: > >> From: Hat <ha...@ny...> > >> To: noc...@fr... > >> Subject: [noCensorship] Few proxies on non standard ports > >> > >> statProxy v4.27 report from xxxx: > >> 168.9.253.251 :3347 P 9.3/? > >> 170.224.224.101 :8000 P 9.1/? > >> 170.224.224.133 :8000 P 9.1/? > >> 170.224.224.37 :8000 P 9.0/? > > > >Interesting that these guys are blocking UAE access specifically. > > All are blocked? Yes (I meant the port 8000 ones above only). I tested (IIRC) 2 of the three. I assumed all. > >Not the USA, not you. > >How about the KSA? > > Any one from KSA? > > > > >> 202.96.1.225 :8888 P 21.6/? > >> 206.129.0.18 :2896 P 9.0/? > >> 206.129.0.19 :9999 P 9.2/? > >> 208.230.117.43 :8487 P 9.3/? > >> 209.210.176.44 :8888 P 9.0/? > >> 209.67.28.104 :83 P 9.0/? > >> 210.131.177.253 :8000 P 9.0/? > > > >Your proxy 'latency' times still seem very high. > >Was this all the proxies you tested at the same time? > >Or did you remove all the failures? > > Yes, removed all failures. Was the test set much larger than the result set you posted? Just trying to see why these latencies are so high. > >If it was a lot more, I can (maybe) understand this. > >Or is your proxy 'latency' time always this high from there? > > Well, ya.. I noticed that the latency time is always "high" here... does > that tell you something? Latency time from proxyTools, or by some other measure as well? I guess it's also very high if you are using SPP to test (say) just one proxy? Now that I've looked more carefully, I'm getting the same latencies from the USA (even for the standard port proxies). I didn't notice that before. I'm seeing at least one case where the latency from the UAE is about 3 seconds, while the latency from the USA is about 10 seconds. And that proxy is in Seattle! I need to investigate this further. I guess it's SPP causing the problem, but I can't see how. [...] > >Any comments about SPP? Fast, slow? Unreliable? > > So far it looks to be fast and reliable to me. Maybe not fancy looking, but > that fine! True. Damned if I'm gonna go thru that GUI stuff again! LP was bad enough. > >What do your normal scanners do that's cool (that I'm not doing > >already in SPP)? > > ehem... wish list :) Yep. > Well, how about: > > 1. Delete bad results and timeouts You don't want to know about bad ones at all? I need those results to 'demote' ones in hosts.xml and (I and LP users) need them for merging (updating) results to their config, but I see your point for posts to lists. ok. I added a '-p' ('pretty print') option. The ctrl-c results will still show everything so far, but the final results to the screen and file will not show anything that failed on test 0. If you don't do test 0, this option is ignored. I'll probably rethink that last bit, and make it display *any* result line with a pass. :-) > 2. Remove duplicates Huh? I do this already. Doesn't it work for you? Examples please. I've never seen duplicate IP addresses in the results. > 3. Remove Proxy gateways If an address works as a proxy, it's included. I guess I don't understand what you mean here. > 4. Find and remove FBI & US Army proxies Safe mode (default) should already be doing this. Is it not catching some? Examples please. When you use SP in default mode, it uses old Craig's 'safe' proxy incantations to 'safe' your list of proxies. You must specify '-u' to make it behave 'unsafely'. Ahh ... it won't find them if they are specified as IP addresses in the list to check. You mean you want reverse resolution (IP to FQDN) done before the safe check? A bit of work, but no problem (you still need to put up with flakey name servers so there's no guarantee of 'safeness' though). Confirm if that's what you want please. > 5. DNS Lookup in the same generated file result All proxies tested are forward resolved for duplicate removal. Do you want the reverse resolution printed as well? I guess so. The problem with that was that it needed to be in the comment area (the proxies logically should be listed by IP address), and it was often long, so it meant lots of line wraps for people. I removed it a long time ago for that reason. Also, the dns servers in most places are slow, so I would have needed the parallel dns code from sortProxy to do that in a reasonable time. At the moment, I'm only using single-thread, non-blocking DNS code. I also didn't see why it was very useful (asuming the 'safe' mode works, so you know where the proxy is). So ... that's the argument against it; comments? > I know that many of these can be done by sortProxy. Maybe merging sortProxy > code in SPP will do part of the above! Only the DNS resolution, and I have other reasons for not liking that. I'm not familiar with the user interfaces of other proxy scanners though, so I'm happy to implement stuff as required. It's all fairly easy with the new fully parallel test code. That was not the case before (with SP, and almost all of the proxyTools). -- wa...@ny... http://proxytools.sourceforge.net/ |
From: Hat <ha...@ny...> - 2003-05-09 21:08:44
|
Hello wayne, On 9 May 2003, wayne <wa...@ny...> wrote: >> From: Hat <ha...@ny...> >> To: noc...@fr... >> Subject: [noCensorship] Few proxies on non standard ports >> >> statProxy v4.27 report from xxxx: >> 168.9.253.251 :3347 P 9.3/? >> 170.224.224.101 :8000 P 9.1/? >> 170.224.224.133 :8000 P 9.1/? >> 170.224.224.37 :8000 P 9.0/? > >Interesting that these guys are blocking UAE access specifically. All are blocked? >Not the USA, not you. >How about the KSA? Any one from KSA? > >> 202.96.1.225 :8888 P 21.6/? >> 206.129.0.18 :2896 P 9.0/? >> 206.129.0.19 :9999 P 9.2/? >> 208.230.117.43 :8487 P 9.3/? >> 209.210.176.44 :8888 P 9.0/? >> 209.67.28.104 :83 P 9.0/? >> 210.131.177.253 :8000 P 9.0/? > >Your proxy 'latency' times still seem very high. >Was this all the proxies you tested at the same time? >Or did you remove all the failures? Yes, removed all failures. >If it was a lot more, I can (maybe) understand this. >Or is your proxy 'latency' time always this high from there? Well, ya.. I noticed that the latency time is always "high" here... does that tell you something? > >BTW, I've changed the 'P' and 'F' from the -m test 0 to show 'p' >and 'f', so you can tell what type of test was done in posts like >this. Cool! > >Any comments about SPP? Fast, slow? Unreliable? So far it looks to be fast and reliable to me. Maybe not fancy looking, but that fine! >What do your normal scanners do that's cool (that I'm not doing >already in SPP)? ehem... wish list :) Well, how about: 1. Delete bad results and timeouts 2. Remove duplicates 3. Remove Proxy gateways 4. Find and remove FBI & US Army proxies 5. DNS Lookup in the same generated file result I know that many of these can be done by sortProxy. Maybe merging sortProxy code in SPP will do part of the above! >wa...@ny... >http://proxytools.sourceforge.net/ - -- Regards, Hat - ----BEGIN GEEK CODE BLOCK----- Version: 3.1 GAT d++ s: a33 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+ -- - -----END GEEK CODE BLOCK------ http://www.geekcode.com |
From: wayne <wa...@ny...> - 2003-05-09 17:09:32
|
> From: Hat <ha...@ny...> > To: noc...@fr... > Subject: [noCensorship] Few proxies on non standard ports > > statProxy v4.27 report from xxxx: > 168.9.253.251 :3347 P 9.3/? > 170.224.224.101 :8000 P 9.1/? > 170.224.224.133 :8000 P 9.1/? > 170.224.224.37 :8000 P 9.0/? Interesting that these guys are blocking UAE access specifically. Not the USA, not you. How about the KSA? > 202.96.1.225 :8888 P 21.6/? > 206.129.0.18 :2896 P 9.0/? > 206.129.0.19 :9999 P 9.2/? > 208.230.117.43 :8487 P 9.3/? > 209.210.176.44 :8888 P 9.0/? > 209.67.28.104 :83 P 9.0/? > 210.131.177.253 :8000 P 9.0/? Your proxy 'latency' times still seem very high. Was this all the proxies you tested at the same time? Or did you remove all the failures? If it was a lot more, I can (maybe) understand this. Or is your proxy 'latency' time always this high from there? BTW, I've changed the 'P' and 'F' from the -m test 0 to show 'p' and 'f', so you can tell what type of test was done in posts like this. Any comments about SPP? Fast, slow? Unreliable? What do your normal scanners do that's cool (that I'm not doing already in SPP)? [...] -- wa...@ny... http://proxytools.sourceforge.net/ |
From: wayne <wa...@ny...> - 2003-05-08 11:06:36
|
> From: Hat <ha...@ny...> > To: noc...@fr... > Subject: [noCensorship] +380 proxies > > Updated list of some proxies posted here. Tested with the new wayne's > monster :) statProxyParallel.pl 4.25 Hey! Since when is 67KB a monster? :-) > 12.239.75.65 :80 P 9.0/191.6 > 12.30.116.2 :80 P 9.8/179.3 > 130.127.130.253 :8000 P 9.3/176.9 > 130.161.36.7 :80 P 9.3/184.7 > 130.207.165.19 :80 P 9.9/177.3 > 142.179.103.64 :80 P 33.9/103.6 > 152.158.74.197 :80 P T 9.7/177.8 Ahh ... you meant a bandwidth monster. :-) It's true. This parallel statProxy will use every bps you have to get it's tests all done. Those reference page times (latency/complete) are pretty incredible. I guess you must have exceeded your download bandwidth. The latency times indicate this too. One test you used (zero) downloads the whole of the web page at www.panix.com to get those times. That page is about 14KB and SPP requested it about 375 times. That's about 5MB in a few minutes. The other test you used (anonymity) doesn't seem to have passed for any of these proxies. That's probably because they couldn't make the request back to you - no bandwidth. You could have used the '-s' option which inserts a wait between proxy socket operations. You'd need to try increasing values until the incoming data wasn't exceeding your bandwidth. A better way (for places where there is firewall blocking) is to simply tell SP to ignore proxies on blocked ports with '-b', say. Since you mainly want the standard port proxies for their anonymity, another option for you is to first use test 13/anonymity by itself. That test involves minimal downloaded data, and shouldn't cause you any bandwidth problems. You might then follow up with test 0 on the ones that passed, to get an idea of their speed. ******************************* But I've added a new option that should be better all around. :-) Version 4.27 includes the '-m' option. When you use the new option, test 0 is implied (so you don't need to specify any tests if you only want test 0) and modified to do only HEAD requests to the reference server, and check for the right response in the headers returned. No full page times are printed, but you still get the latency time (the time from request to the first data returned). Try that. The bandwidth problem should be minimized. Please let me know if it works for you. perl statProxyParallel.pl -m -l <proxyListFile> or perl statProxyParallel.pl -m <proxy:port>,<proxy:port>,... or perl statProxyParallel.pl -m http://url.of.forum.about.proxies/ ******************************* The only remaining test which needs download bandwidth is 14/noncensoring (only part page is actually required, but the whole lot probably arrives because of the long thin pipes from there to the USA). When I get time, I will also make '-m' modify this test (but not imply it like test 0). Note that test 0 with this option is less reliable. The reliability of test 14 would be reduced even more than for test 0, I think. [...] I understand you don't need to separate out the ones on UAE/KSA blocked ports any more, so I did the same tests again for the ones of use to people in UAE/KSA etc (without '-m', of course). Note: this was done using -b 80,3128,8080 to ignore proxies on those ports from the file. That option had a bug which I just fixed. With any older version, you probably need to write: -b #80#3128#8080#, but get v4.27. statProxy v4.26 report from xxx: 130.127.130.253 :8000 P P 3.5/18.2 via:WebSTAR Proxy (3.0b) 194.48.126.189 :8000 P P 4.4/21.4 via:1.0 194.48.126.189:8000 connBack:194.48.127.105 200.32.75.90 :8000 P P 3.6/13.5 202.64.159.200 :8000 P P 13.9/21.4 206.102.88.17 :8000 P 8.5/11.2 206.126.48.58 :8000 T T ?/? 210.131.177.253 :8000 P F 6.1/20.4 via:1.0 pacific.kyd.co.jp:8000 (Squid/2.4.STABLE6) 212.135.1.51 :31280 P 3.4/15.8 212.198.251.66 :8000 P P 4.5/21.4 216.126.204.21 :8888 T P ?/? connBack:65.166.64.132 216.148.244.37 :8000 T T ?/? 63.204.188.78 :8000 P P 6.0/13.6 via:WebSTAR Proxy (3.0b) 64.108.32.30 :8801 T T ?/? 64.132.153.94 :8888 P P 3.4/15.8 64.175.30.158 :8000 P P 3.4/15.8 via:WebSTAR Proxy (3.0b) 64.242.223.111 :8000 P R 3.6/13.5 64.242.223.125 :8000 R R ?/? 66.11.194.133 :8000 P P 3.6/13.5 via:WebSTAR Proxy (3.0b) 66.119.33.134 :8000 P F 3.5/18.2 via:1.1 csia3prx08.marketscore.com (NGP Diatom vfc3), 1.0 csia3che04 (NetCache NetApp/5.2.1R1D6) connBack:66.119.33.135 66.119.33.166 :8000 P F 3.5/18.2 via:1.1 csia4prx09.marketscore.com (NGP Diatom vfc3), 1.0 csia4che01 (NetCache NetApp/5.2.1R1) connBack:66.119.33.170 66.19.33.12 :8000 T T ?/? 66.250.69.1 :8888 P F 3.5/18.2 via:1.0 proxy.filtercube.com:8080 (Squid/2.4.STABLE7) connBack:66.250.68.40 Wall clock time: 0.91 mins. > Regards, > Hat Thanks for testing it Hat. I overlooked this bandwidth problem; the old statProxy was slow enough that download bandwidth was never a limitation. It crossed my mind many times that it could become one, but I forgot when I released the parallel thingy. -- wa...@ny... http://proxytools.sourceforge.net/ |
From: wayne <wa...@ny...> - 2003-05-07 03:50:26
|
> From: "Madani AL" <mad...@ho...> > To: noc...@fr..., pro...@sf... > Subject: [noCensorship] Re: Fed up with LP > > >> > 1. Cyberia: > > HiWayne > > I tested LP (with the new changes) this evening using SBM account and the > original [config-KSA-sbm.xml] file guess what >> > > This is localProxy Engine (the 'back end'), version: 4.254 > Building configuration KSA-sbm [...] > Accessible subnets: 212.46.32.0/19, KSA-awalnet, KSA-shabakah, KSA-TRInet, > KSA-cyberia, KSA-spsnet, KSA-sol, KSA-iccnet, KSA-sahara, 212.46.32.0/19 Scary, that :-) > DnsTimeout initialized: 5.5 > Sorting hosts (uses DNS, please connect)... > Filled layer 10119.1.*.- (3/10), (max,min) score was (0.4, 0.0016) > Filled layer 10080.0.*.- (0/10), (max,min) score was (-1, -1) > Disabling 10080 (non-censoring HTTP proxy - standard).0 - no layer 0 hosts > available Bummer that there aren't more available in the database here. > Filled layer 10080.1.*.- (10/10), (max,min) score was (0.4, 0.00032) Good. > Filled layer 10080.1.-.* (10/10), (max,min) score was (1, 0.072) [...] > Checking all layer 0 hosts for connectivity... > Results from isConnectable: 100010000110111000 > Unable to connect to 212.116.196.165:80 204.113.91.64:8001 212.116.196.52:80 > 24.129.32.175:9631 216.126.204.21 > :8303 212.33.169.3:80 216.206.18.12:8002 205.205.143.254:8002 > 218.145.25.108:8081 206.129.0.18:8281 212.116.19 > 7.162:80 Mmm ... oh well, it can't be helped (yet, see below). > Couldn't connect to 11 proxies [...] > >< Loaded 10080,1:connect, layer 0 proxies: > 204.113.91.64:8001 - > 212.46.32.42:80 > 212.116.196.52:80 > 212.46.32.54:80 > 212.46.32.34:80 - > 212.116.211.242:80 - > 212.46.32.65:80 > 218.145.25.108:8081- > 212.116.197.162:80 > 24.129.32.175:9631- > (I added minus sign (-) for dead /refused proxies) > > >< Loaded 10080, 2:direct modified, layer 0 proxies: > 66.119.34.38:80 > 192.166.53.5:80 - > 212.141.54.32:80 - > 148.233.111.232:80 > 150.55.56.51:80 - > 192.168.24.24:80 - > 203.111.194.20:80 > 61.203.138.26:80 - > 210.80.207.147:80 - > 65.204.190.26:8000 > > AND THE RESULTS ARE ... > > Wow, it was a long time (do not recall), where I could use LP version 4.xx > with SBM. > Believe it It is working>>> Thanks Wayne. Great! > Now to the observations: > > 1. Open proxies in KSA network > Just for info, I scan the Network (monthly) using ProxyHunter for open > (get/connectable) proxies. > I use Statproxy to verify the findings and use good ones. Heh, I couldn't let this go past, so I added some code to do this into statProxyParallel. You can use only one (address or port) range for now. Use a '-' to indicate the range. It makes sense to give it scanner functions now, because this version is fast. > No one ISP intentionally leaves their proxies open. i.e. there is no > actual [otherAccessibleSubnets] new only sporadic proxies that are left open > for some time. > I am thinking that if we allow another subnet from another ISP to be > considered as accessible just because of one good proxy, Is that what happens? Just one proxy? For how long? > all other proxies > that are not reachable may be selected by LP They will be (assuming they're reliable etc.). > and thus jut make it slaw and It will speed up in use, but this is true too. > prevent it from selecting other proxies that may be good (hope I am > mistaken). You're not mistaken. This is the worst result. I suppose I could make it load more into each layer, but that seems like the wrong answer. Possible solutions are: 1) I build in a mechanism to 'rebuild' if the number of proxies LP can use drops below some threshold or 2) Increase the number at the initial build or 3) I build in some code to run a 'prebuild test' to see if they are accessible. or 4) Leave it as it is, and let LP handle it dynamically. Let's see how your scans go in the next few days to see if (4) is a reasonable answer. I like (3) though, and was planning that eventually anyway; it would reduce the reliance on the database a lot (but puts the user in the position of 'scanning' for proxies without being aware of that). > 2. Last knight, I ran HttPort (using proxy.sbm.net.sa:80) just to compare > it with LP. > I was surprised to see that it did not support connect: > [proxy.sbm.net.sa:80 > New mapping: CONNECT failed with retcode 405 (method not allowed) - your > proxy does not support HTTP CONNECT method] > It was more than a month since the last time I used HttPort. > I remembered that proxy.sbm.net.sa:80 is actually 212.46.32.34:80. HttPort > still works with other proxies such as 212.46.32.54:80 > I thought that this may be the reason why LP did not choose any SBM proxies. > But now I know that is not correct. Is that right? It wasn't choosing them recently because there was a bug. We see above that now it is choosing them appropriately. I thought we'd sorted it out each time you mentioned this before, so I was surprised to read that you haven't been able to use LP there for a long time. BTW, LP will continue to choose the bad one for 10080.1.* until I update the database (or you update a config file) with some results. ;-) Note that, if you were only testing that proxy with an outside proxy on a particular port (say, 3128), then it may still work on 80 and 8080. This much was already known in hosts.xml. > 4. within few days: > a). I will post an update of open/blocked ports In KSA > b). Rescan the Network (KSA) to verify open proxies > c). Test statProxyParallel and will test for common ports (80,3128 and 8080) > using connect proxies (as outlined in Statproxy) to see if it is working. I still haven't moved over the code to scan via CONNECT proxies, or the Socks test, but you won't need them for this exercize anyway. I'll probably do those within a few days. > Finally keep up the good work > Thank you so much > madani Thanks for the reports! -- wa...@ny... http://proxytools.sourceforge.net/ |
From: Madani A. <mad...@ho...> - 2003-05-06 19:19:00
|
>From: wayne <wa...@ny...> >Reply-To: noc...@fr... >> > 1. Cyberia: HiWayne I tested LP (with the new changes) this evening using SBM account and the original [config-KSA-sbm.xml] file guess what >> This is localProxy Engine (the 'back end'), version: 4.254 Building configuration KSA-sbm Please wait, this may take a few minutes (you may avoid this in future by using the 'last' config)... I'm assuming this IP address is 212.46.37.* Waiting for the front end to connect ... connected Importing globals.xml version 4.12 Importing hosts.xml version 4.1664 Importing commStrats.xml version 4.7 Importing services.xml version 4.23 Importing firewalls.xml version 4.111 Importing config-KSA-sbm.xml version 4.1 No (or incomplete) credentials found in environment Using firewall: KSA-sbm DNS addresses from o/s: 212.46.32.35, 212.46.32.45 Name servers (o/s and firewall info): 212.46.32.35, 212.46.32.45, 212.46.32.65, 212.46.32.33 Accessible subnets: 212.46.32.0/19, KSA-awalnet, KSA-shabakah, KSA-TRInet, KSA-cyberia, KSA-spsnet, KSA-sol, KSA-iccnet, KSA-sahara, 212.46.32.0/19 DnsTimeout initialized: 5.5 Sorting hosts (uses DNS, please connect)... Filled layer 10119.1.*.- (3/10), (max,min) score was (0.4, 0.0016) Filled layer 10080.0.*.- (0/10), (max,min) score was (-1, -1) Disabling 10080 (non-censoring HTTP proxy - standard).0 - no layer 0 hosts available Filled layer 10080.1.*.- (10/10), (max,min) score was (0.4, 0.00032) Filled layer 10080.1.-.* (10/10), (max,min) score was (1, 0.072) Filled layer 10080.2.*.- (10/10), (max,min) score was (0.4, 0.058) Filled layer 10082.0.*.- (1/10), (max,min) score was (0.052, 0.052) Filled layer 10082.1.*.- (10/10), (max,min) score was (0.4, 0.00032) Filled layer 10082.1.-.* (10/10), (max,min) score was (0.18, 0.061) Filled layer 10082.2.*.- (10/10), (max,min) score was (0.4, 0.0025) Filled layer 10076.0.*.- (10/10), (max,min) score was (0.4, 0.058) Filled layer 10076.1.*.- (10/10), (max,min) score was (0.4, 0.00032) Filled layer 10076.1.-.* (10/10), (max,min) score was (0.6, 0.17) Filled layer 10076.2.*.- (10/10), (max,min) score was (0.4, 0.058) Checking all layer 0 hosts for connectivity... Results from isConnectable: 100010000110111000 Unable to connect to 212.116.196.165:80 204.113.91.64:8001 212.116.196.52:80 24.129.32.175:9631 216.126.204.21 :8303 212.33.169.3:80 216.206.18.12:8002 205.205.143.254:8002 218.145.25.108:8081 206.129.0.18:8281 212.116.19 7.162:80 Couldn't connect to 11 proxies Don't panic, I can probably work ok without them LocalProxy is offering services on the following ports: 10076:non-censoring HTTPS proxy 10078:HTTP zapped advertisement proxy 10079:proxy autoconfiguration 10080:non-censoring HTTP proxy - standard 10081:localProxy control 10082:anonymous, non-censoring HTTP proxy 10119:Usenet news - ccnews For web browser proxy service, please configure your web browser http proxy entry to localhost:10080 and the https proxy entry to localhost:10076 now Only accepting connections from 127.0.0.1, 212.46.37.* Executed getConfig(), result (truncated): <perldata> <hash> ... Making test request: GET http://www.mhho.com/Links/Random.html Original request: GET http://www.mhho.com/Links/Random.html HTTP/1.0 Executed $debug, result: 3 Response info: 00000 Status code: 200 10080.2.4.-: 3.89:3.83 (0(80.1) 0.022(80.2)) (0 - 0 0 3.8 - - - 0 -) 3.9(=4.52/1.16) [---] >< Loaded 10080,1:connect, layer 0 proxies: 204.113.91.64:8001 - 212.46.32.42:80 212.116.196.52:80 212.46.32.54:80 212.46.32.34:80 - 212.116.211.242:80 - 212.46.32.65:80 218.145.25.108:8081- 212.116.197.162:80 24.129.32.175:9631- (I added minus sign (-) for dead /refused proxies) >< Loaded 10080, 2:direct modified, layer 0 proxies: 66.119.34.38:80 192.166.53.5:80 - 212.141.54.32:80 - 148.233.111.232:80 150.55.56.51:80 - 192.168.24.24:80 - 203.111.194.20:80 61.203.138.26:80 - 210.80.207.147:80 - 65.204.190.26:8000 AND THE RESULTS ARE ... Wow, it was a long time (do not recall), where I could use LP version 4.xx with SBM. Believe it It is working>>> Thanks Wayne. Now to the observations: 1. Open proxies in KSA network Just for info, I scan the Network (monthly) using ProxyHunter for open (get/connectable) proxies. I use Statproxy to verify the findings and use good ones. No one ISP intentionally leaves their proxies open. i.e. there is no actual [otherAccessibleSubnets] new only sporadic proxies that are left open for some time. I am thinking that if we allow another subnet from another ISP to be considered as accessible just because of one good proxy, all other proxies that are not reachable may be selected by LP and thus jut make it slaw and prevent it from selecting other proxies that may be good (hope I am mistaken). 2. Last knight, I ran HttPort (using proxy.sbm.net.sa:80) just to compare it with LP. I was surprised to see that it did not support connect: [proxy.sbm.net.sa:80 New mapping: CONNECT failed with retcode 405 (method not allowed) - your proxy does not support HTTP CONNECT method] It was more than a month since the last time I used HttPort. I remembered that proxy.sbm.net.sa:80 is actually 212.46.32.34:80. HttPort still works with other proxies such as 212.46.32.54:80 I thought that this may be the reason why LP did not choose any SBM proxies. But now I know that is not correct. Is that right? 4. within few days: a). I will post an update of open/blocked ports In KSA b). Rescan the Network (KSA) to verify open proxies c). Test statProxyParallel and will test for common ports (80,3128 and 8080) using connect proxies (as outlined in Statproxy) to see if it is working. Finally keep up the good work Thank you so much madani _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus |
From: wayne <wa...@ny...> - 2003-05-05 21:43:33
|
> From: "Madani AL" <mad...@ho...> > To: noc...@fr... > Subject: [noCensorship] Re: Fed up with LP > > Hi wayne > > The following are my findings with regards to SBM and Cyberia In KSA: > > 1. Cyberia: > running the latest firewalls.xml under LP, I realized that subnet had to be > increased to 212.119.64.0/19 as a received the following line from the > localProxy Engine (the 'back end'), version: 4.253: > [LP host (212.119.94.*) was not inside firewall KSA-cyberia]. Done. Good work. > Next, I only got the following proxies in layer 0 of 10080:1(connect): > 204.113.91.64:8001 > 212.119.79.2:80 ( I got this one when I extended the subnet range to 19) > 218.145.25.108:8081 > 24.129.32.175:9631 > > I merged the following working proxies into hosts.xml. These proxies > currently are the only active ones for Cyberia (Ogertel): > 212.119.67.14 :8080 PFFFPFPPPPPPPPFPFPFP 1.9/3.2 via:1.0 cache4.jed > agent:CacheFlow-Proxy/1.0 connBack:212.138.64.174 > 212.119.67.15 :80 PFFFPFPPPPPPPPFPFPFP 1.3/2.7 via:1.0 cache4.jed > agent:CacheFlow-Proxy/1.0 connBack:212.138.64.174 > 212.119.67.16 :8080 PFFFPFPPPPPPPPFPFPFP 1.7/3.0 via:1.0 cache4.jed > agent:CacheFlow-Proxy/1.0 connBack:212.138.64.171 > 212.119.67.17 :8080 PFFFPFPPPPPPPPFPFPFP 1.7/3.0 via:1.0 cache4.jed > agent:CacheFlow-Proxy/1.0 connBack:212.138.64.174 > 212.119.67.80 :80 PFFFPFPPPPPPPPFPFPFP 1.8/3.3 via:1.0 cache4.jed > agent:CacheFlow-Proxy/1.0 connBack:212.138.64.172 Four of those are new, and one already known. I've fudged a statProxy result set to merge these results in, and done it twice, to account for the infrequent reports from the KSA. Please ... it takes a bit of work to fake these result sets for mergeHosts. It's much easier (and less error-prone) for me if you include the statProxy header line, even if it's munged. Just leave enough info for me to know which firewall/ISP the tests were done from (the first two, or three, octets will usually do). > The following proxies should be disabled in hosts.xml at least for now: > 212.119.67.18:8080 > 212.119.67.19:8080 > 212.119.67.20:8080 > 212.119.79.2:80 > 212.119.79.66:8080 > 212.119.79.67:8080 > 212.119.82.61:8080 They get lost forever when I do the next cleanHosts if I do that. I much prefer statProxy(Parallel) tests - several, done over a week or two. So now I'm undecided about what to do. I don't want to risk losing them forever, because i so rarely get up to date info from there, and it will probably be a long time before I get test results allowing mergeHosts to add them again. But at the same time, if I do nothing, I lose the info that you have just provided :-( Later - I've compromised. I've fudged a statProxy result set with timeouts on all those connections, and merged it three times. That's enough to disable ones that were on the way out anyway, but not kill completely those I thought were ok up to now. One more test result from there indicating they are dead will disable them. As it's turned out, none got disabled, because the last time I had any good reports from there (probably from you!), they were ok. In the meantime, LP will try not to use them, because they have such low uptime ratio scores. If they are changing often, the we need reports more often too. :-) > Conclusion: Cyberia is working fine with the original > config-KSA-cyberia.xml. > Problem solved. Great. > 2. SBM: Ahh .. the *real* problem. > I noticed that [master.xml] is not consistent whenever I run the Autoconfig > option in LP. That's true. If your network is not consistent, master can't be either. For example, it must wait a full TCP timeout for each connection. If sometimes, a response comes back at <TCP timeout>+1, then master says it's blocked. That timeout is about 21 seconds. Not much I can do to ensure more consistency in an inconsistent network, except possibly to repeat each test 'several' times. Is that worthwhile? Because each test response is nearly at the timeout, the master tests would take approx 'several' times as long. > Examples: > > Mapping the firewall rules, please wait ... > Warning: filtering detected (probably transparent proxy) on port 25 > Warning: filtering detected (probably transparent proxy) on port 110 > Warning: filtering detected (probably transparent proxy) on port 8083 This bothers me. It means that master didn't get the random 'garbage' characters on each connection to these ports at login.icq.com. I've only seen that on port 80 before (where there *is* a transparent proxy). I may be making an unwarranted assumption there. > port 21 is open > port 22 is open > port 23 is open > port 25 is blocked > port 80 is blocked > port 81 is blocked > port 82 is open > port 85 is blocked > port 110 is blocked > port 119 is blocked > port 443 is blocked > port 563 is open > port 666 is open > port 800 is open > port 880 is open > port 1080 is blocked > port 2009 is open > port 3128 is blocked > port 6588 is blocked > port 6801 is open > port 7000 is open > port 7021 is open > port 7033 is open > port 7070 is open > port 7137 is open > port 7175 is open > port 7475 is open > port 8000 is blocked > port 8001 is open > port 8002 is open > port 8003 is open > port 8004 is open > port 8005 is open > port 8006 is open > port 8007 is open > port 8008 is open > port 8080 is blocked > port 8081 is open > port 8082 is open > port 8083 is blocked > port 8084 is open > port 8085 is open > port 8086 is open > port 8087 is open > port 8088 is blocked > port 8089 is blocked > port 8090 is open > port 8091 is open > port 8141 is open > port 8180 is open > port 8421 is open > port 8616 is blocked > port 8888 is blocked > port 8965 is open > port 9001 is open > port 9081 is open > port 9274 is blocked > port 9589 is open > port 10080 is open > port 12345 is open > port 14000 is open > port 20034 is open > Saving the results in master.xml > > Please note that port 8083 is blocked here while it is open in another test: > > Mapping the firewall rules, please wait ... > Warning: filtering detected (probably transparent proxy) on port 25 > Warning: filtering detected (probably transparent proxy) on port 110 > Warning: filtering detected (probably transparent proxy) on port 9589 So, even this test (last time it indicated 8083), is vulnerable to the same things. I see this sort of thing here too, and proxyTools was designed with that knowledge in mind. It's not a problem with proxyTools, but it must be taken account of by anything that uses the results from master/statProxy etc (for example, LP). It's the same with proxy scanners. Most are a *lot* worse than statProxy. It's a compromise between speed and reliability. Master is to be used while the user is waiting, so it compromises on the side of speed (and is unreliable), while statProxy compromises on the side of reliability (and is slow). My latest statProxyParallel makes the assumption that you're testing more than a few proxies, so it can wait as long as it needs for each response (while accepting all the other responses). I think that's a much better approach, though it makes the tests look very slow if you test just one proxy. BTW, I never called statProxy a proxy scanner (it was more of a proxy analyzer), but statProxyParallel combines the best of both worlds and I will call it a scanner now. Very soon (it still doesn't do Socks tests, or tests via CONNECT proxies like statProxy does - soon), it will just replace statProxy in the CVS. > port 21 is open > port 22 is open > port 23 is open > port 25 is blocked > port 80 is blocked > port 81 is blocked > port 82 is open > port 85 is blocked > port 110 is blocked > port 119 is blocked > port 443 is blocked > port 563 is open > port 666 is open > port 800 is open > port 880 is open > port 1080 is blocked > port 2009 is open > port 3128 is blocked > port 6588 is blocked > port 6801 is open > port 7000 is open > port 7021 is open > port 7033 is open > port 7070 is open > port 7137 is open > port 7175 is open > port 7475 is open > port 8000 is blocked > port 8001 is open > port 8002 is open > port 8003 is open > port 8004 is open > port 8005 is open > port 8006 is open > port 8007 is open > port 8008 is open > port 8080 is blocked > port 8081 is open > port 8082 is open > port 8083 is open > port 8084 is open > port 8085 is open > port 8086 is open > port 8087 is open > port 8088 is blocked > port 8089 is blocked > port 8090 is open > port 8091 is open > port 8141 is open > port 8180 is open > port 8421 is open > port 8616 is open > port 8888 is blocked > port 8965 is open > port 9001 is open > port 9081 is open > port 9274 is open > port 9589 is blocked > port 10080 is open > port 12345 is open > port 14000 is open > port 20034 is open > Saving the results in master.xml > > Mapping the firewall rules, please wait ... > Warning: filtering detected (probably transparent proxy) on port 110 > Warning: filtering detected (probably transparent proxy) on port 25 > Warning: filtering detected (probably transparent proxy) on port 8087 > Warning: filtering detected (probably transparent proxy) on port 20034 > Warning: filtering detected (probably transparent proxy) on port 800 > Warning: filtering detected (probably transparent proxy) on port 21 > port 21 is blocked > port 22 is open > port 23 is open > port 25 is blocked > port 80 is blocked > port 81 is blocked > port 82 is open > port 85 is blocked > port 110 is blocked > port 119 is blocked > port 443 is blocked > port 563 is open > port 666 is open > port 800 is blocked > port 880 is open > port 1080 is blocked > port 2009 is open > port 3128 is blocked > port 6588 is blocked > port 6801 is open > port 7000 is open > port 7021 is open > port 7033 is open > port 7070 is open > port 7137 is open > port 7175 is open > port 7475 is open > port 8000 is blocked > port 8001 is open > port 8002 is open > port 8003 is open > port 8004 is open > port 8005 is open > port 8006 is open > port 8007 is open > port 8008 is open > port 8080 is blocked > port 8081 is open > port 8082 is open > port 8083 is open > port 8084 is open > port 8085 is open > port 8086 is open > port 8087 is blocked > port 8088 is blocked > port 8089 is blocked > port 8090 is open > port 8091 is open > port 8141 is open > port 8180 is open > port 8421 is open > port 8616 is open > port 8888 is blocked > port 8965 is open > port 9001 is open > port 9081 is open > port 9274 is open > port 9589 is open > port 10080 is open > port 12345 is open > port 14000 is open > port 20034 is blocked > > I have more of these results. Results are not consistent. It looks like the > timeout value for port testing need to be increased. Sure, that's the issue. The timeout now is 20 seconds for the whole lot. Ok, I've changed it to 40 seconds. > Running LP using SBM fire wall > > This is localProxy Engine (the 'back end'), version: 4.253 > Building configuration KSA-sbm > Please wait, this may take a few minutes > (you may avoid this in future by using the 'last' config)... > I'm assuming this IP address is 212.46.37.* > Waiting for the front end to connect ... connected > Importing globals.xml version 4.12 > Importing hosts.xml version 4.1664 > Importing commStrats.xml version 4.7 > Importing services.xml version 4.23 > Importing firewalls.xml version 4.110 > Importing config-KSA-sbm.xml version 4.1 > No (or incomplete) credentials found in environment > Using firewall: KSA-sbm > DNS addresses from o/s: 212.46.32.35, 212.46.32.45 > Name servers (o/s and firewall info): 212.46.32.35, 212.46.32.45, > 212.46.32.65, 212.46.32.33 > Accessible subnets: 212.46.32.0/19, 212.46.32.0/19 > DnsTimeout initialized: 5.5 > Sorting hosts (uses DNS, please connect)... > Filled layer 10119.1.*.- (1/10), (max,min) score was (0.4, 0.4) > Filled layer 10080.0.*.- (0/10), (max,min) score was (-1, -1) > > Disabling 10080 (non-censoring HTTP proxy - standard).0 - no layer 0 hosts > available > Filled layer 10080.1.*.- (3/10), (max,min) score was (0.4, 0.00032) > Filled layer 10080.1.-.* (10/10), (max,min) score was (1, 0.072) > Filled layer 10080.2.*.- (10/10), (max,min) score was (0.4, 0.0076) > Filled layer 10082.0.*.- (1/10), (max,min) score was (0.052, 0.052) > Filled layer 10082.1.*.- (3/10), (max,min) score was (0.4, 0.00032) > Filled layer 10082.1.-.* (10/10), (max,min) score was (0.18, 0.061) > Filled layer 10082.2.*.- (6/10), (max,min) score was (0.4, 0.00023) > Filled layer 10076.0.*.- (10/10), (max,min) score was (0.4, 0.016) > Filled layer 10076.1.*.- (3/10), (max,min) score was (0.4, 0.00032) > Filled layer 10076.1.-.* (10/10), (max,min) score was (0.6, 0.17) > Filled layer 10076.2.*.- (10/10), (max,min) score was (0.4, 0.016) > Checking all layer 0 hosts for connectivity... > Results from isConnectable: 00101011000000 > Unable to connect to 66.250.69.1:8572 204.113.91.64:8001 168.9.253.251:3347 > 216.126.204.21:8303 216.206.18.12:8002 209.2 > 05.129.2:8851 200.23.144.129:8001 205.205.143.254:8002 206.129.0.18:8281 > 218.145.25.108:8081 > Couldn't connect to 10 proxies > Don't panic, I can probably work ok without them > > LocalProxy is offering services on the following ports: > 10076:non-censoring HTTPS proxy > 10078:HTTP zapped advertisement proxy > 10079:proxy autoconfiguration > 10080:non-censoring HTTP proxy - standard > 10081:localProxy control > 10082:anonymous, non-censoring HTTP proxy > 10119:Usenet news - ccnews > > > For web browser proxy service, please configure your web browser > http proxy entry to localhost:10080 and the > https proxy entry to localhost:10076 now > > Only accepting connections from 127.0.0.1, 212.46.37.* > Executed getConfig(), result (truncated): <perldata> > <hash> > ... > Making test request: GET http://www.mhho.com/Links/Random.html > ---------------------- > The following are the only proxies selected in: 10080,1:connect, layer 0 > 204.113.91.64:8001 > 218.145.25.108:8081 > 216.20.10.43:8616 > 24.129.32.175:9631 > Also, non of SBM proxies were selected in layer 0 of the 2:direct, modified > > Conclusion: This ISP is ?@#$@%#$... Do not know that Is needed to make LP > identify the proxies in the subnet! I found it! I found it! :-) There was a bug which would have affected any of these firewalls which were inaccessable from outside (the 'notPanix' acl thingy). And only those I had already noticed, and tagged as such. I've fixed that, and also made it easier to trace these things. Around line 6086, just uncomment each line and fill in the type of trace you want - basically whatever you know about what you want to trace. I already had this debug code there, but it wasn't as easy to use before. :-) > 3. Open proxies with KSA network: > statProxy v4.156 report from 212.46.37.*(KSA-sbm): > 212.100.203.194 :3128 PFFFFFFPFFFFPFFPFPFP 4.3/38.6 via:1.0 cache10.ruh, > 1.1 d1proxy (NetCache 4.1R6), 1.0 setup (NetCache NetApp/5.2.1) Here we go again. This is an Awalnet proxy. If you did this test from SBM, then I have to assume all Awalnet proxies are accessible from SBM. I asked you about this before, IIRC. This time I see (below) what looks like a full the statProxy result, so I'm making the changes to incorporate the info. That will make a major increase in the number of proxies accessable from SBM. The results of this will swamp the extra proxies found for sbm by fixing the bug above. Please let me know if this report was edited in some way - ok? > agent:BlueCoat-Security-Appliance connBack:212.138.47.11 > 212.100.205.226 :8080 PFFFTRFPFFFFPPFPFPFP 2.8/16.1 via:1.0 cache10.ruh, > 1.0 netcache2 (NetCache NetApp/5.2.1R3), 1.0 SERVER2 > agent:BlueCoat-Security-Appliance connBack:212.138.47.17 > 212.100.207.10 :8080 PFFFFFFPFFFFPPFPFPFP 1.7/3.6 via:1.0 cache8.ruh, 1.0 > netcache1 (NetCache NetApp/5.3.1R2), 1.0 LINDORAPC > agent:BlueCoat-Security-Appliance connBack:212.138.47.11 > 212.100.207.22 :3128 PFFFFFFPFFFFPPFPFPFP 1.7/3.3 via:1.0 cache10.ruh, 1.0 > netcache1 (NetCache NetApp/5.3.1R2), 1.0 USTSRV > agent:BlueCoat-Security-Appliance connBack:212.138.47.12 > 212.102.11.254 :8080 PFFFFFFPFFFFFFFPFFFP 2.1/4.1 via:1.0 cache4.ruh, 1.0 > New-Proxy2 (NetCache NetApp/5.3.1R2) agent:NetCache NetApp/5.3.1R2D5 OMG! a whole new isp (Shabakah) at 212.102.0.0/19. Added to firewalls.xml, but I have no idea what ISPs can access this subnet (except for sbm/212.46.37.* of course). > connBack:212.26.70.40 > 212.102.12.180 :3128 PFFFFFFPFFFFFFFPFFFP 2.4/5.1 via:1.0 New-proxy3 > (NetCache NetApp/5.3.1R2D5) agent:NetCache NetApp/5.4R2 > connBack:212.138.47.14 > 212.102.2.122 :8080 PFFFFFFPPFFFFPFPFFFP 3.9/13.8 via:1.0 New-proxy3 > (NetCache NetApp/5.3.1R2D5) agent:NetCache NetApp/5.3.1R2D5 > connBack:212.26.70.41 > 212.102.2.229 :80 PFFFFFFPPFFFFPFPFPFP 2.3/4.7 via:1.0 new-proxy1 > (NetCache NetApp/5.4R2) agent:NetCache NetApp/5.4R2 connBack:212.26.70.40 > 212.102.3.66 :80 PFFFFFFPFFFFPPFPFPFP 2.3/5.4 via:1.0 New-proxy3 > (NetCache NetApp/5.3.1R2D5) agent:NetCache NetApp/5.3.1R2D5 > connBack:212.26.70.41 > 212.107.101.146 :80 PFFFFFFPFFFFPPFPFPFP 3.9/9.0 via:1.0 cache1.jed, 1.0 > SAUDISTEELBDC agent:BlueCoat-Security-Appliance connBack:212.119.67.17 A new subnet for Trinet. That means also for cyberia? I've added these too. > 212.107.97.2 :8080 PFFFFFFPFFFFFFFPFPFP 2.4/5.1 via:1.0 cache3.jed > agent:BlueCoat-Security-Appliance connBack:212.119.67.17 > 212.107.99.130 :8080 PFFFPFPPPPPPPPFPFPFP 3.7/13.9 via:1.0 cache4.jed > agent:BlueCoat-Security-Appliance connBack:212.119.67.17 > 212.11.177.235 :8080 PFFFFFPPFPFPFPFPFPFP 1.9/8.9 via:1.0 cache4.ruh, 1.0 > cache-01 (NetCache NetApp/5.3R2) agent:BlueCoat-Security-Appliance More subnets for sps too. Done. > connBack:212.11.191.16 > 212.116.194.195 :8080 PFFFPFPPPPPPPPFPFPFP 1.7/3.2 via:1.0 cache7.ruh, 1.0 > netcache3 (NetCache NetApp/5.2.1R3) agent:BlueCoat-Security-Appliance > connBack:212.138.47.11 More subnets for awalnet > 212.33.168.229 :80 PFFFPFPPPPPPPPFPFPFP 4.7/7.0 via:1.0 cache10.ruh, 1.0 > C3100-0033602110 (NetCache NetApp/5.2.1R1D4), 1.0 TMISERVER > agent:BlueCoat-Security-Appliance connBack:212.33.160.3 sol ... > 212.62.100.205 :8080 PFFFFFFPFFFTPPFPFPFP 3.9/14.6 via:1.0 cache1.jed, 1.0 > NetCache3100 (NetCache NetApp/5.3.1R2), 1.0 IBM iccnet - another new one for firewalls.xml > agent:BlueCoat-Security-Appliance connBack:212.138.64.174 > 212.76.68.49 :8080 PFFFPFPPPPPPPPFPFPFP 3.0/7.9 via:1.0 cache7.ruh > agent:BlueCoat-Security-Appliance connBack:212.76.68.204 > 212.76.70.39 :8080 PFFFFFFPFFFFPPFPFPFP 9.8/30.4 via:1.0 cache1.ruh, 1.0 > SERVER agent:BlueCoat-Security-Appliance connBack:212.76.68.203 > 212.76.75.103 :8080 PFFFPFFPPPPPFFFPFPFP 3.0/4.5 via:1.0 cache1.ruh > agent:BlueCoat-Security-Appliance connBack:212.76.68.203 > 212.76.75.50 :80 PFFFPFFPPPPPPPFPFPFP 2.2/3.7 via:1.0 cache10.ruh > agent:BlueCoat-Security-Appliance connBack:212.76.68.203 > 212.76.76.11 :8080 PFFFPFPPPPPPFPFPFPFP 2.3/4.8 via:1.0 cache9.ruh > agent:BlueCoat-Security-Appliance connBack:212.76.68.204 > 212.76.76.16 :80 PFFFPFPPPPPPPPFPFPFP 2.0/4.2 via:1.0 cache9.ruh > agent:BlueCoat-Security-Appliance connBack:212.76.68.203 > 212.76.76.42 :8080 PFFFFFFPFFFFPPFPFPFP 2.2/3.9 via:1.0 cache1.ruh, 1.0 > SERVER agent:BlueCoat-Security-Appliance connBack:212.76.68.203 212.62.99.52 > :8080 PFFFFFFPFFFFPPFPFPFP 1.6/5.6 via:1.0 cache4.ruh, 1.0 NetCache3100 > (NetCache NetApp/5.3R2D4), 1.0 SALAH agent:BlueCoat-Security-Appliance > connBack:212.138.47.14 sahara ... > 213.184.160.152 :80 PFFFFFFPFFFFPPFPFPFP 1.8/24.2 via:1.0 cache8.ruh, 1.0 > netcache2 (NetCache NetApp/5.2.1R3), 1.0 MISHWAR_MAIL > agent:BlueCoat-Security-Appliance connBack:212.138.47.20 > 213.184.164.63 :80 PFFFFFFPFFFFPPFPFPFP 7.9/12.1 via:1.0 cache1.ruh, 1.0 > netcache4 (NetCache NetApp/5.3.1R2) agent:BlueCoat-Security-Appliance > connBack:212.138.47.29 awalnet. > Please NOTE: the above open proxies are not fixed/stable. Today are open > tomorrow might be closed. The ISPs are switching their proxies very often That's why LP is the way it is. That doesn't matter to it. But whole subnets/ISPs changing certainly affects it. If one ISP allows another ISPs users to access it's proxies, for example, then LP's build should change quite dramatically. > Best regards > madani I've made lotsa changes based on your info; all good, I think. Please ignore extra warnings from mergeHosts for the moment, I'm still evaluating a new routine (isAccessible). Please tell me about any problems you see - I'm sure I've broken something as well :-( Good info, as usual. Thanks. -- wa...@ny... http://proxytools.sourceforge.net/ |
From: wayne <wa...@ny...> - 2003-05-03 22:30:49
|
> From: "Madani AL" <mad...@ho...> > To: noc...@fr... > Subject: [noCensorship] Fed up with LP Summary: I think the basic problem is that the sbm proxies aren't being loaded in the LP build. The way to figure out why is to see a log of that build. > Dear Wayne > > I have to admit it. I have a mixed feeling toward LP 'Mixed', or 'fed up'? Ya gotta admit, testing LP over the years has taught you some things about Perl, networks and proxies. That's good ... I think. :-) > I know it is becoming more automated and easy to use for novice, but still > full of whistles for the more advance users. > > I am exercising all sorts of fall downs when trying to run LP with SBM ISP > (sbm.net.sa). No matter what changes I make, LP never pick up SBM proxies > such as: > 212.46.32.42 > 212.46.32.34 > 212.46.32.54 These are already present and enabled in hosts.xml, but they are censoring. Censoring means they won't get chosen for commStrat 0, layer 0. They CONNECT to 80, 8080 at least, so they could be chosen for commStrat 1, layer 0. They should be chosen for commStrat 2 too. They won't get chosen for any of these places unless they score higher (are faster and more reliable) than the alternative choices. > It will however accept any proxy in my config. It believes the user has access to any proxies he puts in his own config. It won't believe they are non-censoring (or even working), unless the user has also added test results into that config which prove that. > File other than SBM proxies. That's weird. You made sure they were fast and reliable so they could get chosen, I guess? Note that they are also in the LP database, so they should have been loaded from there even without your configuration. If you haven't already done this, try using the distributed SBM config file, rather than your own. There may be a problem with yours. Did you add these proxies in there by hand, or by using statProxy/mergeHosts? > Auto config. never help at all. That would be right. It would only add them to your config, with test results, and if loading them from the config wasn't working you wouldn't get anywhere. > I changed config-last.xml and inserted manually needed SBM proxies and > started LP with config. last chosen just to go around it. That would work if you used them for commStrat 1, layer 0. You added them there? And the results were good? Probably. > Lately, I noticed that hosts.xml file had no 10080.0.0- proxies [Disabling > 10080 (non-censoring HTTP proxy - standard).0 - no layer 0 hosts available]. Yes, that has been the case (on and off) for some time now for KSA. I'm not spending lots of time searching the Arabic groups where the proxies are (at least, were) being posted. Either people test them and post to me, or in lists I see, or everyone tests their own and adds the results to their own config. It's no skin off my nose if people don't share their results, but many other people are then disadvantaged. That's pretty much the way it's happening right now. > This means that I had to search the network for other open proxies (within > KSA or from the outside) just to start my LP. **Not funny isnt it? **. No. So post them to me, and then they will be there for everyone. What's the alternative? If you and just one other person there had successfully tested some and sent to me, your LP would probably have worked. Still, the basic problem seems to be that your CONNECT capable local ISP proxies are not being used in the LP build (10080, commStrat 1, layer 0). We should sort that out. > As a last resort, bought several cards with some hours from the following > ISPs: Great! Someone willing to do some testing. You're unique (and that's a fact!). > 1. cyberia.net.sa:8080 > 2. nesma.net.sa:8080 > 3. sps.net.sa:8080 > 4. zajil.net:3128 > The test was very smooth for ISPs 2,3,4. No sweat. LP ran like Ferrari. Heh, it's been some time since that kind of statement was made. > For #1 (Cyberia), LP could not help it. LP said it was > As a matter of fact, Cyperia is just > another name for proxy.ogertel.com Ok, Ogertel is now gone from firewalls.xml. CVS soon. > cyberia.net.sa > Domain ID 20020818N001 > 212.119.67.14 > Name server ns1.cyberia.net.sa , 212.119.64.2 > Name server ns2.cyberia.net.sa , 212.119.64.3 Ok, added these two to the two already there (from ogertel: 212.119.67.2, and 212.119.67.3). If these two from ogertel aren't working in cyberia, that might explain some things, but you would have seen error messages. Can you confirm that they all work: nslookup www.panix.com 212.119.67.2 for example? > When I started LP using [auto], it did not work If it doesn't work, that's probably still ok. LP just uses what it's got in the database. > although every thing was ok: > ----------------- > This is localProxy GUI (the 'front end'), version: 4.262 > Proxies found in environment: proxy.sbm.net.sa:80 > I'm assuming this IP address is 212.119.66.* > I'm assuming this IP address is 212.119.66.* > Setting default config KSA-ogertel > master.xml has been generated ... loading > Generating config-auto.xml ... done > Starting localProxy engine with configuration: auto > start line: perl localProxy2.pl -x 3 -g -d 0 -c auto > Connected to localhost:10081.... > ----------- > Mapping the firewall rules, please wait ... > Warning: filtering detected (probably transparent proxy) on port 25 > Warning: filtering detected (probably transparent proxy) on port 110 > Warning: filtering detected (probably transparent proxy) on port 7021 > [---] You got that message on all the ports? Port 80? Is it correct? Do you have a transparent proxy? > port 8000 is blocked > port 8001 is open > port 8002 is open > port 8003 is open > port 8004 is open > port 8005 is open > port 8006 is open > port 8007 is open > port 8008 is open > port 8080 is blocked > port 8081 is open > port 8082 is open > port 8083 is open > port 8084 is open > port 8085 is open > port 8086 is open > port 8087 is open > port 8088 is blocked > port 8089 is blocked > port 8090 is open > port 8091 is open > port 8141 is open > port 8180 is open > port 8421 is open > port 8616 is blocked > port 8888 is blocked > port 8965 is open > port 9001 is open > port 9081 is open > port 9274 is blocked > port 9589 is open > port 10080 is open > port 12345 is open > port 14000 is open > port 20034 is open > Saving the results in master.xml > Checking proxies: 212.119.67.14:8080, proxy.zajil.net:3128, > proxy.ogertel.com:8080, > panix.panix.com:10080, This resolves to at least 3 IP addresses. If you added it because you had a redirector running on Panix, you need to say which host (panix1, 2,3,...) or give the IP address. > proxy.sbm.net > .sa:80 > Checking proxy capabilities ... > Warning: safe mode is off > [---] > statProxy v4.156 report from 212.119.66.*(KSA-ogertel): > 212.119.67.14 :8080 PFFFPFPPPPPPPPFPFPFP 1.8/3.2 via:1.0 cache4.jed > agent:BlueCoat-Security-Appliance > ----------------- > This is localProxy Engine (the 'back end'), version: 4.252 [...] > DNS addresses from o/s: 212.119.64.2, 212.119.64.3 > Name servers (o/s and firewall info): 212.119.64.2, 212.119.64.3 > Accessible subnets: 224.0.0.0/4, 212.119.67.8/24, 212.119.66.255/24, > 212.119.66.*/24 Hmm, that's misleading. It actually has more subnets than this. The list printed is only for the subnets it's added by examining the auto config file. I've changed it to show all of them now. Please update localProxy2.pl so that if you post a log next time, it will include all the nets. > DnsTimeout initialized: 5.5 > Sorting hosts (uses DNS, please connect)... > Filled layer 10076.0.*.- (10/10), (max,min) score was (0.4, 0.016) > Filled layer 10076.1.*.- (3/10), (max,min) score was (0.4, 0.00032) > Filled layer 10076.1.-.* (10/10), (max,min) score was (0.6, 0.17) > Filled layer 10076.2.*.- (10/10), (max,min) score was (0.4, 0.016) > Filled layer 10022.1.*.- (0/10), (max,min) score was (-1, -1) > > Disabling 10022 (secure telnet (ssh) - SSH-panix3).1 - no layer 0 hosts > available > Filled layer 10119.1.*.- (1/10), (max,min) score was (0.4, 0.4) > Filled layer 10080.0.*.- (0/10), (max,min) score was (-1, -1) > > Disabling 10080 (non-censoring HTTP proxy - standard).0 - no layer 0 hosts > available That's reasonable. No *nonCensoring* http proxies are available. > Filled layer 10080.1.*.- (3/10), (max,min) score was (0.4, 0.00032) But 3 proxies which are CONNECTCapable to standard outside proxy ports are available. These would be Cyberia/Ogertel proxies. > Filled layer 10080.1.-.* (10/10), (max,min) score was (1, 0.072) > Filled layer 10080.2.*.- (10/10), (max,min) score was (0.4, 0.011) > Filled layer 10082.0.*.- (1/10), (max,min) score was (0.052, 0.052) > Filled layer 10082.1.*.- (3/10), (max,min) score was (0.4, 0.00032) > Filled layer 10082.1.-.* (10/10), (max,min) score was (0.18, 0.061) > Filled layer 10082.2.*.- (8/10), (max,min) score was (0.4, 0.00023) > Rotating name servers: 1 > Checking all layer 0 hosts for connectivity... > Results from isConnectable: 000111010100010100 > Unable to connect to 66.250.69.1:8572 216.126.204.54:8303 204.113.91.64:8001 > 216.126.204.24:8303 205.205.143.254:8002 16 > 8.9.253.251:3347 66.213.25.6:8867 216.126.204.21:8303 216.206.18.12:8002 > 200.23.144.129:8001 218.145.25.108:8081 bash-2.05b$ ./statProxyParallel.pl -t 0 -l so.txt [...] statProxy v4.25 report from xxx: 168.9.253.251 :3347 P 11.2/12.5 200.23.144.129 :8001 T ?/? 204.113.91.64 :8001 T ?/? 205.205.143.254 :8002 T ?/? 216.126.204.21 :8303 P 0.8/1.0 216.126.204.24 :8303 T ?/? 216.126.204.54 :8303 T ?/? 216.206.18.12 :8002 P 0.9/1.3 218.145.25.108 :8081 R ?/? 66.213.25.6 :8867 P 10.3/10.5 66.250.69.1 :8572 P 11.9/12.2 Wall clock time: 0.53 mins. So, some of these were working. Are these ports open/blocked for you? 3347, 8303, 8002, 8867, 8572 [...] > Is that all??? > No. Believe it, LP works just fine when I use config- KSA-ogertel.xml file > under Cyberia ISP. I believe it :-) I can see from that build that it has enough to work. > Just to make it more complicated, I changed KSA-ogertel in firewalls.xml to > KSA-cyberia They were already the same except for the name servers. See my question above. > and started LP using config-KSA-cyberia.xml (just renamed the > config-KSA-ogertel.XML). Renaming doesn't make any difference either. I've added a new config-KSA-cyberia.xml now, but the only thing that means is that it will appear in the config lkist in LP now. > LP could not make it. I have trouble understanding that. Possibly the name servers screwed it up. Check those. It's a pity you didn't post that log too. I could have seen exactly what went wrong. Can you do that? > I other words LP could not > deal with cyberia.net.sa. Only works with ogertel.com (which is not there > any more as it is changed to cyberia.net.sa). > > Is that all ?? > Not yet. > I went back to an old version of LP(4.3) which can be found in > 2001-12-01.zip. > This version is able to figure out all SBM proxies found in hosts.xml and > use them as layer 0. For 10080, commStrat 1, you mean? Certainly not commStrat 0. > Newer versions could not. Ok, it sounds like that's the basic problem here. > One more thing: > I searched SaudiNIC's database for sbm at the following URL: > http://www.saudinic.net.sa/cgi-bin/whois.cgi > It returnred: > ---------------- > sbm.net.sa > Domain ID 19990326N000 > Name server neptune.sbm.net.sa , 212.46.32.65 > Name server pluto.sbm.net.sa , 212.46.32.33 Yep. I get these too. > On the other hand, I typed :ipconfig (in Command Prompt) and got the > following: > > Microsoft Windows XP [Version 5.1.2600] > (C) Copyright 1985-2001 Microsoft Corp. > > C:\Documents and Settings\madani.MADANI-*.000>ipconfig /all > > Windows IP Configuration > > Host Name . . . . . . . . . . . . : madani-* > Primary Dns Suffix . . . . . . . : > Node Type . . . . . . . . . . . . : Unknown > IP Routing Enabled. . . . . . . . : No > WINS Proxy Enabled. . . . . . . . : No > > PPP adapter SBM-Local: > > Connection-specific DNS Suffix . : > Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface > Physical Address. . . . . . . . . : ******** > Dhcp Enabled. . . . . . . . . . . : No > IP Address. . . . . . . . . . . . : 212.46.36.* > Subnet Mask . . . . . . . . . . . : 255.255.255.255 > Default Gateway . . . . . . . . . : 212.46.36.* > DNS Servers . . . . . . . . . . . : 212.46.32.35 > 212.46.32.45 The first one is refusing dns queries, and the second is down, or firewalled from the outside. Test these two as explained above, and remove from your setup if necessary. If they are being dynamically allocated, then complain to the ISP you dialled into at the time. > By the way, SaudiNIC is the only database which resolved Cyberia. > > > Summery: > There is some thing not correct in the new versions of LP. Older versions > work fine but not the new ones. I know that this message is too long Messages are never too long if it's because they contain some good information :-) > but I > hope it will help in solving the problem A log of any of the failing builds will tell me what's wrong. > Best regard > madani -- wa...@ny... http://proxytools.sourceforge.net/ |
From: wayne <wa...@ny...> - 2003-04-24 04:11:33
|
> From: Nabil Jaffar <nf...@ya...> > Subject: Re: [proxyTools-users] ISA server problem ???? > To: pro...@li... > > My questions: > 1) why do you want ftp? Ftp is difficult to set up in that kind > of environment, even with LP. Many ftp archives these days also > offer http access; are you sure that possibility won't work for > you? > >>> http has no problems, but as i often use to download > lot of project work with large file sizes and ofcourse ok, that covers the need for ftp you thought you had. Use http. > i use kazaa or any other p2p applications/utilities > on my workstation.... This is a new requirement. Also not easy. Each one requires you to look into the protocol, see if it's a simple TCP protocol, and implement the tunnel configuration. I added E-Donkey to the LP services once; you may find that interesting. > 2) you should confirm that the relevant ports are actually > blocked > by your firewall. Run master.pl to see this. > >>> as you can see the results of various utilities pasted below > and yes that particular port is blocked.... I didn't see any master.pl test reports, but I'm sure you're correct. In one place like this, I once found the firewall allowed access on a port to local ISP proxies (which happened to allow CONNECT). Master.pl indicated that they were blocked because it tested for connection to login.icq.com (which *was* blocked). Unlikely, but maybe worth a look. > 3) LP could only be used to give you an ftp service, if the http > > proxy you use allows CONNECT, and even then it is difficult to > arrange (and I would need to add some code to LP). So far, this > hasn't been necessary. Use statProxy to see if your proxy has > this capability. > >>> i have tried and also you can see the result output below... No CONNECT allowed to useful ports. That's normal for MS. > 4) Does your proxy need a password? If so, do you know if it > requires NTLM authentication? > >>> no it does not.... Probably next week ... No problem though - LP can use a Perl NTLM proxy. Will post if anyone needs this. > ONE MORE QUESTION , A GENERAL ONE, AND MAY BE YOU BE ABLE TO > HELP... > I ALSO RUN A LINUX WORKSTATION, I CAN PING OTHER HOSTS AND ALSO > THE ISA SERVER BUT I CANT BROWSE, DOES THIS HAVE TO DO ANYTHING > WITH THE ISA SERVER, IS THERE ANY SETTING OR CANT DO? 1) You're sure there's no NTLM? 2) What are you using to browse with? Netscape/Mozilla? Or lynx etc? 3) Is there a MS domain involved? 4) It's critical that you have a name server configured! Try this: export http_proxy=http://192.168.0.1:8080 lynx http://166.84.63.251/ and see if it works. If it does not, you might get a useful error. Netscape/Mozilla should also work, if you configure that proxy. If they don't, try (on one line): lynx -useragent='User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;)' http://166.84.63.251/ to see if they are blocking access from other browsers. > THANKS > NJ > D:\bakup\local-proxy\winbin>statproxy 192.168.0.1:8080 > Can't find your name server(s) using nslookup, ipconfig /all > etc. What operating system was this? Oh, I see from below that you have no name server set up. Surely there is one available. Find out, and configure it. [...] > statProxy v4.143 report from 192.168.0.37(User0): > 192.168.0.1 :8080 PFFFFFFPFFFFPPPPFP P 9.0/14.0 via:1.0 All the CONNECT tests failed (except to 443/https), so you can't use LP/commStrat 1 to make tunnels for even simple tcp protocols. LP commStrat 2 could allow access to blocked web sites, but that's all the help it can give you in this environment. That means that to implement any of the p2p stuff, you need to use an outside service (not just an http proxy) of some sort to make a tunnel. Try http_tunnel. IIRC, there are free servers running to test with, but you'd want to run your own somewhere (home?). I will have to handle a similar environment in a couple of weeks, so I might be able to help with details then. [...] > D:\bakup\local-proxy\winbin>statProxy -t 0 -C 213.42.1.171:8080 > 192.168.0.1:8080 > > Tests done via CONNECT (thru 213.42.1.171:8080) > Can't find your name server(s) using nslookup, ipconfig /all > etc. > Extracting proxy strings, safeing, expanding/skipping ports, > validating, resolving, deduping... > 1 proxies to test (after processing) > ctrl-c to see results so far; double-ctrl-c to abort > Running test: 0 Can't connect to CONNECT proxy - refused Heh, nice try, but not a surprising result :-) -- wa...@ny... http://proxytools.sourceforge.net/ |
From: Nabil J. <nf...@ya...> - 2003-04-23 14:51:54
|
My questions: 1) why do you want ftp? Ftp is difficult to set up in that kind of environment, even with LP. Many ftp archives these days also offer http access; are you sure that possibility won't work for you? >>> http has no problems, but as i often use to download lot of project work with large file sizes and ofcourse i use kazaa or any other p2p applications/utilities on my workstation.... 2) you should confirm that the relevant ports are actually blocked by your firewall. Run master.pl to see this. >>> as you can see the results of various utilities pasted below and yes that particular port is blocked.... 3) LP could only be used to give you an ftp service, if the http proxy you use allows CONNECT, and even then it is difficult to arrange (and I would need to add some code to LP). So far, this hasn't been necessary. Use statProxy to see if your proxy has this capability. >>> i have tried and also you can see the result output below... 4) Does your proxy need a password? If so, do you know if it requires NTLM authentication? >>> no it does not.... ONE MORE QUESTION , A GENERAL ONE, AND MAY BE YOU BE ABLE TO HELP... I ALSO RUN A LINUX WORKSTATION, I CAN PING OTHER HOSTS AND ALSO THE ISA SERVER BUT I CANT BROWSE, DOES THIS HAVE TO DO ANYTHING WITH THE ISA SERVER, IS THERE ANY SETTING OR CANT DO? THANKS NJ *********************************************************************** D:\bakup\local-proxy\winbin>statproxy 192.168.0.1:8080 Can't find your name server(s) using nslookup, ipconfig /all etc. Warning: If you are testing any proxy through a redirector, the proxy anonymity test will reveal your true IP address. Normally you would be connecting directly to the proxy for these tests anyway, so it doesn't matter. The test won't work if you block incoming connections with a firewall, or a NAT. I will disable the anonymity test if you wish. Disable anonymity test (y or [n])? n Extracting proxy strings, safeing, expanding/skipping ports, validating, resolving, deduping... 1 proxies to test (after processing) ctrl-c to see results so far; double-ctrl-c to abort Running test: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 Can't find your name server(s) usi ng nslookup, ipconfig /all etc. Can't find your name server(s) using nslookup, ipconfig /all etc. 14 15 16 17 18 Can't find your name server(s) using nslookup, ipconfig /all etc. 19 192.168.0.1:8080 statProxy v4.143 report from 192.168.0.37(User0): 192.168.0.1 :8080 PFFFFFFPFFFFPPPPFP P 9.0/14.0 via:1.0 PNSERVER Reference page size was 14014 bytes Wall clock time: 1.1 mins. Results have also been written to file statProxy.2003.4.23.1.out This exe file was created with the evaluation version of Perl2Exe. For more information visit http://www.indigostar.com (The full version does not display this message with a 2 second delay.) ... D:\bakup\local-proxy\winbin>ipconfig/all Windows IP Configuration Host Name . . . . . . . . . . . . : stigmatik Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Unknown IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : 3Com EtherLink XL 10/100 PCI TX NIC (3C905B-TX) Physical Address. . . . . . . . . : 00-10-4B-61-F5-20 Dhcp Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 192.168.0.37 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.0.1 D:\bakup\local-proxy\winbin>master Can't find your name server(s) using nslookup, ipconfig /all etc. Can't find your name server(s) using nslookup, ipconfig /all etc. Can't find your name server(s) using nslookup, ipconfig /all etc. waiting for name server ... waiting for name server ... waiting for name server ... waiting for name server ... waiting for name server ... waiting for name server ... waiting for name server ... waiting for name server ... waiting for name server ... waiting for name server ... waiting for name server ... ^C D:\bakup\local-proxy\winbin>statProxy -t 0 -C 213.42.1.171:8080 192.168.0.1:8080 Tests done via CONNECT (thru 213.42.1.171:8080) Can't find your name server(s) using nslookup, ipconfig /all etc. Extracting proxy strings, safeing, expanding/skipping ports, validating, resolving, deduping... 1 proxies to test (after processing) ctrl-c to see results so far; double-ctrl-c to abort Running test: 0 Can't connect to CONNECT proxy - refused statProxy v4.143 report from 192.168.0.37(User0): 192.168.0.1 :8080 R ?/? Wall clock time: 0.081 mins. Results have also been written to file statProxy.2003.4.23.2.out This exe file was created with the evaluation version of Perl2Exe. For more information visit http://www.indigostar.com (The full version does not display this message with a 2 second delay.) ... D:\bakup\local-proxy\winbin> ********************************************************************** ===== <(@ ! @)> __oooo__oooo__ take care & PLAY SAFE __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
From: wayne <wa...@ny...> - 2003-04-19 23:12:58
|
> From: Nabil Jaffar <nf...@ya...> > To: pro...@li... > Subject: [proxyTools-users] ISA server problem ???? > > i am sitting behind ISA server 2000, 'Behind' a web server? Hmm, I'll guess that means that means there is a firewall blocking direct outgoing connections and that you are forced to use Microsoft proxies for external access (http, ftp). > and i am in pakistan, so > normal rules for uae/ksa i dont suppose apply to this situation The config User0 is an example for a config for LP for this kind of corp/edu environment. > since i have tried but the LP server cant find my DNS addresses You could either mean that LP can't find it's own IP address (unlikely), or that it can't resolve fqdn addresses to IP addresses because it really can't find a DNS server to use. I'm guessing the latter. If I'm right, then it's probably because the DNS server is not in your registry, or your environment, or your 'ipconfig /all' command, or /etc/resolv.conf, or ... It's possible LP is failing to parse some of these if you're using an operating system/version it's not familiar with. Which version of Unix/Windows are you using? > since there is a cable system laid down here through utp and > switch.... This is not relevant to any of the above, and to your acess problems. > my problem is that the FTP server is always seem to > be blocked, how can i use proxy tools to use the FTP service... 'The ftp service' means the ftp service that's available on the IIS server, or an ftp service outside? If you mean your IIS service, what makes you think it's even running? If you mean any outside ftp, then it's probably blocked by the firewall. > if posible, please, this used to work beutifully in u.a.e. Ftp is not blocked by the UAE firewall, so LP would have had nothing to do with that. My questions: 1) why do you want ftp? Ftp is difficult to set up in that kind of environment, even with LP. Many ftp archives these days also offer http access; are you sure that possibility won't work for you? 2) you should confirm that the relevant ports are actually blocked by your firewall. Run master.pl to see this. 3) LP could only be used to give you an ftp service, if the http proxy you use allows CONNECT, and even then it is difficult to arrange (and I would need to add some code to LP). So far, this hasn't been necessary. Use statProxy to see if your proxy has this capability. 4) Does your proxy need a password? If so, do you know if it requires NTLM authentication? > help > > NJ -- wa...@ny... http://proxytools.sourceforge.net/ |
From: Nabil J. <nf...@ya...> - 2003-04-19 16:00:24
|
i am sitting behind ISA server 2000, and i am in pakistan, so normal rules for uae/ksa i dont suppose apply to this situation since i have tried but the LP server cant find my DNS addresses since there is a cable system laid down here through utp and switch.... my problem is that the FTP server is always seem to be blocked, how can i use proxy tools to use the FTP service... if posible, please, this used to work beutifully in u.a.e. help NJ ===== <(@ ! @)> __oooo__oooo__ take care & PLAY SAFE __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
From: wayne <wa...@ny...> - 2003-04-17 21:50:29
|
> From: red line <dar...@ya...> > Subject: [noCensorship] updating proxies > To: noc...@fr... > > hi everyone... alot of proxies arent working anymore...and localproxy isnt working well too. I think it will keep working for years though. It will just get slower as the proxies it has available die away. The newest versions (CVS only, so far) are better at optimizing use of an old list of proxies. > how can i update the proxies Localproxy is using with newer one?? and where can i find an always updated list of proxy servers? Thanks Do you see the 'Update proxies' button? Click it! If you don't have that button ... Get the latest hosts.zip from CVS and leave it lying around in your LP directory. LP will find it, unpack it (to hosts.xml) and use the new proxies the next time you 'run services'. Use your web browser to go here (it's probably wrapped on your screen, so join the bits back together): http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/proxytools/proxyTools/hosts.zip?rev=HEAD -- wa...@ny... http://proxytools.sourceforge.net/ |
From: wayne <wa...@ny...> - 2003-04-14 20:29:50
|
> From: "Madani AL" <mad...@ho...> > To: noc...@fr... > Subject: [noCensorship] Re: Unknown acl notation Error > > > > > Hi Wayne > > This is what I got when I went back to my configuration file. I hope it > clear things. > > > > Whenever I try to run LP from the customized config file in which I > >added my own proxies (config-_sbm.xml). I get the following: > > > > > > Sorting hosts (uses DNS, please connect)... > > > > > > Unknown acl notation: KSA-sbm > > > > > > Unknown acl notation: KSA-sbm > > > > > > Unknown acl notation: KSA-sbm > > > >There is probably, somewhere, a tag called > >'onlyAllowsTcpAccessFrom', with a value containing 'KSA-sbm'. > >That means it was put there by mergeHosts. > > YES, It is in my config file (config-_sbm.xml ) Better remove it. It will never be removed by mergeHosts. > >Not in my hosts.xml, or firewalls.xml, so it must be in > >your config-_sbm.xml (or hosts if you've modified it with > >mergeHosts maybe) > > > >Some time ago, when you used mergeHosts, did you see this error > >message? > > >Warning: firewalls.xml access control data (xxxx) incorrectly > > >says this location has no access to xxxx. Tell wayne please. > > >Adding 'onlyAllowsTcpAccessFrom' tag for KSA-sbm > > > >I'm guessing you did. > True: this proxy (212.93.197.230:80)was the case Heh, and you didn't 'Tell wayne' :-) Tsk, tsk. According to whois, this proxy is in Awalnet. Please confirm if it is accessible from SBM as well. I guess it is. If it is, I'll change the (new - see below) Awalnet tag: <item key="onlyAllowsTcpAccessFrom">212.93.192.0/18, 213.184.160.0/19</item> to: <item key="onlyAllowsTcpAccessFrom">212.93.192.0/18, 213.184.160.0/19, 212.46.32.0/18</item> and the 'otherAccessibleSubnets' tag for KSA-sbm. Also, it pointed out a wider range in Awalnet to me: 212.93.192.0/18, instead of the 212.93.192.0/20 I had before. I don't think I just missed this - I think it's 'new' ('new' being anything less than 2 years, or so. :-( > <item key="onlyAllowsTcpAccessFrom">212.93.192.0/20, 213.184.160.0/19, > KSA-sbm</item> > > <item key="comment">via:1.0 cache2.ruh, 1.0 NetCache6100 (NetCache > NetApp/5.3.1R2), 1.0 SALEHIYA_PROXY agent:BlueCoat-Security-Appliance > connBack:212.138.47.20 </item> Note the connection back was from 212.138.47.20. My test got a connBack from 212.138.47.17. These two are part of the proxy array used by Awalnet, and may be usable by you directly as proxies. In the UAE, for example, these proxy array components are not advertized, but are usable. You need to test these on the standard ports (and maybe others) to find out which port they are listening on to make use of them. If you do, please let me know - I can't do it because they are firewalled off from the rest of the net. > >In that case, you have a proxy in your own config which I thought > >was not accessible from your location. Could you please let me know > >your IP address (xxx.xxx.xxx.0/24 is ok) and the /24 of the > >proxy(ies)? Or find that tag, and see why mergeHosts thought the > >corresponding proxy was not accessible from your computer at the > >time - then let me know what subnet(s) need to be added as either > >'subnetsInside' in firewalls.xml/ KSA-sbm, or as > >'otherAccessibleSubnets' in the same place. I must ask if you used Awalnet test results to update your config file to be used in sbm. That's bad. I don't think you did though. > >As well as that, the part of the lp2 code that was supposed to > >handle this is unfinished :-) > >I guess I was lazy at the time, and just haven't noticed it since. > >I've fixed it now, and LP should accept the extra tag. > >Get a new localProxy2.pl. > > > > > In config-_sbm.xml, there is a reference to KSA-sbm in the firewalls.xml > >(<item key="useFirewall">KSA-sbm</item>) > > > >No other reference? > > > > > Looking at the above, LP did not understand the KSA-sbm section in the > >firewalls file. > > > > > > What is/are the reasons? > > > >I don't think that's right. There are two parts to the problem, and > >the second part is in lp2's interpretation of the tag I mention > >above. That should be fixed. The initial part was caused by > >mergeHosts being clever when it had test results indicating you > >could access a proxy, yet no corresponding subnet info from > >firewalls which allowed this to be true. It added a tag to indicate > >that access was allowed (on the basis that, if even one test is > >successful, you *do* have access). > > > > > This explains why non of the SBM proxies in my config file or from the > >hosts.xml are picked up by LP. > > > >Yes, it does. > > > > > Is the subnetInside (212.46.32.0/19) range correct? > > > >It looks like it should be /18 now. This was wrong! Sorry. > >And if you had positive tests for a proxy in the /18 range but not > >in the /19 range, (212.46.48.0 - 212.46.63.255) then that would > >cause the extra tag added above! > > > > > Are the (nameServer">212.46.32.33, 212.46.32.65</item>) correct ? > > > >Dunno - tell me. :-) > >It's hard for me to know, but I got that info from somewhere. > >It might be very old. > > I think not sure it is 212.46.32.49 since it is the first address appers > whenever tracing is conducted. ??? That doesn't mean it's a name server. Nameservers usually listen on 53/tcp, so a telnet test to that port might show if it's a name server or not. From outside (using netcat instead of telnet): $ nc -vvn 212.46.32.49 53 (UNKNOWN) [212.46.32.49] 53 (?) : Connection refused sent 0, rcvd 0 If it's a name server, it should respond as one, but it doesn't (possible it's firewalled from outside though - you need to test yourself): $ dig @212.46.32.49 www.panix.com ; <<>> DiG 9.2.2 <<>> @212.46.32.49 www.panix.com ;; global options: printcmd ;; connection timed out; no servers could be reached You can do that same test with nslookup like this: nslookup www.panix.com 212.46.32.49 which again (from outside) shows it's not a name server. If you're using Windows, typing ipconfig /all should show you the name servers you are using. Please let me know if there are changes necessary. > > > BTW you have stated in your reply on my message (Re: LP and ActivePerl > >8xx) that SBM subnet extend to 212.46.63.255. Is it true? > > > >Yes, AFAIK: > >$ whois 212.46.63.255 > > > >inetnum: 212.46.32.0 - 212.46.63.255 > >netname: SA-SBM-990301 > >descr: Saudi Business Machines > >descr: PROVIDER > >country: SA > > > >That doesn't prove that all subnets have access to all others, or > >even that subnets within the range are actually in use. There's > >no way I can keep track of all that though, so LP must assume > >they are there and accessible. That's no problem normally. > > > this range is accurate :(212.46.32.0/19) Oh, I see what you are getting at. You think it should not be 212.46.32.0/18, as I have in firewalls.xml? You are correct too. I screwed up there :-( I've changed it again in firewalls.xml now. > It covers all used subnets (i.e 212.46.38.x) which I never got so far as my > IP > > I still have the problem of LP can not identify SBM proxies That's (at least) because they are Awalnet proxies, not SBM proxies. :-) At least the one you gave as an example is - dunno about others you have added. LP doesn't know that they are accessible from SBM. If they really are, we need to adjust firewalls.xml as mentioned above. > I used /24 (doesnot cover all) up to /18 which exceeds the actual range. I > even went to /16 but did not work. > Q: Is nameServer is a must for LP ? or is it able to work without it? Not usually a problem now. It gets them from firewalls.xml, from ipconfig/nslookup, and from your registry. If it's unable to find any, it will print a message to that effect (at debug > 2). If the ones it tries to use are bad, it will print 'rotating name servers', and 'unable to resolve ...' all the time. Even in that case, it will still work well - commStrat 2(a) and 2(e) will fail all the time, and LP will try something else. Services specified in the config as an fqdn would fail completely, however (the free news service ccnews.thu.edu.tw, for example). > Madani -- wa...@ny... http://proxytools.sourceforge.net/ |
From: wayne <wa...@ny...> - 2003-04-13 16:35:25
|
> From: madani <mad...@ya...> > Subject: [noCensorship] Unknown acl notation Error > To: noc...@fr... > > Hi Wayne Hiya, > Whenever I try to run LP from the customized config file in which I added my own proxies (config-_sbm.xml). I get the following: > > Sorting hosts (uses DNS, please connect)... > > Unknown acl notation: KSA-sbm > > Unknown acl notation: KSA-sbm > > Unknown acl notation: KSA-sbm There is probably, somewhere, a tag called 'onlyAllowsTcpAccessFrom', with a value containing 'KSA-sbm'. That means it was put there by mergeHosts. Not in my hosts.xml, or firewalls.xml, so it must be in your config-_sbm.xml (or hosts if you've modified it with mergeHosts maybe) Some time ago, when you used mergeHosts, did you see this error message? >Warning: firewalls.xml access control data (xxxx) incorrectly >says this location has no access to xxxx. Tell wayne please. >Adding 'onlyAllowsTcpAccessFrom' tag for KSA-sbm I'm guessing you did. In that case, you have a proxy in your own config which I thought was not accessible from your location. Could you please let me know your IP address (xxx.xxx.xxx.0/24 is ok) and the /24 of the proxy(ies)? Or find that tag, and see why mergeHosts thought the corresponding proxy was not accessible from your computer at the time - then let me know what subnet(s) need to be added as either 'subnetsInside' in firewalls.xml/ KSA-sbm, or as 'otherAccessibleSubnets' in the same place. As well as that, the part of the lp2 code that was supposed to handle this is unfinished :-) I guess I was lazy at the time, and just haven't noticed it since. I've fixed it now, and LP should accept the extra tag. Get a new localProxy2.pl. > In config-_sbm.xml, there is a reference to KSA-sbm in the firewalls.xml (<item key="useFirewall">KSA-sbm</item>) No other reference? > Looking at the above, LP did not understand the KSA-sbm section in the firewalls file. > > What is/are the reasons? I don't think that's right. There are two parts to the problem, and the second part is in lp2's interpretation of the tag I mention above. That should be fixed. The initial part was caused by mergeHosts being clever when it had test results indicating you could access a proxy, yet no corresponding subnet info from firewalls which allowed this to be true. It added a tag to indicate that access was allowed (on the basis that, if even one test is successful, you *do* have access). > This explains why non of the SBM proxies in my config file or from the hosts.xml are picked up by LP. Yes, it does. > Is the subnetInside (212.46.32.0/19) range correct? It looks like it should be /18 now. And if you had positive tests for a proxy in the /18 range but not in the /19 range, (212.46.48.0 - 212.46.63.255) then that would cause the extra tag added above! > Are the (nameServer">212.46.32.33, 212.46.32.65</item>) correct ? Dunno - tell me. :-) It's hard for me to know, but I got that info from somewhere. It might be very old. > BTW you have stated in your reply on my message (Re: LP and ActivePerl 8xx) that SBM subnet extend to 212.46.63.255. Is it true? Yes, AFAIK: $ whois 212.46.63.255 inetnum: 212.46.32.0 - 212.46.63.255 netname: SA-SBM-990301 descr: Saudi Business Machines descr: PROVIDER country: SA That doesn't prove that all subnets have access to all others, or even that subnets within the range are actually in use. There's no way I can keep track of all that though, so LP must assume they are there and accessible. That's no problem normally. > Note: I noticed that 8888 port is listed in blockedTCPPorts and openTCPPorts (firewalls.xml). It is not an open port in KSA. Need to be corrected. Thanks. Dunno when that happened :-( I've fixed it now. Get a new firewalls.xml. > madani -- wa...@ny... http://proxytools.sourceforge.net/ |
From: wayne <wa...@ny...> - 2003-04-12 05:36:57
|
> From: madani <mad...@ya...> > Subject: [noCensorship] LP and ActivePerl 8xx > To: noc...@fr... > > Hi Wayne, All > > I installed the new version of PERL ActivePerl 8xx and tried to run localProxy. The following happened: > > LP tried to connect to the Site to download the missing modules: Net::DNS and Win32::API but it failed. Bummer. I am using Cygwin perl 5.8 (but of course, needed to install those from CPAN by hand). > I opened the modInstall.bat to discover that LP was trying to connect through another ISP account e.g. ogertel.com which was in the Internet options of I.E and not the same account I was running (e.g. SBM). Since I had 3 accounts listed in the Internet options, the same thing was repeated i.e looking for Zajil account (see below) Yep. It's trying to be clever and using the proxy it thinks is appropriate for your location. :-( > [Missing Perl modules: > > Net::DNS Win32::API > > Proxies found in environment: proxy.sbm.net.sa:80 > > I'm assuming this IP address is 212.46.x.x [not ogertel IP) You chopped off too much there. I can't see what it was. SMB contains subnets 212.46.32.0/19 (212.46.32.0 through to 212.46.63.255). I guess that was correct? > Using proxy: http://proxy.ogertel.com:8080 This came from the first one found by WLib::getProxies. WLib::getProxies looks at: 1) your environment (http_proxy #case insensitive match. Looks like it found proxy.sbm.net.sa:80 there) 2) your registry 3) firewalls.xml (which has for sbm: proxy.sbm.net.sa:80, 212.46.32.42:80) Turn up the debug level to see exactly where it got the ogertel value from. perl localProxy.pl -x 3 Looks like it was somewhere in your registry though. Maybe dialup settings? Or settings specific to a NIC that you haven't looked at for some time? Which one actually gets chosen from all the above is up to Perl (and, at the moment, is allowed to change with Perl versions etc.). Maybe I should give priority to the environment? > A batch file, with the necessary script to install > > these modules, has been written to modInstall.bat > > Installing missing modules ... > > Press enter to exit localProxy GUI, > > wait for the modules to be installed, then restart localProxy] > > > > First of all, LP should detect which account is running and act accordingly. Is this a bug? I think I'd call it that too. I think it happened because you have junk hanging around in the registry, but I couldn't argue that the user should know that, and get rid of it. I'm sure it would take me an hour to find it and I wrote the code! I recall this occurring to me way back when, but there was nothing I knew at the time to ensure I got a proxy for an active network interface. I am sure it would take some research to fix. If I'm right about where it came from, then I'd say it only affects people who used multiple ISPs, so it's not worth hours of work, and then I would suggest I give the environment priority so you at least have a way to fix it by specifying the right proxy in the environment (as you already have). Sound ok? > So I tried to install Win32-API and Net-DNS manually. > > http://ppm.activestate.com/PPMPackages/zips/8xx-builds-only/Windows/Net-DNS.zip > I succeeded in installing Wen32-API module but the length of Net-DNS zip was only 415 bytes. It consisted of ppd and Readme files. Yes, it only contains the PPD spec, not the actual code. That's an activestate bug. They have been having difficulties with perl 5.8 ppd repositories. That's why I haven't moved to Windows Perl 5.8 yet. You should let them know about this. > The above forced me to go back and installed the 6xx version. > Is there another source where I can download the Net-DNS module? You can always try to use CPAN. perl -MCPAN -e shell install Net::DNS q If you haven't used CPAN before, you will probably need to answer a bunch of questions. I think all default answers will be ok, except for the http proxy question. Some (not sure about Net::DNS) of the modules need nmake (free from Microsoft site). Another way you can sometimes resolve these problems is to find the source code somewhere else on the Activestate site, but for the new perl 5.8, I wouldn't hold my breath. > Best regards > > madani -- wa...@ny... http://proxytools.sourceforge.net/ |
From: Manuel de la T. <ma...@de...> - 2003-04-06 02:18:24
|
From: wayne <wa...@ny...> - 2003-04-04 17:30:47
|
> From: "gstmoderator" <gst...@ho...> > To: <noc...@fr...>, <pro...@sf...> > Subject: [noCensorship] Re: DONE--Re: Re: LP > > I didnt know LP had the proxies built in so I thought I had to add them. > thanks for clarifying. Hosts.zip is the database. It decompresses to hosts.xml. You can read it by hand(Internet Explorer, or a text editor), but extracting proxies with the specifications you need is best done using extractHosts.pl. I generally keep it up to date, using the proxy lists posted in various groups and by testing the ones selected by LP for various configurations and ISPs. > > I think that answers all your original questions, but I have a > > couple: > > 1) I'd like to confirm that LP works when you leave it alone and > > just try to use it for (say) web browsing without adding your own > > proxies. Did you ever get that far? If it doesn't work (and you're > > still interested) please post some logs from the back end window. > > 2) I'd like to confirm whether or not that window (or task bar > > icon) actually appears when you use 'test/merge'. I recall a problem > > reported on XP, but I thought it was fixed a long time ago. It would > > only affect operation of 'test/merge'. I guess I'll have to do > > this myself on an XP system, if I can find one. I tested it on a Windows XP Pro workstation, and it worked fine. > the window only opens on autoconfigure. when I get the chance I'll run it > and post log for you. Duh, that's right. The test results are displayed in the GUI log window - sorry about that. > > > 1. open lp using saved config > > > 2. put proxies in box from hat 141.150.149.247:80, 208.49.206.97:80, > > > 204.196.215.9:80, 64.48.186.225:80, 208.218.142.13:80 Echo= 11687 > > > 3. push test/merge > > > 4. localproxy2 window log > > > > > > This is localProxy Engine (the 'back end'), version: 4.214 > > > Loading configuration saved > > > Waiting for the front end to connect ... connected > > > Checking all layer 0 hosts for connectivity... > > > Couldn't connect to 33 proxies > > > > Why so many? On second thoughts ... It looked to me like there were too many per layer, but this overall number is probably reasonable in a difficult environment like yours. LP should still work, but might require more training. > > What config did you use (before the 'saved' one)? > > There's no 'saved' config, until you save one. > > auto. I thought LP chose a new proxy every time Internet 'call' to LP for > proxy address. Does LP do that, or just search for the best proxies its > already used. At the time the back end runs it selects 10 proxies for each layer. The database is searched for the best ones for each service, commStrat, speed, reliability etc. No dynamic tests are done at this time. As soon as the build is complete all the layer 0 proxies are tested to see if they are alive. None are discarded, but if they appear to be dead, they are demoted so that LP will not choose them as often. In use, LP will occasionally try them again, but will mostly use the good ones. As you use it, LP will concentrate on the good ones more and more. If you save the config (use 'saved', or 'last'), this learned info is available as soon as LP starts up the next time. [...] > > With autoConfigure you should have been able to find a file > > created called master.log with the log of what happened. > > will it save in xml Not the log file. There's no point. The saved configs are all in xml. > > But we're talking about test/merge. > > Did anything appear on the task bar? > > only in autoconfigure See above. That's ok, the log is in the GUI log window. [...] > meant previous LP installation 10 months ago was .pl but exe seem more > stable Errk. The pl and exe are exactly the same. But I managed to make some improvements in that 10 months :-) [...] > > > > > > 7) During the above tests, there are various files created and > saved. > > > > > > The easy way to find them is by modification/creation date. See if > > > > > > they contain the proxies you expected. Let us know what happened. > > > > > > > > > > config-saved attachd > > > > > > > > Did you find any files created/modified? > > > > You still didn't look for these? > > statproxy out files That's a start :-) No tests-auto.txt file? How could you miss this one? Do you know how to find recently created/modified files? These files tell you exactly what happened. -- wa...@ny... http://proxytools.sourceforge.net/ |
From: gstmoderator <gst...@ho...> - 2003-04-01 10:20:29
|
----- Original Message ----- From: "wayne" <wa...@ny...> To: <noc...@fr...>; <pro...@sf...> Sent: Monday, March 31, 2003 2:53 PM Subject: [noCensorship] Re: DONE--Re: Re: LP > > From: "gstmoderator" <gst...@ho...> > > To: <noc...@fr...>, <pro...@sf...> > > Subject: [noCensorship] DONE--Re: Re: LP > > > > wayne- > > > > thanks for your help. running JAP I was having same problem. Turns out now > > I'm on a LAN and locations to set my proxy were different. No problem. > > > > thanks again. > > I'm commenting below anyway. > You (and others) might find it useful yet. > > Here's the overall summary of my comments below. > You chose proxies which all failed on every test, for LP to > 'test/merge'. As a result, it (correctly) didn't merge anything, > and you didn't see them in the reloaded configuration. > > You would have been better off just letting LP do it's job. > It has a database of thousands of proxies to choose from, and > would have chosen ones which worked there. > There is a common feeling that the user needs to tell LP what to > do, but the truth is that it knows better than 99% of users, and > what it doesn't know it learns after a bit of use. > I didnt know LP had the proxies built in so I thought I had to add them. thanks for clarifying. > I think that answers all your original questions, but I have a > couple: > 1) I'd like to confirm that LP works when you leave it alone and > just try to use it for (say) web browsing without adding your own > proxies. Did you ever get that far? If it doesn't work (and you're > still interested) please post some logs from the back end window. > 2) I'd like to confirm whether or not that window (or task bar > icon) actually appears when you use 'test/merge'. I recall a problem > reported on XP, but I thought it was fixed a long time ago. It would > only affect operation of 'test/merge'. I guess I'll have to do > this myself on an XP system, if I can find one. the window only opens on autoconfigure. when I get the chance I'll run it and post log for you. > > > > From: "gstmoderator" <gst...@ho...> > > To: <noc...@fr...>, <pro...@sf...> > > Subject: [noCensorship] Re: LP > > [...] > > > 1. open lp using saved config > > 2. put proxies in box from hat 141.150.149.247:80, 208.49.206.97:80, > > 204.196.215.9:80, 64.48.186.225:80, 208.218.142.13:80 Echo= 11687 > > 3. push test/merge > > 4. localproxy2 window log > > > > This is localProxy Engine (the 'back end'), version: 4.214 > > Loading configuration saved > > Waiting for the front end to connect ... connected > > Checking all layer 0 hosts for connectivity... > > Couldn't connect to 33 proxies > > Why so many? > What config did you use (before the 'saved' one)? > There's no 'saved' config, until you save one. auto. I thought LP chose a new proxy every time Internet 'call' to LP for proxy address. Does LP do that, or just search for the best proxies its already used. > > > Don't panic, I can probably work ok without them > > > > LocalProxy is offering services on the following ports: > > 10076:non-censoring HTTPS proxy > > 10077:PROPFIND capable HTTP proxy > > 10078:HTTP zapped advertisement proxy > > 10079:proxy autoconfiguration > > 10080:anonymous, non-censoring HTTP proxy - standard > > 10081:localProxy control > > 10082:non-censoring HTTP proxy - standard > > 10119:Usenet news - panix > > 11119:Usenet news - mozilla > > > > > > For web browser proxy service, please configure your web browser > > http proxy entry to localhost:10082 and the > > https proxy entry to localhost:10076 now > > > > 5. localproxy log > > > > This is localProxy GUI (the 'front end'), version: 4.247 > > Proxies found in environment: none > > I'm assuming this IP address is 192.168.1.101 > > I'm assuming this IP address is 192.168.1.101 > > Setting default config syria-scs-net > > Starting localProxy engine with configuration: saved > > start line: perl localProxy2.pl -x 0 -g -d 0 -c saved > > running localProxy2.exe > > So the back end is running *before* you test the proxies. > > > Checking proxy capabilities ... > > Extracting proxy strings, safeing, expanding/skipping ports, > > validating, resolving, deduping... > > 1 proxies to test (after processing) > > ctrl-c to see results so far; double-ctrl-c to abort > > Running test: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 > > 19 Results have also been written to file statProxy.2003.3.30.22.out > > > > statProxy v4.143 report from 192.168.1.101(syria-scs-net): > > This is the 'LAN' you were talking about. > We're all on a LAN, of some sort, but yours is a private address > lan. This is special - packets to addresses like yours will never > be routed acrosss the internet. For you to be able to talk to > *anything* on the internet outside your lan, you must use a router > of some sort (something with an address on your lan, an address > on the real internet and the capability of switching packets > between the two. Remote sites will think they are communicating > with this router. > > In your case, your ISP's proxies are probably handling this > for web browsing. Other services (your JAP access, for example) > would be being provided by a NAT. > > BTW, 'syria-scs-net' is localProxy's guess at your ISP/firewall. > It's done by looking at your address, and finding the best match > in the firewalls database. Syria-scs-net is the first one it found, > but there are millions of such addresses (those addresses are > not routable on the internet, so they can be reused in different > locations). No harm done, but wrong (in general) and confusing. > I've changed it to indicate a private address in future versions. > > > 141.150.149.247 :80 FFFFFFFFFFFFF FFFFFF 1.2/? > > These results are all bad, so when these tests are complete, > there is nothing of interest to localProxy (or you!), and > nothing needs to be merged to your configuration file. MergeHosts > will simply ignore any proxies where where *every* test fails. > > Port 80 looks like a bad choice for you - you need to test > proxies on other ports. 3128 and 8080 are probably also blocked. > Try this one: 24.129.32.175:9631 > Test it quickly by using: > statProxy -t 0 24.129.32.175:9631 > If that passes ('P'), then do the localProxy 'test/merge' and > you should find it in the config you specify. Note that this > is unnecessary, because LP already knows about this proxy - > it's in the database. See the summary above. > > [...] > > > Done ... writing results to tests-userSpecd.txt > > MergeHosts.pl v4.48 > > merging tests-userSpecd.txt to config-saved.xml > > (saving original config-saved.xml in config-saved.old.xml) > > Test location firewall: syria-scs-net > > Ignoring all test results (except uptime and socks) for any > > hosts on port 80 - known transparent proxy > > [...] > > Nothing actually happened here - no results were worth saving! > I've added a message to this effect. > > > This exe file was created with the evaluation version of Perl2Exe. > > For more information visit http://www.indigostar.com > > (The full version does not display this message with a 2 second delay.) > > ... > > > > > > > > 6. none of proxies are then used during internet or when I close and restart > > LP using saved config (no error stats) > > None were merged to the config. This is expected. > > [...] > > > > Let's clarify: > > > 1) you enter proxies into the field above 'test/merge new proxies' > > > Or you leave the entries that are already there. Use the right format: > > > proxy.xxx.com:8000, proxy2.yyy.etc:8999 > > > etc. (say). > > > > yes > > > > > 2) you click 'test/merge new proxies' > > > > yes > > > > > 3) a window opens (or appears on the task bar?). On XP, I think > > > it should have a title containing the command used to run it. > > > Warning, I don't have an XP system to test on, so I can't be > > > precise here. This might be the area where the problem lies - the > > > window/icon may not be appearing at all. I had some XP problems here > > > before. If that's the case, I'll need to find an XP system. > > > > window opens if I run Autoconfigure instead of test/merge > > Hmm ... they are done in different ways, so that's interesting. > With autoConfigure you should have been able to find a file > created called master.log with the log of what happened. will it save in xml > > But we're talking about test/merge. > Did anything appear on the task bar? only in autoconfigure > > > > 4) in that window, you should be able to watch statProxy testing your > > > proxies. If it closes too quickly, you probably gave it a bad proxy > > > format. If the reason is not obvious, I suggest you run statProxy > > > by itself in a command window with the proxy format you used to see > > > what error is reported. > > > > see above--no errors > > > > > 5) the merge of these results to a config are done back in the GUI > > > (by calling mergeHosts). > > > > > > I'll wait to hear what the log window contains. > > > > like I said, I've run LP on XP though it was .pl not .exe. > > You said you ran the LP exe (see your comment a few lines down). > No matter though, the whole 'problem' appears to be your bad > choice of proxies to test. > Basically, LP knew better than you :-) > See my summary above. meant previous LP installation 10 months ago was .pl but exe seem more stable > > [...] > > > > > > 5) Which LP are you using (version number, executable or source)? > > > > > > > > 4.247 exe I think > > > > > > Damn, that makes things difficult. > > > > > > > > 6) You might be able to run the GUI window (localProxy.pl or .exe) > > > > > with debug turned on - later versions only. > > > > > > > > > > 7) During the above tests, there are various files created and saved. > > > > > The easy way to find them is by modification/creation date. See if > > > > > they contain the proxies you expected. Let us know what happened. > > > > > > > > config-saved attachd > > > > > > Did you find any files created/modified? > > You still didn't look for these? statproxy out files > > [...] > > > thanks again > > -- > wa...@ny... > http://proxytools.sourceforge.net/ > ===8>============== noCensorship community =============== > List's webpage: http://www.freelists.org/webpage/nocensorship > List's archive: http://www.freelists.org/archives/nocensorship > To unsubscribe: noc...@fr... with 'unsubscribe' in the SUBJECT field. > Moderator's email: noc...@fr... > ===8>============== noCensorship community =============== > > > |