Movie

Sign In | Sign Up

Post

Need help on yellow light listening port.
Size: Large, Medium, Small Wed May 28, 08 09:28 AM | Category: All
0
By suwatj
From forum_name, BitComet Forum
Hi all, my first post here. I have problems with Bitcomet listening port. I used to get green light some of the times (not always) in the past but currently I only get the yellow or grey light. The initiation are mostly "local" or "Nat Transversal" with no "remote" at all.

Here is my setup:
1. OS: Ms Windows XP service pack 2 without much updates or patches on Intel Pentium 4 2.4Ghz. 512Mbytes RAM. nVidia Geforce FX5500.
2. Bitcomet version: I have tried .70, 1.0 and 1.01 with no better result. Currently running version 1.01.
3. DSL modem : Thomson (Alcatel) SpeedTouch 546v6 with software release 6.1.0.5. It also acted as a 4-port router and the gateway to the internet. Firewall is set to standard allowing portforwarding. Intrusion Detection is enabled.
uPNP is also enabled. It's also the only DHCP server in the local network. My ISP provides 2048/512 Kb connection.
4. Connection: The computer running Bitcomet is hooked up with the DSL modem via an wireless accesspoint Linksys

Wireless-G Broadband Router WRT54GL, firmware version 4.30.5. Here Linksys is acting like a bridge with Wan port connecting to nothing. The BC machine is on wired-Lan not wireless with fix IP number.
5. Three more devices are connected directly to the SpeedTouch. I provided no details here because I think it's irrelivant. All other devices except SpeedTouch have their firewall disabled.
6. Bitcomet is set to listen on port 49999; changing ports had been tried. Global max upload limit is 35KB with unlimited
download according to advices from this board. In the past my upload limit is 50-60 and download 120 KB with no ill effects. Most other options are set to BC default setting. No proxy. Anti-leech on. DHT enabled. NAT/firewall in ICS/ICF enabled. uPNP mapping enabled. Half-open limit is at 10. It was 200 before I tried to change it to remedy the yellow light issue. After that, I cannot use the hacked tcpip.sys anymore because it messed up my system so that I couldn't open up many startup programs including BC.
7. Other softwares currently running in the system: Windows Firewall, Peer Guardian 2 with HTTP block disabled, Orbit
downloader, Nokia Nseries Software Launcher, IVT Bluetooth Bluesoliel, MouseImp Pro, Nod32 antivirus, TightVNC Service, Spybot SD Resident, Logitech Mouse and Keyboard Util, and those hidden pests that are hard to killed for checking and updating their softwares ie. Realplayer launcher or whatever, Adobe Acrobat whatever and so on. Oh, and nVidia nView for desktop management.
If I miss any info, please ask.

What I have already done:
1. Using info from this board and from portforward.com, I set SpeedTouch to forward 3 ports to my computer fix IP; one for Bitcomet, one for Bitcomet eMule plug-in and one for eMule. I have High-ID on eMule and canyouseeme.org checked-out. I can't check the plug-in port. Canyouseeme.org gave "connection refused" as error. I checked each connection while the corespoding programs were running.

CanYouSeeMe.org - Open Port Check Tool
Error: I could not see your service on xxx.xxx.xxx.xxx on port (49999)
Reason: Connection refused

2. uPNP seems to be working ok. Here is Bitcomet v0.7 stats: (IP info edited out)

Default tracker optimization rules file loaded.
Start Listening at TCP Port:49999
Start Listening at UDP Port:49999
BitComet 0.70 is running on:
CPU : Intel® Pentium® 4 CPU 2.40GHz 2405 MHz
RAM size : 511.46 MB
OS Version: Microsoft Windows XP Professional Service Pack 2 (Build 2600)


Windows XP WF Status: TCP Port is opened in Windows Firewall.
Windows XP WF Status: UDP Port is opened in Windows Firewall.
Update Local IP: 192.168.1.xxx
Windows XP ICS Status: WAN IP: xxx.xxx.xxx.xxx
Windows XP ICS Status: TCP PortMapping Successfully Added.
Windows XP ICS Status: UDP PortMapping Successfully Added.
Windows XP UPnP Status: Found urn:schemas-upnp-org:device:WANConnectionDevice:1 [Linksys Inc.]

