Menu
▾
▴
[proxyTools-users] Re: [noCensorship] Re: Fed up with LP
|
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/ |
