Author Topic: WinMX peer network crashed? (Read 12432 times)

stigbye1 · « **Reply #20 on:** April 13, 2009, 05:39:47 pm »

Just to make things clear:

1. WinMX itself doesn't connect through the network. WinMX communicate only with the tunneling client running on the machine using proxy port 1080, i.e. the proxy IP/port settings in WinMX is "127.0.0.1:1080" (or "localhost:1080").

2. The tunneling client is handling all communication from my local machine, through the network, and all the way to the remote proxy server (located somewhere in the US). This communication is using TCP port 80 (HTTP), which is the basic of using tunneling to make applications to work on restricted networks where virtually all ports are blocked, provided minimum TCP port 80 (HTTP) is open.

3. I'm only running ONE instance of WinMX at the same time.

4. My second PC (with Win98) is primarily NOT used on the Internet, although I have the possibility and for example have WinMX on this PC. Actually, this is my previous PC that I just kept because I have some older design/CAD applications that partially use MS-DOS routines and thus won't run correct on Win XP.

5. To rule out possible corrupt installations or files, I installed a new copy of WinMX on a separate disk partition (and with the recent patch), but this installation experience the exact same problem as the original WinMX installations.

6. I have also tried to completly disable the firewall and other similar secutiry applications that may interfere, but this didn't make any difference.

Forested665 · « **Reply #21 on:** April 13, 2009, 08:44:11 pm »

Have you tried a "random proxy server off the net" as you put it. Just to rule out your proxy being the issue.
Also you still havent provided us with the Provider of the proxy.
A peak through their management style and Terms of Service could very well hold a solution.

stigbye1 · « **Reply #22 on:** April 14, 2009, 04:50:21 pm »

The nature of this problem appear to be found, and it's NOT something with my local PC/system or the WinMX installation.

I began to suspect that this could be a problem with the tunneling/proxy servers although the regular status messages in the tunneling client didn't indicate this.
Therefore, and to get more informations, I temporarily configured the tunneling client to use the highest log level, which normally shouldn't be used as this will generate VERY HUGE log files and also use a considerably amount of system resources. Running the client with this log level setting generated a log file of approx. 8 MB in less than 30 minutes.....!!!!!

By wading through and analyzing thousands of log lines, I discovered the following:

Whenever this problem was present and WinMX didn't connect normally (constantly flashing yellow), WinMX did however, and at every connection attempt, succesfully establish a connection through the proxy server with the WinMX cache servers.
However, and for each succesful cache server connection, there was some further down in the log file some log lines that indicate that the problem could be related to the proxy servers.

As the proxy provider have a pool of many proxy servers, each with a unique IP-address that is randomly assigned to the tunneling client when connecting, I therefore got further indications and proof when I from the detailed log file discovered that the WinMX connection problem ONLY occurred when the tunneling client used specific proxy servers IP-addresses.
This is therefore the explanation why WinMX sometimes connected succesfully ("good" proxy server IP), and sometimes not ("bad" proxy server IP).

nylly444 · « **Reply #23 on:** April 14, 2009, 07:59:56 pm »

Is there a chance that one of the proxy IP addresses matches our blocklist ranges and therefor gets rejected by the cache?

Have a look at it and compare.... https://www.winmxworld.com/files/block_list.txt

stigbye1 · « **Reply #24 on:** April 14, 2009, 10:31:15 pm »

Nope! The tunnelling/proxy servers use several IP-addresses within the address block 207.176.xxx.xxx.

Forested665 · « **Reply #25 on:** April 14, 2009, 11:49:20 pm »

In the mean time I Shall make the suggestion to block outgoing connections to the proxies that dont work.
Increasing the chance that you will hit good ones.

Lagerlout666 · « **Reply #26 on:** April 15, 2009, 07:16:08 am »

The thing with the caches, is that the test each connection that comes to it. So if they get a request from a ip, and it doesnt get a response, it wont send a nodes list. So if one of the proxy's arent allowing the check back threw to you, or is timing out at the cache, then you wont ever get a list.

An before someone ask's. why do the caches do this. The caches use your ips to pass onto others. These new caches though store the encrypted IP's in memory so a machine can be closed and all trace of it is gone. Just incase as you never know. And with the test we know their real unlike the amount of junk dead IP's you get from sabers servers.

stigbye1 · « **Reply #27 on:** April 20, 2009, 08:37:21 pm »

