WinMX peer network crashed?

[stigbye1]

What im suggesting is killing the HTTPtunnelClient.exe and just using the socks4 address from their website in the winmx settings.
or if the HTTPtunnelClient.exe has a section to remove programs from the tunnel then remove winmx from it.

So, will using their SOCKS4 address directly work on port 80...???
As far as I know, the standard SOCKS network port is 1080, which is within the port range my local network provider usually is blocking in their firewalls/routers, and lead me back to the basic reason why I have to use HTTP-Tunnel for both WinMX and other applications that use ports usually blocked.

Theres not much way to tell if the person on that forum who tried to help you use winmx without even googling it is employed by the tunnel website or not.

Actually, and to be more precise, that person is employed by the company and working in a corporate branch office.  Back in the beginning of 2007 I also had some direct contact through eMail and a few "snail-mail" (where I also got his corporation business card)...

It is appearent you need to continue to study on what a proxy is because you seem to be confused on how your own set up works.

My description on how the tunneling service is working is very much based on descriptions I got from others, and is of course aware of that something may not be quite correct.  On the contrary, even those who call themself experts can be wrong..........

Using socks5 through an http-tunnel proxy is overkill.
its surprising you ever connect at all with the networks timeout setting.
The main difference between socks4 and 5 is all dns queries go through the proxy with 5
this is why winmx benefits from using socks4

How SOCKS actually work, that you're surprised that I can connect at all, and the benefit of one SOCKS version than the other, is not the primary issue in this thread.

The true and indisputable fact is that I have now used WinMX - by using SOCKS5 - through HTTP-Tunnel for more than two years, and haven't had any problems getting WinMX to connect at almost every connection attempt throughout this period -- until recently..........

Actually, I'm just trying to find the cause of this mysterious problem that suddenly occurred, i.e. if this is related to the HTTP-tunnel servers (which I primarily suspect based on what I see in log files and other behaviours) or not.....

[Forested665]

Actually, I'm just trying to find the cause of this mysterious problem that suddenly occurred, i.e. if this is related to the HTTP-tunnel servers (which I primarily suspect based on what I see in log files and other behaviours) or not.....

Wich is precisly WHY i told you to remove winmx from the http tunnel proxy and use SOCKS4 or SOCKS5 directly.
If your ISP blocks it then oh well, You can try it faster then you can mope about it and try to find out. If it works then you saved yourself alot of hassle and know that its the http tunnel.
You said only some of the servers prevent the connection was their IP the same as the SOCKS servers or were they http?
If not and your isp doesnt block it (most ISPs dont because it would infringe your privacy rights) then this should solve your problem.
Theres only three outcomes to trying winmx with socks outside of the tunnel:
A) Your ISP blocks it
B) We determine the problem also exists within the SOCKS server
C) you connect, it works, and we move on

@nylly Thanx hun =)

[stigbye1]

Although this should be apparent from some of my previous replies to this thread, I going to be a little more precise:

The actual problem is NOT that WinMX cannot connect, the problem IS that WinMX cannot connect...!!!

Sound strange?  First I'm actually saying that WinMX CAN connect, and a moment later that WinMX CANNOT connect.

Now, let me explain further:

As far as I know, a succesful WinMX connection (changing from flashing yellow to steady green) can be summarized in three basic steps that must be fulfilled:
1.  WinMX connect to a cache server.
2.  The cache server return a peer list to WinMX.
3.  WinMX connect to one of the peers from the peer list returned from the cache server.

