Fake files, or what...?

[stigbye1]

When searcheing for "glasgow rangers", here is what I got (this is a copy-and-paste of several "pages"),  With some exceptions, none of these are identical in size, and none of the sources respond when trying to view the user:




Something caused me to srcatch my head a little though.  Although the file itself doesn't origin from me as none of the files listed above is an exact match of the original filesize (see below), I did however and immediately recognized the filename as that is my own "file naming system" (that I used some time to construct) as seen in the following excerpt from the shared file list in WinMX:

[Lagerlout666]

Hmm strange, ive just done a search and i can see your available files but i dont see any of them. Ill monitor this though and thank-you for bringing it to out attention

[stigbye1]

( Addendum to my original post. )

When jogging my memory, I have actually seen this a few times before, and this it more specifically what I recall to have noticed in these cases:

• These mysterious files are usually the ONLY files showing up in the search results, i.e. none, or very few, other files are shown.
• It's only MP3-files (at least what I've seen).
• The search result may be several "pages" long (as seen in the example in my original post).
• Although all files have the EXACT same file name, all files - with some exceptions though - are slightly different in file size and/or length (min:sec).
• The user/source for these files are ALWAYS shown as having at least one available download slot, i.e. they never appear as having a queue.
• When trying to download any of these files, the download will never start, i.e. it simply time-out trying to establish connection with remote host.
• When trying to view user information, it always result in a "No response from remote host." error (although I haven't tried every single one when there are many).
• This appear to be present with specific hosts/nodes only, as the problem vanished as soon as I disconnected and then reconnected WinMX to the network, i.e. when WinMX found another host/node to connect to - see Note 1.

Note 1:  Unfortunately I didn't think of it, but as I have a Network/TCP-monitor continiously running in the background, I could have seen exactly what host/node (host IP-address and port) WinMX were connected to while this "problem" was present...

[GhostShip]

Can you confirm your using the Community patch Stigbye1, also as you may be aware, this is just the sort of result you will see if the blocklist has not loaded correctly or is blocked, can you check all these possibilities out and get back to us please, I checked this title myself and didnt get a mass of results so  I dont think the problem is one for the blocklist team although they have been informed to be extra vigilant 

[stigbye1]

As seen in the following and partial screen snapshot, I am using the Community Patch:




However, I'm not quite sure if the block list is correct loaded.

[Me Here]

Just wanted to let yall know, I've investigated this and here is what I can say without a doubt at this time:

Stigbye1, those files are  being faked and flooded onto the network they are especially targeting the Eiffel 65 track 'I'm Blue', this track comes up with thousands of results not just the Glasgow Rangers one.
The IP's being used to flood those results that I am able to track here, are indeed on the block list
MediaDefender       :72.172.91.94-72.172.91.116

It's likely that your blocklist didn't load at the time you started WinMX, and usually a quick fix is just to restart WinMX.  Its not unheard of that there are occasions that the list doesn't get passed to you fast enough from a cache, a lot like the occasion page on the internet not loading regardless of everything being in working order.

As for the naming being so similar to you, you know that saying "imitation is the sincerest form of flattery"...its happened to me many times, in fact I used to quite enjoy a laugh out of it, I'd name a file with cD1  and watch them copy it to fake up their fake files and make them more 'real' looking.  Don't be alarmed by it, its not uncommon, we've seen them also use common room tags, the Axxo or other scene labels as well..

Hope this helps and thanks for bring it to our attention.

[stigbye1]

Actually, I don't have WinMX running continiously, so WinMX has been restarted several times.

When WinWX connect to the cahce(s) to get the block lists, do WinMX then use some specific and "non-standard" ports?

Just wondering as I'm on a local company network where I know several ports are blocked in firewalls and/or routers.

Actually, to get WinMX to be working at all (connecting, downloading and uploading), I have to use an external server that "tunnel" all traffic to and from WinMX through the local network using standard TCP port 80 (HTTP).
A backdraw with this method is slower download/upload speed compared to a direct connection, except there is a small benefit though.  As all network traffic from my local computer through the local network and to the external server is 100% encrypted, the local network administrator is completly unable to monitor/view what's actually being transferred.... 

[Lagerlout666]

Its possible using this method then that the connection part managed to get threw but the blocklist may not have. I have seen this before myself when the blocklist request upon connection times out. Their is abit of a delay till it checks again and its possible it may have just been timing out alot. As you are using a diffrent setup to most that add's overhead to all your packet transfers any extra delay would affect the blocklist request. As pointed out we have noticed this in the past on both patchs but it is very uncommon, an the quickest way to rectify it is just to restart winmx.

[stigbye1]

Now I just experienced this "problem" again.....

This time, I immediately checked the proxy tunnel client to check the IP-address of the remote host WinMX was connected to while this incident was present:

Application :	WinMX.exe
Local host / Source (IP:port) :	127.0.0.1:1080
Remote host / Destination (IP:port) :	220.208.84.132:6699
Status :	Connected / Active
Local computer address (IP:port) :	192.168.100.140:80
Local network gateway address (IP:port) :	192.168.100.1:80

When doing an IP-lookup on the remote host IP-address, I got the following result:

IP-address :	220.208.84.132
Host name :	u19132.koalanet.ne.jp
ISP :	JAPAN CABLENET LIMITED
Organization :	Koala Television Co., Ltd.
Proxy :	(none)
Country :	Japan
City :	Tokyo

[Lagerlout666]

Thats just a user running primary, its nothing to do with them, you dont get the list from the primarys. you get the list from the caches. We have currently just restructured the DNS entrys for the patch after you posting your problems and i have to say everything here is running 100% optimum our end. If you are still failing to get the blocklist im affraid it is more than likely the setup that you have running. I cant say that full proxy support for all setup's can be fully supported. As your setup is one that is very uncommon. During the beta tests we did test proxy support but only via the standard socks 5/4 proxys that winmx supports.