P2P-Zone - View Single Post - port blocking, throttling, and scrambling

db_ · 16-07-02, 08:05 AM

Hi.

The RoadRunner block on the default WinMX listening port 6699 has been going on since at least January this year. The block only affects certain areas of the RR network, in particular the Texas regions Houston and Austin regions were reported by users frequently as having the problem. The 6699 filter usually allowed an outside user to connect into the RR users 6699 serving port, the transfer would usually get to around 8KB - 30KB before stalling and timing out completely.

The easily 'solution' to this was for these users to specify a port number other than the 6699 port. This then circumvents the 6699 block that RR are running and allows uploads to operate as normal. Another problem that's been occurring it seems is that these same RR users are finding they can't search for files on the network correctly, reporting searches for popular artists failing very early in, only a handful of results returned before stopping completely. It seems that the RR 6699 block is not only filtering incoming connections to RR users 6699 server ports, but is also filtering external 6699 connections. The RR user initiating a search for a file asks the/other Primary connections it's connected to, and it's invariably connected into these other Primary users via their 6699 port, and so if the RR block is restricting search results, it's restricting *external* connections to 6699, this IMO is unjustifiable, but I'm sure RR if faced with it could make up a reason to justify blocking the service WinMX, and not just incoming connections to their users.

Looks summit like this...
An off-net user connects into a RR user to download a file...

DL'er:1663 connects into RRuser:6699

The filter prevents this from operating, no problem, it seems the filter is also filtering outside 6699 connections though like...

RRuser:3527 is connected to PrimaryUser:6699 (superpeer)

When the RRuser initiates a search request, it asks the Primary, or Primaries it's connected to for results, and those Primaries ask every other Primary, all the results get returned to the initial Primary that the RRuser is connected to, and then received by the RRuser on their already established 3527 to 6699 connection. If the results are falling under the filter that RR have in place, they are not filtering their own users operating servers on 6699, they're in fact filtering users on external other networks running on the 6699 port. How an ISP can justify this I really don't know.

damn, did any of that make any sense or what? :-)

Anyway, the way I see it is the solution is.... the clients upon installation and configuration should try to assign a random port, instead of basing every user on the 'centralized' 6699 port by default. You can't assign dynamic ports really as far as I'm aware that change per session, etc, as users Routers need configuring with port forwarding very often to enable incoming connections to the client. This means the clients ports need to remain stationary so a Router forwarding rule can be created such as 'forward 16699 packets to machine 192.168.0.200', this requires the client have the port 16699 static. If the client port changes, the Router forwarding becomes useless, and no uploads will take place (note).

So, the clients just need a feature that upon installation of the client it chooses a fairly random port to use, say, anything between 1024 and 5000, this creates a network that is not centralized around a single common port, this means ISP's will find it harder to control specific services through the filtering of the common ports used for the service.

There are other ways an ISP can filter connections, but I think it's not a straight forward thing to do with apps such as WinMX, as the packet data appears as junk, and as far as I'm aware has no repetitive info within the packet to distinguish it as a specific service to be filtered. The Opennap and KaZaa protocols for example are far easier to filter as they contain clear information that can be filtered by using packet rules, you can even sniff a Opennap packet and read in English the user password, username on the network, file being transferred, files being served etc in plain English, this makes a filter rule easy to create. This is a good reason I no longer use Opennap, although I'm not scared of a note from my ISP stating I was sharing blah blah, I just think the protocol is insecure and old compared to what seems to be required nowadays to help protect one's privacy, and protect one's self from being busted. :-D

There is another client I noticed that has implemented the randomized port idea, I'm not sure what it was now, maybe Filetopia, which I was very happy to see added, hopefully it'll become a standard practice as new clients emerge to scatter the ports away from the default presently used.

Right I better shut up now, all the above is only *IMO* and *AFAIK* so there could well be inaccuracies here and there, and there are no doubt things I'm not aware of yet, other methods and complications maybe, but hopefully some of it is of interest to someone somewhere. =)

BTW the site mentioned up top is one I made up to help users with WinMX probs, nothing special or anything by any means. I used to have more information directly for the blocked RR users available on the site at one point, but thought it best to not mention the actual ISP anymore in case it stirred any trouble. I know RR where made aware of the info as the users were phoning RR tech and causing mayhem a bit, mentioning 'the site' etc. I did have some interesting RR tech support excuses knocking around at one point, only one person afaik was able to get RR to admit the blocks were in place, the other tech responses were a joke tbh. This all happened around February iirc, I'm surprised it's took so long to come out (with the news of KaZaA possibly now blocked).

All good fun.
cheers.

db

