Wow! Someone that knows what they're talking about!
 

You're quite correct. The in-bound connection will be made through any private port. This whole conversation was just some unregistered user claiming there was something that made ports 2000 & 4000 special or unblockable.

I have one disagreement though. While port 80 will never be blocked, having Gnutella clients all running on that port isn't such a good idea. First because so many are using that port for http. Second, because it would be very hard to differentiate between Gnutella servers and http servers. At least with port 5190, it's easy to tell the difference if the port is used for AIM or gnutella, and there wouldn't be a lot of false positives when scanning for hosts.

As far as FTP... Passive mode is as functional as non-passive mode, so I wouldn't suspect ISPs would be opposed to blocking anything unused above 1023.


One minor correction, the range includes 1024 as well.

Re: Wow! Someone that knows what they're talking about!
 

Perfectly true - but actually that was kind of what I was thinking. ;0) It would look much more like normal trafic to the ISP. As far as false positives go, most Gnutella peers wouldn't have much of a problem. Since a web server wouldn't send the Guntella connect string, the connection would just be dropped (actually probably quicker than if it timed out connecting to a stealthed port or dead IP address). Also downloading in Gnutella basically acts like a webserver anyway. Many of the peers now even return a webpage if you connect with a browser.

No problem behind a company firewall, but too many Internet doo-dads have built-in FTP for one thing or another that defaults to active (thought I'll admit I don't understand why passive isn't a universal yet). ISP's would be reluctant to block it becuase they'd probably get complaints that people's Budwizer frog news ticker and bass report wasn't working.

Actually, on second thought, we should be thanking our lucky stars for active FTP, pain that it is, just because it makes it harder for an ISP to justify banning all incoming connections. In fact, it would probably be a good idea for programmers to make as many pointless, gimmicky, apps with AOL-appeal as possible use incoming connections! ;-)

Right, I messed up there!

Oops!
 

My browser died and I forgot to sign-in again! Still the above post is actually me.

Re: Browsers port
 

[QUOTE]Originally posted by Informant
Browsers use ports in the 2000 and 4000 number range for connections BACK from the server sometimes, so you could use them as they would probably not be blocked.[/QUOTE.

Do you know nothing about TCP/IP and port blocking? You web browser creates a connection from localhost:2000 or somesuch to www.remotehost.com:80 to use the web. Connections with a remote port of 2000 could be blocked while connections coming from port 2000 could still be allowed to run. Firewalls would really disrupt connections to the internet if this was not the case.

boring...
 

There are already filters that watch packet content for several applications, so this would most likely exist for gnutella as well. Read some other posts on this forum for examples. Ports are just the easiest way to block stuff like this, however if an ISP decides to filter the data then there is not a lot that can be done about it escept maybe open an SSH connection.. which would not be hard either for an ISP to see.

If an ISP wants to block gnutella, it can do so very effectively.. Will they? I doubt it.

Tam

oh and btw...
 

netst -an partly cut/paste

TCP 192.168.0.25:2427 66.28.32.107:80 TIME_WAIT
TCP 192.168.0.25:2433 216.239.35.119:80 ESTABLISHED

Looks to as they are in the 2000-4000 range.. but this is not guaranteed to be so. Oh well..

Re: oh and btw...
 

It's the outgoing port. If I were to block 2433 and 2427, I'd still get a connection to port 80 on the remote machine. I think that was the point later on the discussion (although quite unrelated to the initial topic I must say).

-- Mike

you can configure your firewall to block or allow both ways

ie:

add allow all from 10.0.0.150 2000 to 10.0.0.151 80
add deny all from any to any

this would only allow a socket connection to port 80 on 10.0.0.151 if 10.0.0.150 would actually bind their socket to port 2000.

Anyway, its a mute discussion. Its more fun to squable about protocols :D

so
 

So... I tried to read it all, and I still clueless.
I'm behind a firewall, the messenger, the icq, and the Y!, works fine, maybe they are using port 80 or 21.... I don't know.

The LimeWire can't connect automaticly, will I be able to use it connecting to other server/port? or I better give up and desinstall it and forget all about this.

Thanxs

It might be you are encountering the 'ultra-peer' bug. Try another client maybe? there are many and they all like things a bit differently.