When I first said "The actual problem is NOT that WinMX cannot connect", this was regarding to the cache server connection (step #1 above) as this is usually always succesful.

In the HTTP-Tunnel Client, the status message "Remote server accepted connection." indicate that a remote server (e.g. a WinMX cache server) accepted the HTTP-Tunnel connection request, and that an application (e.g. WinMX) now succesfully has established a connection through HTTP-Tunnel with this server.
Therefore, let's take a portion of the same HTTP-Tunnel log file excerpt I used in a previous reply, but now also adding a comment line (shown in different color) below each log file line that more detailed explain what's happening:

<20 : 29 : 11> Client requesting SOCKS5CONNECT to 75.134.104.100:7952
WinMX attempting a SOCKS5 connection through HTTP-Tunnel to cache server 75.134.104.100 on port 7952.
<20 : 29 : 12> Upstream connection #43: Remote server accepted connection.
Succesful connection with cache server 75.134.104.100 established through HTTP-Tunnel.
WinMX is now connected to, and awaiting a peer list from, this server.....
<20 : 29 : 21> Client requesting SOCKS5CONNECT to 115.124.110.120:7951
WinMX did not timely receive a peer list from cache server 75.134.104.100, so WinMX is now trying another cache server by attempting a SOCKS5 connection through HTTP-Tunnel to cache server 115.124.110.120 on port 7951.
<20 : 29 : 21> Upstream connection #44: Remote server accepted connection.
Succesful connection with cache server 115.124.110.120 established through HTTP-Tunnel.
WinMX is now connected to, and awaiting a peer list from, this server.....
<20 : 29 : 31> Client requesting SOCKS5CONNECT to 115.124.110.121:7950
WinMX did not timely receive a peer list from cache server 115.124.110.120., so WinMX is now trying another cache server by attempting a SOCKS5 connection through HTTP-Tunnel to cache server 115.124.110.121 on port 7950.
<20 : 29 : 31> Upstream connection #45: Remote server accepted connection.
Succesful connection with cache server 115.124.110.121 established through HTTP-Tunnel.
WinMX is now connected to, and awaiting a peer list from, this server.....
<20 : 29 : 41> Client requesting SOCKS5CONNECT to 78.47.24.173:7951
WinMX did not timely receive a peer list from cache server 115.124.110.121, so WinMX is now trying another cache server by attempting a SOCKS5 connection through HTTP-Tunnel to cache server 78.47.24.173 on port 7951.
(and so I could continue page up and page down.....)

On the contrary, if WinMX at any stage could'n establish a succesful SOCKS5 connection through HTTP-Tunnel with the cache server, or if the connection otherwise failed due to problems with SOCKS/proxy/HTTP-Tunnel, the HTTP-Tunnel Status message would usually be "Remote server rejected connection." or some other status/error messages.
Therefore, and from the above, this problem is evidently NOT related to whether I'm using HTTP-Tunnel or not, proxy or not, SOCKS5 or not, or even ports blocked by my local network provider.

When I at the beginning of this reply said "the problem IS that WinMX cannot connect...!!!", this was concerning the fact that although WinMX usually and successfully connect to a cache server, WinMX do not get the peer list from the cache server (step #2 above) and thus cannot proceed to connect to a user/peer (step #3 above), i.e. WinMX will remain in the "flashing yellow state".

By doing a thorough analyzation of the HTTP-Tunnel Client log file(s), I discovered that although WinMX usually can establish a successful SOCKS5 connection through HTTP-Tunnel no matter what HTTP-Tunnel server being used, WinMX may only get the peer list from the cache server when using specific HTTP-Tunnel servers.

This, in addition to the fact that this problem occurred suddenly, is why I suspect the problem to be something related to the HTTP-Tunnel servers, even if HTTP-Tunnel claim that there is nothing wrong with their systems.

This is also why I in a previous reply asked is someone else could try a simple test setup using WinMX through HTTP-Tunnel, as if other users also experience similar problems, I will have more hefty evidence trying to convince HTTP-Tunnel to check their systems more thoroughly.....

[bu44er]

I personally tested this for you and I was unsuccessful to connect. There is no problems with the Peer Cache Servers being used and the majority of people can connect without any issues. I hate to say this but the problem is with the Http Tunnel system.

After trying to connect with the HTTP Tunnel setup like your I tried connecting without it and connected straight away.

[bu44er]

I am locking this thread for the mean time until I get to speak with my Supervisors. I can just see this ending up in some silly argument.

[Lagerlout666]

Can you give me a list of all IP's used in this process.

You
Http
Socks proxy

[Lagerlout666]

Also whats the name of this software so i may try to set this up

[Lagerlout666]

Right i have been investigating this. I can confirm that this software is using the new 209 range that was recently added to our block list for performing attacks upon this fine network over the last few weeks. My apologies but im afraid you will need to find some other way of connecting to this network. As the multiple searches conducted on this network raping people of their BW is the one reason why we have a blocklist in the first place. And im sorry that you have been caught up in this but winmx's future and safety is paramount.

Traceroute depicts  127.0.0.1 to thier 207.xxx.xxx.xxx range and thats socksed threw 209.xxx to the caches.

[GhostShip]

The blocked range was slimmed down a bit to ensure innocent folks where not affected but in this case an attacker has compromised the block your using, we will delve deeper into this to see if its possible to slim it down further, although its my belief thats not possible.

[stigbye1]

If I understand this correct, some of the HTTP-tunnel server IP-addresses are within an IP-address range blocked by the peer cache servers.

Why I say "some" is because ALL HTTP-Tunnel server IP-addresses cannot be within the blocked IP-address range, which also make a logical picture regarding how I experience this problem.

As the HTTP-Tunnel servers randomly assign an IP-address from the HTTP-Tunnel IP-address pool when connecting to a remote server (e.g. a WinMX peer cache server), this could then explain why the WinMX connection problem appear to be intermittent, i.e. that WinMX sometimes cannot connect, and sometimes connect succesfully, as I then see only two logical reasons:

• When WinMX CANNOT get a peer list from the peer cache server, and thus CANNOT connect, the IP-address currently assigned by the HTTP-Tunnel server is an IP-address WITHIN one of the blocked IP-address ranges, and ...
• When WinMX CAN get a peer list from the peer cache server, and thus CAN connect successfully, the IP-address currently assigned by the HTTP-Tunnel server is an IP-address OUTSIDE one of the blocked IP-address ranges.

Then the next question arise:

As I don't think an attack or whatever that caused the IP-addresses to be blocked is coming from HTTP-Tunnel (the company in general is too serious for that as in addition to HTTP tunnelling they also deal with business networking solutions used by corporations, organizations, banks, governments, etc.), and if that were the case ALL HTTP-Tunnel IP-addresses should already have been blocked...

Therefore, and if knowing the exact IP-addresses that HTTP-Tunnel use within an address range, is should be possible to individually block all IP-addresses within an address range EXCEPT those IP-addresses explicit used by HTTP-Tunnel.

As an example, take the IP-addresses used by the HTTP-Tunnel Client when connecting to an HTTP-Tunnel high-bandwith server.  Currently, there are eight high-bandwidth servers the HTTP-Tunnel Client can use, and although all these are within the 207.176.6.xxx range, it's only eight explicit IP-addresses actually used.
Here is the complete list of these IP-addresses, and where other IP-addresses in between these end up at other servers/domains/companies when doing some random traceroutes:

HTTP-Tunnel Client --> HTTP-Tunnel high-bandwidth server #1:   207.176.6.32
HTTP-Tunnel Client --> HTTP-Tunnel high-bandwidth server #2:   207.176.6.48
HTTP-Tunnel Client --> HTTP-Tunnel high-bandwidth server #3:   207.176.6.64
HTTP-Tunnel Client --> HTTP-Tunnel high-bandwidth server #4:   207.176.6.132
HTTP-Tunnel Client --> HTTP-Tunnel high-bandwidth server #5:   207.176.6.164
HTTP-Tunnel Client --> HTTP-Tunnel high-bandwidth server #6:   207.176.6.180
HTTP-Tunnel Client --> HTTP-Tunnel high-bandwidth server #7:   207.176.6.196
HTTP-Tunnel Client --> HTTP-Tunnel high-bandwidth server #8:   207.176.6.212

In addition, and if I recall correct, the HTTP-Tunnel low-bandwith server (free non-subscribing service) use 207.176.6.148.

[Forested665]

I am speaking out of place on this.
Attacks on the network can be something as simple as a malformed packet that the provider would know nothing about and wouldnt pick up on their software. so the ranges that were used to carry out the attack are blocked.

Try using a SOCKS WITHOUT the http tunnel server.
As i said before chances are port 1080 isnt blocked.
I will not continue to post until you provide feedback with the results of the steps i have given for you to take as i have repeated them twice and cannot offer anymore advice without knowing the results of said measures.

[stigbye1]

Some time ago, I tested another program that can be used to search for and connect to hundreds of world wide proxy servers, both HTTP, SOCKS4 and SOCKS5.
When using the feature "Proxy locator" to automatically finding proxy servers, the program found around 1500 proxy servers.
Thereafter, the program performed an automatic "Proxy test" to test all proxy servers found (server actually exist, server ping, network/server port availability, etc.), but then the majority of servers failed, usually during the "port" test...
Finally, the around 1500 proxy servers initially found was suddenly reduced to approx. 40 useable proxy servers - ALL of them HTTP-proxy servers using port 80.....

[stigbye1]

Has there been made any changes to the IP block list...?

If we assume the nature of problem is that some of the HTTP-Tunnel IP-addresses were within the blocked IP-address ranges, I currently have more succesful connections than failed connections, i.e. the quite opposite of what I recently experienced.....

[Forested665]

The Blocklist is no secret
you can see it here https://www.winmxworld.com/files/block_list.txt

[bu44er]

I am locking this thread once again. This time due to the fact that we are going around in Circles. I will have a word with My Supervisor and see if we can resolve this by removing certain IP's from the blocklist. Please send me a personal message Stigbye1 and I will report back after asking.