The never ending case...

Recently I posted a thread on the tunnelling providers support forum.

From the replies I've got, I've not been any wiser on this problem, and I think they partially is some misinformed and/or don't know exactly what they're saying (partially because they start talking about LimeWire).....

Here is my initial post on their forum:

Quote

There are currently problems getting WinMX to connect through HTTP-Tunnel.
Although the HTTP-Tunnel client say that the remote server accepted connection when WinMX is making a connection with the WinMX cache servers, the cache servers do however not deliver the peer list back to WinMX.
According to someone from the WinMX support team, and when using a tunnelling/proxy server (in this case HTTP-Tunnel), this problem may occur when the WinMX cache servers don't get a proper and timely response from the tunnelling/proxy server.
What I've discovered is this:
The problem occurred suddenly on or around Thursday April 9th, and has more or less been persistent since then.
To make WinMX connecting, I may have to rotate through all HTTP-Tunnel servers until finding one that apparently respond correct with the WinMX cache servers.
Sometimes I can't find a "good" HTTP-Tunnel server, and then have to wait some time before trying again.
The problem seem to "rotate" between the servers, i.e. the next time I may have to find one another HTTP-Tunnel server than used the last time.
In addition, as my local Internet connection provider currently is upgrading their systems and temporarily has disabled all port blocking in their firewalls/routers (the reason why I usually have to use HTTP-Tunnel), I've now and until they enable port blocking again had the opportunity to test WinWX (and other applications) without using HTTP-Tunnel, and then WinMX always and almost instantly connect successfully.....[/color][/size]

Now, here is a quote (partially) of the first reply I got from their support staff:

Quote

Do you think that WinMX tested their application with the tunnel client? Or any other tunnelling service for that matter. HTTPTunnel is NOT a Proxy per se.
WinMX reports the problem to be with the proxy and not an issue with their application. Where is the emperical data to support that assertion? I could just as easily state the opposite.
Not every application/nor user may have identical results using the tunnel client. This I know.
I have tested various Gnutella and torrent clients. The 2 that work best for me are LimeWire and utorrent.
WinMX like LimeWire uses the Gnutella network. Making connections through the tunnel client for LimeWire as with WinMX requires that you connect to Ultra Peers.
With LimeWire I toggle the Connect/Disconnect. Sometimes LimeWire can stay on Connect for 5 min or more and have None or only 1 UltraPeer. I deem I have waited long enough > I Disconnect and Connect and within 30 seconds I have Turbo-Charged results.
If you are using the SOCKS configuration and not HTTP you may want to test that you are not inadvertently connecting to the LAN address of a tunnel client server.

Then I replied with the following message:

Quote

Just to make something clear, and based on what I see from how the application behave:
The problem currently present is something that occurred suddenly on or around Thursday April 9th as far as I recall.
Independent of whether the WinMX application is tested or not with HTTP-Tunnel, I've never had any prior problems using WinMX through HTTP-Tunnel. In fact, I've used WinMX through HTTP-tunnel without any major problems and by using the same setup/configuration for a long time (more or less since I first time discovered and used the HTTP-Tunnel service back in 2006) using either the free low-bandwidth service or the high-bandwith paid service.
As I may have to rotate the HTTP-Tunnel servers to be able to get WinMX to connect, I have also noticed the following:
1. Let's say WinMX currently have a successful connection through HTTP-Tunnel server IP .180 (example only), and as long as being connected to this IP, I can disconnect and reconnect WinMX several times without problems.
2. However, if I switch to another server IP (Configure -> Test) and then try to reconnect WinMX, WinMX may not reconnect at all.
3. If I try another test by continiously switching between different HTTP-Tunnel server IP's between each WinMX connection attempt, I have noticed that WinMx often can connect when using specific IP's, and fail to connect when using other IP's.
However, this may "rotate" as if I do this later, the server IP's that is "good" and "bad" may be different.
[/color][/size]

Next, I got the following reply from the support staff:

Quote

Let me make something CLEAR.
If it was working well before and is not working the same now. Then: Something in the enviroment that all the factors ( Tunnel client, WinMX, etc ) were functioning under has changed. HTTPTunnel has NOT changed.
You may exclude HTTPTunnel from the equation.
You should look elsewhere and investigate the local machine or network for the variable that may be causing your issue.

... and thereafter this:

Quote