http://WinMXHelp.d2g.com/

16-07-02, 08:05 AM	#12
db_ Registered User Join Date: Jun 2002 Location: underground Posts: 9	Hi. The RoadRunner block on the default WinMX listening port 6699 has been going on since at least January this year. The block only affects certain areas of the RR network, in particular the Texas regions Houston and Austin regions were reported by users frequently as having the problem. The 6699 filter usually allowed an outside user to connect into the RR users 6699 serving port, the transfer would usually get to around 8KB - 30KB before stalling and timing out completely. The easily 'solution' to this was for these users to specify a port number other than the 6699 port. This then circumvents the 6699 block that RR are running and allows uploads to operate as normal. Another problem that's been occurring it seems is that these same RR users are finding they can't search for files on the network correctly, reporting searches for popular artists failing very early in, only a handful of results returned before stopping completely. It seems that the RR 6699 block is not only filtering incoming connections to RR users 6699 server ports, but is also filtering external 6699 connections. The RR user initiating a search for a file asks the/other Primary connections it's connected to, and it's invariably connected into these other Primary users via their 6699 port, and so if the RR block is restricting search results, it's restricting external connections to 6699, this IMO is unjustifiable, but I'm sure RR if faced with it could make up a reason to justify blocking the service WinMX, and not just incoming connections to their users. Looks summit like this... An off-net user connects into a RR user to download a file... DL'er:1663 connects into RRuser:6699 The filter prevents this from operating, no problem, it seems the filter is also filtering outside 6699 connections though like... RRuser:3527 is connected to PrimaryUser:6699 (superpeer) When the RRuser initiates a search request, it asks the Primary, or Primaries it's connected to for results, and those Primaries ask every other Primary, all the results get returned to the initial Primary that the RRuser is connected to, and then received by the RRuser on their already established 3527 to 6699 connection. If the results are falling under the filter that RR have in place, they are not filtering their own users operating servers on 6699, they're in fact filtering users on external other networks running on the 6699 port. How an ISP can justify this I really don't know. damn, did any of that make any sense or what? :-) Anyway, the way I see it is the solution is.... the clients upon installation and configuration should try to assign a random port, instead of basing every user on the 'centralized' 6699 port by default. You can't assign dynamic ports really as far as I'm aware that change per session, etc, as users Routers need configuring with port forwarding very often to enable incoming connections to the client. This means the clients ports need to remain stationary so a Router forwarding rule can be created such as 'forward 16699 packets to machine 192.168.0.200', this requires the client have the port 16699 static. If the client port changes, the Router forwarding becomes useless, and no uploads will take place (note). So, the clients just need a feature that upon installation of the client it chooses a fairly random port to use, say, anything between 1024 and 5000, this creates a network that is not centralized around a single common port, this means ISP's will find it harder to control specific services through the filtering of the common ports used for the service. There are other ways an ISP can filter connections, but I think it's not a straight forward thing to do with apps such as WinMX, as the packet data appears as junk, and as far as I'm aware has no repetitive info within the packet to distinguish it as a specific service to be filtered. The Opennap and KaZaa protocols for example are far easier to filter as they contain clear information that can be filtered by using packet rules, you can even sniff a Opennap packet and read in English the user password, username on the network, file being transferred, files being served etc in plain English, this makes a filter rule easy to create. This is a good reason I no longer use Opennap, although I'm not scared of a note from my ISP stating I was sharing blah blah, I just think the protocol is insecure and old compared to what seems to be required nowadays to help protect one's privacy, and protect one's self from being busted. :-D There is another client I noticed that has implemented the randomized port idea, I'm not sure what it was now, maybe Filetopia, which I was very happy to see added, hopefully it'll become a standard practice as new clients emerge to scatter the ports away from the default presently used. Right I better shut up now, all the above is only IMO and AFAIK so there could well be inaccuracies here and there, and there are no doubt things I'm not aware of yet, other methods and complications maybe, but hopefully some of it is of interest to someone somewhere. =) BTW the site mentioned up top is one I made up to help users with WinMX probs, nothing special or anything by any means. I used to have more information directly for the blocked RR users available on the site at one point, but thought it best to not mention the actual ISP anymore in case it stirred any trouble. I know RR where made aware of the info as the users were phoning RR tech and causing mayhem a bit, mentioning 'the site' etc. I did have some interesting RR tech support excuses knocking around at one point, only one person afaik was able to get RR to admit the blocks were in place, the other tech responses were a joke tbh. This all happened around February iirc, I'm surprised it's took so long to come out (with the news of KaZaA possibly now blocked). All good fun. cheers. db http://WinMXHelp.d2g.com/