[http://www.linksys.com/]
Windows XP UPnP Status: Found Service: WANIPConnection
Windows XP UPnP Status: WAN IP: 192.168.1.yyy
Windows XP UPnP Status: TCP Port Mapping Existed!
Windows XP UPnP Status: UDP Port Mapping Existed!
Windows XP UPnP Status: Found Service: WANPPPConnection
Windows XP UPnP Status: WAN IP: 192.168.1.yyy
Windows XP UPnP Status: TCP Port Mapping Existed!


Overall Infos: Torrents: 36 | Peers: 1851 | Sockets: 1957 (HTTP: 147)
TCP Connections: Established: 22 | Half-Open: 10 | Waiting: 1826
LAN IP: 192.168.1.xxx / WAN IP: 0.0.0.0

Overall Download Rate: 5 KB/s Connection Limits: 20 - 40 per task
Overall Upload Rate: 24 KB/s Upload slots: 7 - 12

Disk Cache Size: 38 MB (Min: 6 MB, Max: 80 MB)
Free Phys Mem: 108.84 MB (Min: 50 MB)
Disk Read Statistics: Request: 302 (freq: 1.5/s), Actual Disk Read: 17 (freq: 0.0/s), Hit Ratio: 94.3%
Disk Write Statistics: Request: 79 (freq: 0.3/s), Actual Disk Write: 4 (freq: 0.0/s), Hit Ratio: 94.9%

Total Downloaded: 227.42 GB
Total Uploaded: 438.93 GB

3. On the quest for an answer, I read about Wireshark so I installed the util and got the following results:

501 3.605424 212.35.84.20 maya.lan TCP 36435 > 49999 [SYN] Seq=0 Win=51736 Len=0 MSS=496 WS=4
502 3.605548 maya.lan 212.35.84.20 TCP 49999 > 36435 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

I only include 2 entries as an example. Using filter on TCP port 49999, I had many of the above pairs. Bitcomet or some
agent seemed to RST every attempt to connect to its listening port. None out of all the log entries were successful "TCP 49999>destination port."

4. Using Portreport service downloaded from MS web site, I checked the log and Bitcomet was the only process that had
anything to do with port TCP 49999. Other processes didn't have 49999 in their log entries. The log was too long to be included
here.

5. I turned off windows firewall and SpeedTouch firewall (temporarily). The port 49999 was still blocked.

6. The most puzzling thing is this. I exited Bitcomet and started eMule which I hadn't been using for a while. I changed eMule listening port to use BC port 49999 and got High-ID. I used canyouseeme to verify and the site returned succesful
connection. Why the thing that blocked Bitcomet from listening port, did not block eMule port? Are there differences between the way BC handles ports and the way eMule did them?

I did try many different remedies I could think of or found on the web which included this board, portforward.com, p2pforums.com and many others. So please help. What I need are:

1. A ready-made remedy.
or 2. Suggestion about where I could learn more about the problem.
or 3. Suggestion about tools I can use to find out "what's blocking the port?"

Since english is not my native language, I try my hardest to communicate what happened and what I want. If there
confusion on the way I organize my sentences and writing, please feel free to ask. Thank you for listening.

BitComet
Link: http://blog.bitcomet.com/post/39423/ ©
Add to favorites | Quote Reads (6870) | Comments (12)

Related Posts

CommentsReload

↑
Old_BitComet_Forum Wed May 28, 08 08:41 PM
By kluelos
From forum_name, BitComet Forum
First thing to get clear on, is that there is no "magic" port number. An open port is not something that you seek, like a hidden treasure. It is something that you set, like a thermostat, or the channel of a television.

Next thing is to understand routers. For this you need to study your router's manual.

The router has a firewall. You can instruct the router to open a port on that firewall (which action is sometimes called "forwarding the port", and sometimes called "setting up a virtual server on the port") but only under certain, limited conditions.

An open port is a vulnerability. It's potentially dangerous. Because of that, you don't want to have a port open to a computer or device that doesn't know that port is open and expects it.

Therefore, most routers will only permit you to open a port to a particular and specific IP address, which you must detail in the forwarding rule. Your computer or device needs to be AT that IP address, and it's your responsibility to make that so. If you do not, then the setup won't work.

Set up a rule that says, "Allow incoming traffic, both TCP and UDP, into port number 65432, for IP address 192.168.2.254"

With that rule in place on my router, my computer must have the IP address 192.168.2.254, and if it does not, then port 65432 (and all other ports) will be blocked on all other addresses including whatever IP address my computer does have.

If I have the default windows setup, my computer uses DHCP to ask the router to assign it a random IP address out of a pool that the router keeps for the purpose. (The size and contents of that pool can be adjusted. Let's say the pool addresses all have the first three octets of 192.168.2 and the last octet can be 2 through 255.)

The router gives the computer a random address, as requested. Let's say that 254 is within the pool, and my computer just happens to get 254 assigned to it. My address matches the IP address that the port is being held open for, so everything works. I get a green light.

Then I turn off my computer, go away for a while, come back and turn the computer back on. Again the computer asks the router for an adddress assignment, and this time is assigned the address .3 out of the pool. Now this address does NOT have a port opened for it on the firewall, so this does not work. I get a yellow light.

Every time I reconnect, I ask for and get a random address. Sometimes I happen to get the one address where the port is open, most times I don't. So sometimes my light is green, most times it's yellow, and this seems to me to happen randomly. But it's all because I'm using DHCP to ask for a random address, rather than having set a static address set into my computer for this network.

What I needed to do, was to tell my computer to never use DHCP, but to always use a fixed address of 192.168.2.254 where the port is being held open. Instead of asking the router for an address, I TELL the router that this is my address. It is my charge, as the network administrator, to make damn sure that nothing else on my little network has or can get that same address. MY job, not the router's or the computer's. Mine. If I screw that up I deserve the chaos I'll get.

----- Digression
Ok, now wait a second. Let's say that I have more than one computer. I hook them both up to the router and they both use DHCP to get IP addresses. Sometimes, it could be that my other computer gets the .254 address. When it does, port 65432 is open, and a malicious port-prober could find it. I'm not running BitComet on this computer, and the computer is not even aware that the port is open. That's a security hole. Not good. So this is what the rule is there to prevent.
----- /digression

If I now try to hook this computer up to a modem instead of a router, with those same network settings, I am telling my ISP, through the modem, that I am taking the address of 192.168.2.254, and my ISP will tell me, "not on my network, you're not. Get lost."

I must change my setting BACK to using DHCP and asking for an IP address assignment from them, if I'm going to connect directly to the modem without going through the router. Then I must change it back again whenever I change between the two networks.

I must always adapt my network settings to the requirements of the network I'm connecting to.

It would be great if windows supported various network configurations on a single network card, but it does not and never has. That means that I have to adjust the network settings by hand every time I change, so I need to memorize IP addresses, DNS servers, default gateway settings and so forth for every network I connect to.

(If I get the settings wrong, because I memorized incorrectly, wrote them down wrong, or mistyped when I set them, I will spend an enjoyable couple of hours trying to figure out why I can't communicate.)

I hope you got that very clear. What we accomplished is to allow unsolicited traffic from other computers, into your computer at a specific port. Your bittorrent client is watching that port and receiving that traffic. It only understands certain, very specific messages, and because it discards anything that it doesn't understand, you're safe from attack on that port.

Unsolicited traffic, only on the specific port, only to the computer that's expecting it, where BitComet sits watching the port.

Now adding a second router into the mix, it gets messier. The same principles apply, but you have to go through Router B. Router B has to sit in place of your computer. It has to have a static IP address on Router A's subnet, just as your computer used to. Router A's firewall has to forward the chosen port to Router B, at that same IP address, just as it used to do for your computer.

Your computer's connection to router B will be unchanged from its former connection to router A. Your computer can even use the same IP address as before, because it is now connected to a sub-sub-network.
You can't have two files with the same name, in a single directory, but you can if one is in a subdirectory. Same principle.

Router A can only see Router B, but not B's subnet or any devices connected to Router B. As far as router A is concerned, all of this traffic is coming from Router B with no idea what, if anything, may actually be connected to B. This isolation flows both ways.

It's still the same principle. Get the unsolicited traffic through the first firewall on the right port, to and through the second firewall on the right port, to the computer that's expecting it and where BitComet is waiting for it. You use the same tools to test it.

↑
Old_BitComet_Forum Wed May 28, 08 10:51 PM
By cassie
From forum_name, BitComet Forum
*moved to Port Forwarding and Router Setup*

↑
Old_BitComet_Forum Thu May 29, 08 04:13 AM
By suwatj
From forum_name, BitComet Forum
kluelos, thank you very much for your prompt reply. Your post was a little crytic to me. Either my language deficiency or my ignorance made me read the post several times to fully understand what you tried to explain. Base on your answer, I will do some experiments and will post the result back later. I hope that you will stay helping until the issue is solved. Thanks again.

QUOTE (cassie @ May 29 2008, 05:51 AM) <{POST_SNAPBACK}>
*moved to Port Forwarding and Router Setup*


cassie, my apology for posting in the wrong place. By the way, I like your animated cat; it's pretty cute. It reminds me of one of my weaknesses; curiosity.

↑
Old_BitComet_Forum Thu May 29, 08 12:13 PM
By suwatj
From forum_name, BitComet Forum
QUOTE (kluelos @ May 29 2008, 03:41 AM) <{POST_SNAPBACK}>
Now adding a second router into the mix, it gets messier. The same principles apply, but you have to go through Router B. Router B has to sit in place of your computer. It has to have a static IP address on Router A's subnet, just as your computer used to. Router A's firewall has to forward the chosen port to Router B, at that same IP address, just as it used to do for your computer.

Your computer's connection to router B will be unchanged from its former connection to router A. Your computer can even use the same IP address as before, because it is now connected to a sub-sub-network.
You can't have two files with the same name, in a single directory, but you can if one is in a subdirectory. Same principle.

Router A can only see Router B, but not B's subnet or any devices connected to Router B. As far as router A is concerned, all of this traffic is coming from Router B with no idea what, if anything, may actually be connected to B. This isolation flows both ways.

It's still the same principle. Get the unsolicited traffic through the first firewall on the right port, to and through the second firewall on the right port, to the computer that's expecting it and where BitComet is waiting for it. You use the same tools to test it.


To avoid the above problem with too many routers and sub-sub-net, I took "Router B" out of the loop by connecting my computer directly to "Router A". Port-forward and firewall setting stayed the same as before. I used Bitcomet v1.01 and eMule 0.48 for testing the port. Here's my findings:

Case 1: Port 49999, uPNP enabled, Port-forward and other settings were checked twice. Bitcomet started. eMule not running. Results:
- Unsuccessful. Yellow light. "Local" initation and LT Seed. No "Remote".
- Canyouseeme.org reported "Connection refused"
- Wireshark reported that Bitcomet received transaction from the port but refused to connect by sending out "RST".

Case 2: Port 49999...settings same as Case 1. Bitcomet not running. eMule started using 49999 as listening port.
Results:
- Successful, High-ID connection to server.
- Canyouseeme.org reported successful connection.
- Wireshark reported normal transaction on port 49999.

Then I connected everything back to the original two-tier setup by including "Router B". I got the same results as the above test. eMule could use the listening port successfully while Bitcomet was still blocked or it refused to receive transactions from that port. So, I think the problem has nothing to do with firewall, port-forwarding or the two-router setup. It looks like Bitcomet didn't want to communicate to its peers and I really don't know why.

Kluelos, what's your opinion? Are there other ways to check deeper? Some software that can trace deeper?

Any suggestion is really appreciated. Thanks in advance.

↑
Old_BitComet_Forum Thu May 29, 08 01:38 PM
By bloominidiot
From forum_name, BitComet Forum
I got that damnable yellow light yesterday (28 May 2008) myself after upgrading to BC 1.01. Had been using ver. 96 and had green light all the time. Went thru a bunch of stuff trying to get my green light back but to no avail until I went into windoze firewall settings. I allowed my listening port in exceptions and got my green light. So now all is good again.

↑
Old_BitComet_Forum Thu May 29, 08 06:18 PM
By kluelos
From forum_name, BitComet Forum
BitComet starts and tries to send a message to an external server, asking it to send a probe to your listen port. It then waits for that message. If it can't contact that server, it shows a gray light. If it contacts the server but never sees the probe, it shows a yellow light. If it contacts the server and then sees the probe, it shows a green light. It's a simple-minded system and has lots of possibilities for error.

Because of those possiblities for error, you test at canyouseeme.org for confirmation.

A blocked port means you have a firewall blocking the port. This is a rule you can rely on. If your port is blocked, then you've got a firewall you haven't configured to open that port. If you don't think so, that just means you've got a firewall you haven't found yet, or think you've configured properly when you have not.

UPnP has had a very unhappy history with routers, and frequent unexplained failures. If it happens to work for you, great, but if it does not you probably will not be able to fix it, or to diagnose any problems. Should UPnP fail to work completely and easily, you should forget it, disable it, and configure manually instead. Betyer to know what you're doing and why, than to rely on the mysterious and undocumented inner workings of some mechanism with that track record -- especially if it used to work and now doesn't. You'll probably never be able to figure out why.

One change you should make though, is not to use the same port for BitComet and EMule. Whichever one gets the port first will block it for the other, so they'll never both work at the same time.

If you are using the Windows firewall and have enabled ICF in your BitComet preferences, then BitComet will configure that firewall correctly for you, automatically. If any of those are not true, then this must be done manually. You must not only permit BitComet traffic outbound through your firewall, you must also open the selected listen port. This is not "to" BitComet or any other application, because it's not a firewall's job or concern to route traffic. The port must just be open, period.

And to repeat, if the port's blocked, you have a firewall that's blocking it.

↑
Old_BitComet_Forum Thu May 29, 08 10:48 PM
By cassie
From forum_name, BitComet Forum
QUOTE (suwatj @ May 29 2008, 05:13 AM) <{POST_SNAPBACK}>
It reminds me of one of my weaknesses; curiosity.

Lol, I don't consider it a 'weakness' (I am guilty of the same thing, myself) - rather a 'thirst' for knowledge...

↑
Old_BitComet_Forum Fri May 30, 08 07:17 AM
By suwatj
From forum_name, BitComet Forum
QUOTE (kluelos @ May 30 2008, 01:18 AM) <{POST_SNAPBACK}>
One change you should make though, is not to use the same port for BitComet and EMule. Whichever one gets the port first will block it for the other, so they'll never both work at the same time.


You misunderstood me. I did not run both Bitcomet and eMule concurrently using the same port. In the experiment above, I ran Bitcomet alone using port 49999 and then exited it and ran eMule using the same port. In essence, I checked the port using eMule. I did this because I do not know have a better tool to check the listening port. In both cases, I used canyouseeme.org to verify the connections. If canyouseeme.org is to be believed like you said and if the port was blocked by the router or whatever firewall in the system, be it software or hardware, eMule should be blocked too. It turned out that Bitcomet was blocked or refused to respond to the port while eMule was not blocked. There are only two hypothesises, I could fanthom. The first one is that there is an external process that only block Bitcomet but not eMule. I know this is a bit absurd and leaning toward conspiracy theory. The second hypothesis is more plausible. There is something inside Bitcomet, either by design or some libraries (DLLs) and/or system services that Bitcomet hooked to, interfering with the listening port.
In one of my trial and error before my posting here, I turned almost everyting on the way from the modem to Bitcomet off. Firewall in the modem was off except Intrusion Detection (can't find way to disable it). Windows firewall was disable. All the programs that started with windows were disable or exited. I did not turn any system service off because the last time my ignorance made me turned off "remote procedural call service" and I was forced to do reformat and re-install. Same result. Bitcomet was blocked while eMule could get thru.

QUOTE
And to repeat, if the port's blocked, you have a firewall that's blocking it.


I ran out of idea on how to investigate this phenominon. So please help if you can. Any suggestion is welcomed. Or at least pls point to a tool that can help me investigate further. My curiosity is killing me.

QUOTE
UPnP has had a very unhappy history with routers, and frequent unexplained failures. If it happens to work for you, great, but if it does not you probably will not be able to fix it, or to diagnose any problems. Should UPnP fail to work completely and easily, you should forget it, disable it, and configure manually instead. Betyer to know what you're doing and why, than to rely on the mysterious and undocumented inner workings of some mechanism with that track record -- especially if it used to work and now doesn't. You'll probably never be able to figure out why.


Thanks for the warning. I always set everything you mentioned by hand and use uPNP and ICF/ICS as a mere backup. Currently I am into Wireshark. It looks like Wireshark inserts itself in front of windows firewall because I turned firewall off and still could see transactions to the port originated from remote IP without reponse from my computer; not even "RST".

Regards, suwatj.

↑
suwatj Mon Jun 2, 08 11:53 AM

Problem solve. I've got green light now. Turned out, I installed a software called "Netpeeker" a week before the yellow light issue to try it out. Once installed, Netpeeker inserted a system level driver, Netpeeker.sys, under \windows\system32\driver\ folder. The driver interferes with Bitcomet's listening port eventhough the main program has never been run. To the question why it blocks only Bitcomet and not eMule, I don't have a proper tool to dig deeper. So, I am happy now with download speed max at almost 1.8 mbps on a 2 mbps line. Thanks for all your suggestion and time. SJ.


↑
[Guest]Guest Thu Nov 5, 09 10:45 AM

UGG Classic Tall is one of our brand's heritage styles. The UGG Classic Tall features genuine twin-face sheepskin for refreshing comfort.UGG Classic Tall Sheepskin boots are the taller version of UGG Australia's signature luxury sheepskin boot.UGG Classic Tall is a classic article for autumn and winter seasons. It has become a new favorite for fashionable ladies.

http://www.widelybuy.com/ugg-classic-tall-c-3.html



TOP