Just now> With the tunnel client connected for over an hour to the same server. Sitting unused > A stale connection > I start LimeWire and have Turbo Charged results in less than 5 min. I am also using my personal firewall ( Sygate ) to block LimeWire's access to the internet ( This insures no errant or lagacy connections are being made.) > LimeWire must use the tunnel client.
I searched for a file and download it (approx 5 mb ) all in less than 30 seconds.
At this time. All Systems, Services and Servers are at Peak Performance.
HTTPTunnel is: Stable, Static, Reliable, Optimal.

GhostShip · « **Reply #28 on:** April 20, 2009, 11:03:54 pm »

Quote

WinMX like LimeWire uses the Gnutella network.

If the nice chap their bases his assumptions on this he is very much mistaken, WinMX has nothing to do with Gnutella instead it uses its own proprietary two tiered encrypted network and thus his further comments based on Gnutella clients are invalid

Forested665 · « **Reply #29 on:** April 20, 2009, 11:43:57 pm »

Most likely a scammed user:
http://www.gnutellaforums.com/general-gnutella-gnutella-network-discussion/45783-winmx-limewire-same.html
Seems the scam sites dont even bother downloading winmx anymore they just hand you the Free Limewire.

And it seems your tunneling service isnt so friendly either....
I clicked Post reply and instead of tkaing me to a guest post screen or registration I got this...

Direct Link:http://i42.tinypic.com/ifnbxh.jpg

But now that you have inadvertantly handed over some of the information i requested, I can read through your providers terms of use and see if they even allow the use of programs like winmx through their service.
The service they provide looks to be mainly HTTP tunneling (hence the domain name), but i happened to see socks listed on the forum.
you may want to remove winmx from the http tunnel and enter one of their socks servers into your winmx settings, then under host name resolution put in the address of a DNS server that doesnt belong to your local ISP (your tunneling to avoid them right? so why use their DNS).
Then fully close winmx, and restart it.

stigbye1 · « **Reply #30 on:** April 21, 2009, 01:07:11 am »

bacon665:

The "You have been banned ..." screen appear when you try to post on the HTTP-Tunbel forum without being a registered user (they disabled guest posting some time ago due to abuse by spammers).
I sometimes got that myself when I forgot to log in first...

And YES, HTTP-Tunnel DO support P2P-applicaions, and they even advertise with "Superior P2P performance" on their front page.

User guides for some of the applications commonly used through HTTP-Tunnel is found at http://www.http-tunnel.com/html/support/user_guides.asp

And NO, I did NOT intentionally keep my tunnelling provider "secret"............

Forested665 · « **Reply #31 on:** April 21, 2009, 01:15:42 am »

Still yet, Winmx works great with SOCKS4
And is just slightly usable with SOCKS5
I still suggest trying the former without the Http Tunnel and specifying a seperate DNS in your winmx settings.

stigbye1 · « **Reply #32 on:** April 21, 2009, 01:52:48 am »

As I can see, it doesn't make any difference whether I'm using SOCKS4 or SOCKS5.

Anyway, this is still the facts:

I've used WinMX (using SOCKS5) through HTTP-Tunnel more or less continiously since 2006 without any major previous problems...
The connection problem uccurred recently and suddenly without making any prior changes in my local configuration, neither WinMX nor the operating system...
When connecting directly without using HTTP-Tunnel (as I currently have the opportunity to test as my local network provider temporarily have disabled all port blocking in their firewalls and routers) WinMX always connect successfully at every attempt, which clairly should indicate something and somehow related to the tunnelling service...
The HTTP-Tunnel support staff are obviously way misinformed as they - quite incorrect - state that WinMX use the Gnutella network, and also compare the way WinMX connect and operate with Gnutella clients...

Forested665 · « **Reply #33 on:** April 21, 2009, 02:14:17 am »

Forum members are not staff of a company.
We are not frontcode.......
SOCKS is not a tunneling service.
Are you using socks through an HTTP tunnel?
Heres some reading:
http://en.wikipedia.org/wiki/Http_tunnel
http://en.wikipedia.org/wiki/SOCKS

We can't do anything else for you, if the problem persists the next steps would be to either
A) aimlessly change settings until something works
B) wait until the next payment period for the provider and then cancel your subscription.(That also includes finding a new provider)

Did you ever try firewalling the servers that were giving you issues?

White Stripes · « **Reply #34 on:** April 21, 2009, 02:15:48 am »

id find a new tunnel service... seems like the one youve got doesnt know sh-t from shineola...

stigbye1 · « **Reply #35 on:** April 21, 2009, 04:46:43 pm »

Quote

Forum members are not staff of a company.

If this was meant to be a comment to what I said about the HTTP-Tunnel staff being misinformed, then, and as I know after being a HTTP-Tunnel customer for more than 2 years, I can tell you that the person who replied to me with incorrect informations (e.g. that WinMX is using the Gnutella network) in the HTTP-Tunnel forum actually is someone affiliated with HTTP-Tunnel Corporation...

Quote

SOCKS is not a tunneling service.
Are you using socks through an HTTP tunnel?

Obviously, I need to explain a little more on how HTTP-Tunnel actually work, as when I in this case is using the term "HTTP-Tunnel", I'm talking about the HTTP-Tunnel service from HTTP-Tunnel Corporation, and NOT about HTTP tunnel or HTTP tunneling as per regular networking definition.
The following is partly what I know or have found out myself, and partly learned otherwise:

Before I can use any application (e.g. WinMX, eMule, LimeWire, bitTorrent, MSN Messenger, FileZilla, FlashFXP, etc.) through HTTP-Tunnel, I must first start the HTTP-Tunnel Client ("HTTPtunnelClient.exe") installed locally on my computer.
The HTTP-Tunnel Client is actually starting and running a proxy server on my computer (localhost), and this proxy server then handle the communication to and from all applications that should be tunnelled through HTTP-Tunnel.
In every application tunnelled through HTTP-Tunnel, the proxy IP-address should be set to "127.0.0.1" (or "localhost"), the proxy port to "1080" (default, but can be changed in the HTTP-Tunnel Client configuration settings), and the proxy protocol to any of the four major proxy protocols (HTTP, HTTPS, SOCKS4 or SOCKS5) dependent on what protocols the application itself can handle.
Although all tunnelled applications should use the same proxy IP-address and port, the proxy server can simultaneously handle multiple tunnelled applications, even if they use different proxy protocols. For example simultaneously having WinMX (using SOCKS5), eMule (using HTTP), MSN Messenger (using HTTPS) and FileZilla (using SOCKS4) connected through HTTP-Tunnel.
The proxy server transmit/receive data packets to/from the HTTP-Tunnel Client itself, which in turn transmit/receive data packets to/from the remote HTTP-Tunnel servers through the regular Internet connection using standard HTTP protocol port 80 - which is where the regular HTTP tunnelling definition enter the picture.
All data transferred between the local HTTP-Tunnel Client and the remote HTTP-Tunnel server are fully encrypted. This makes HTTP-Tunnel not only suitable for bypassing blocked ports in firewalls and routers on the network, but also for hiding P2P-activity and similar that some network administrators dislike, as due to the encryption it's virtually impossible or at least very difficult for network administrators to find out what's actually going on even if they should probe users network connections...

Regarding this mysterious problem, and that may help to determine whether this is HTTP-Tunnel server related (which I suspect even if HTTP-Tunnel claim otherwise), is if someone else can test WinMX through HTTP-Tunnel.
Setting up a test configuration is very easy, and as HTTP-Tunnel also provide a low-bandwith service that can be used by anyone without any subscription fee.

WinMX / HTTP-Tunnel test setup:
IMPORTANT: HTTP-Tunnel Client can only be used with Windows!

1. Download and install the HTTP-Tunnel Client. Download link: http://http-tunnel.com/HTTPTunnelInstallerv444000.exe
2. Start the HTTP-Tunnel Client.
3. In the "Subscription Key" dialog box, click "Use Free Service".
4. Make sure you see "HTTP/HTTPS/SOCKS 4/SOCKS 5 Servers started on Port xxxx", and note the port number used.
5. First time network configuration: Click "Configure", make sure "Auto detect" is selected and click "Test".
6. If the "Subscription Key" dialog box appear again, click "Use Free Service".
7. In WinMX "Outgoing TCP-connection" settings, select desired proxy protocol (SOCKS4 or SOCKS5).
8. In the "Address" field type "127.0.0.1:xxxx", where "xxxx" is the port number shown in HTTP-Tunnel Client (#4 above).
9. Exit and restart WinMX.

WinMX should now connect to the WinMX peer network through HTTP-Tunnel servers (using the free low-bandwidth service), and in the HTTP-Tunnel Client log-window you should now see what remote IP-addresses and ports WinMX is trying to connect to at every connection attempt.

If WinMX then won't connect at all, and you in the HTTP-Tunnel Client log-window only see connection attempts to the WinMX cache server IP-addresses and ports, then it's not only me having this problem, and the problem is someting related to the HTTP-Tunnel servers.....
NOTE: As this problem may be intermittent, as I've previously mentioned, WinMX may sometimes connect and sometimes not, so you may have to test several times at different times!

bu44er · « **Reply #36 on:** April 21, 2009, 06:15:53 pm »

stigbye1, as what your asking is not the hard to do I will personally test this for you and report back with the outcome. I will be able to give you a fair outcome by the end of the night GMT time.

bu44er · « **Reply #37 on:** April 21, 2009, 06:26:02 pm »

Upto yet I have followed your instructions, set everything up, tried to connect 5 times and got nowhere. I will try and continue tests but it is not looking good.

stigbye1 · « **Reply #38 on:** April 21, 2009, 07:09:08 pm »

Quote

Upto yet I have followed your instructions, set everything up, tried to connect 5 times and got nowhere. I will try and continue tests but it is not looking good.

I assume that WinMX won't connect and remain in the connecting state (flashing yellow).

What I'm curious to know is what you then see in the HTTP-Tunnel Client log-window as that may or will indicate what's actually is happening or if something is wrong (the entire log file - "HTTPTunnelTrace.txt" - is found in the same folder where the client is installed).

Here is a sample from the HTTP-Tunnel Client log file where WinMX cannot connect succesfully through the HTTP-Tunnel, i.e. where WinMX connect to a WinMX cache server, but somehow don't get the peer list from the cache server and the retry another cache server after a timeout :

<20 : 29 : 11> Client requesting SOCKS5CONNECT to 75.134.104.100:7952
<20 : 29 : 12> Upstream connection #43: Remote server accepted connection.
<20 : 29 : 21> Client requesting SOCKS5CONNECT to 115.124.110.120:7951
<20 : 29 : 21> Upstream connection #44: Remote server accepted connection.
<20 : 29 : 31> Client requesting SOCKS5CONNECT to 115.124.110.121:7950
<20 : 29 : 31> Upstream connection #45: Remote server accepted connection.
<20 : 29 : 41> Client requesting SOCKS5CONNECT to 78.47.24.173:7951
<20 : 30 : 05> Upstream connection #46: Remote server accepted connection.
<20 : 31 : 30> Client requesting SOCKS5CONNECT to 74.208.71.148:7952
<20 : 31 : 31> Upstream connection #47: Remote server accepted connection.

Here is a sample from the HTTP-Tunnel Client log file where WinMX connected succesfully through the HTTP-Tunnel, i.e. where WinMX first tried a WinMX cache server (78.105.170.174:7951), then successfully got the peer list from the cache server, and thereafter successfully connected to a peer (86.132.122.141:6699).

<20 : 33 : 06> Client requesting SOCKS5CONNECT to 78.105.170.174:7951
<20 : 33 : 06> Upstream connection #56: Remote server accepted connection.
<20 : 33 : 15> Client requesting SOCKS5CONNECT to 86.132.122.141:6699
<20 : 33 : 17> Upstream connection #57: Remote server accepted connection.

Forested665 · « **Reply #39 on:** April 21, 2009, 07:11:06 pm »

See, if you place a socks proxy inside winmx with your set up you are connecting through the http tunnel to a socks proxy and then to the network.

Quote

the term "HTTP-Tunnel", I'm talking about the HTTP-Tunnel service from HTTP-Tunnel Corporation, and NOT about HTTP tunnel or HTTP tunneling as per regular networking definition.

This is a regular http-tunnel you are just using a proprietary program to do so.
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.
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.

and just for refrence...

Quote

I can tell you that the person who replied to me with incorrect informations (e.g. that WinMX is using the Gnutella network) in the HTTP-Tunnel forum actually is someone affiliated with HTTP-Tunnel Corporation...

By all definition since you are a customer you are also affiliated with them.
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.

Quote

<20 : 31 : 30> Client requesting SOCKS5CONNECT to 74.208.71.148:7952
<20 : 31 : 31> Upstream connection #47: Remote server accepted connection.

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

*edit by nylly: put in the missing bracket to the last quote tag