new router, bitcomet cant listen to ports

[kluelos]

In a TCP or UDP packet, the first four bytes of the packet are the destination address. The next two bytes are the port number.

It's just a routing number, nothing more, and it has no physical existence, nor any use outside of your computer.

When an application starts up, it says to Winsock, "Send me all the traffic that comes in and has routing number 12 on it from now on". Winsock says "OK, will do", or "no, sorry, I can't, somebody else already reserved the #12 traffic." (This latter is what BitComet says is happening to you.)

There is no hardware, no structure to that routing number. "More traffic on that port" simply means more messages with that routing number in their bytes 5&6 than messages with another number there. It is NOT a channel, like a TV channel or a radio channel, and it does not carry traffic like one. The traffic is carried by the internet, period, and it is all routed from IP address to IP address. Only after the traffic is received does anything worry about the routing number.

When an ISP "blocks a port" it examines the destination port, bytes 5 & 6, of all incoming traffic, and if set to the forbidden number, discards it. The remainder it forwards on to the destination.

When you pick a listen port for BitComet, then when BitComet connects to a tracker it sends the tracker your current IP address and your current listen port. That information gets added to the list the tracker keeps, of peers interested in this particular torrent it's tracking. That's what a tracker does and why it's called a tracker. It keeps track of the interested peers, who's at which IP address and which port their client is listening to for new traffic.

Other peers ask the tracker for that list, so the tracker sends the list out to them, with your IP address and port number on it. Then some of them may try to contact you, using that port number. Their traffic comes in to your computer, your Winsock sees the routing number, and sends that traffic to BitComet.

If you change your port number, BitComet sends that different port number out when it contacts a tracker. The tracker receives your IP and (new) port number as before, puts that info on its list, distributes the list, now peers are trying to contact you on your new port number.

That is why it doesn't matter which port number you choose, and the number you do choose is only relevant to you -- not to anybody else in the swarm.

Your BitComet participates in the swarm, connecting to Jase, who lives in Spain, and has his listen port set to 65535, so that's the port number your client inserts into bytes 5&6 of the packets it sends when asking Jase if he has the piece you're looking for. Padma, in Bombay has her client set to use port 80 -- the usual web server port -- because she isn't running a web server, but her ISP blocks most other ports. So when your client wants to initiate communication with Padma, it inserts port 80 as the destination port in its packets to her.

Joel, in Brooklyn, uses 6880 as his listen port because another kid in his high school told him that was the "right" port to use for bittorrent. Neither of them knows any better. Your BitComet doesn't care, it uses routing number 6880 to initialize communication with Joel.

In the meantime, your own listen port is set to 65432. Max, in Westphalia, tries to initiate contact with your client, using routing number 65432. He's also trying to talk to Jase, Padma and Joel using their respective listen ports.

If Joel wises up and changes his listen port to something else, his client tells the tracker, which changes its list. You eventually re-scrape the tracker, get the updated list with Joel's new port number on it, and thereafter you, Max, and everybody else will use that new port number for initiating contact with Joel.

There is no point at all to trying to find a "better" or "the right" listening port. That doesn't, can't exist. All this fuss about searching for it, like it was a buried treasure, is useless.

You should now clearly understand why an ISP attempting to block a port in order to control bittorrent traffic, is just sleepwalking.

(This is all when traffic is initialized -- first begun, no matter who begins it. Once traffic is established, it moves to other port numbers, but now all that traffic is in reply to previous traffic. It's treated differently than the first contact.)

[MrYumYum]

greywizard-

just changing the port number and hitting ok results with this error, this usually showed yellow light, (now it shows a green light and while hovering my mouse over it, it indicates a yellow/grey light, is this due to upgrading my version from 1.25 to 1.26?)

--pre-error: transfers are conducting through this port

--post-error: no transfers are conducting through this port

closing and reopening bitcomet (post-error) shows a green light (checked with the command you gave me, transfers are done through this port)

--post-error+restarting bitcomet: transfers are conducting through this port

regarding the steps you posted,

netstat -aon|find /i "oldportnumber" and netstat -aon|find /i "newportnumber"

both show the same PID which is bitcomet's PID

i've saved the results if you'd like me to post them

kluelos-

thanks for all the useful information, things are much clearer now

just to make sure: netstat -aon|find /i "xxxx" shows all the traffic done through port number xxxx correct?

is there a way to differentiate between traffic that was done through an open/blocked so that we can tell if this is a bug or not?

Edited February 8, 2011 by MrYumYum (see edit history)

[greywizard]

Yes, we need you to post the results of the commands (both netstat and tasklist).

--pre-error: transfers are conducting through this port

--post-error: no transfers are conducting through this port

You're not being very clear about this one. Which port is "this port"; the port you used pre-error or post error?

That's why we need to see the results for the commands run on both ports, pre-error and post-error, so that we can asses the status of each one of them in both moments.

But since you mentioned it, what I would like you to do is to also run the commands after restarting BitComet, and save the results as well. That way we'll be able to make a better comparison between the two cases.

Then upload all the results here.

Also, post a screenshot of the tooltip-message you get when hovering the mouse pointer over the status light (stating it is grey or yellow) while it displays a green status light; this may be a bug in the user interface of v.1.26, but we need to confirm it.

You'll just need have a little patience about solving the yellow light issue, as I told you in the previous post. Mixing questions and answers from two different issues only leads to confusion on both sides.

As soon as we'll be finished on the issue provoking the error message, perhaps we'll be able to draw a more informed conclusion and hopefully it'll be much easier to help you solve the blocked port issue (which BTW is an entirely different one from the problem we're discussing now).

Just to quickly answer your last question, the "listening" status of the port displayed by the netstat command doesn't mean that you have an open port, per se. It just says that it's registered in Windows' Winsock by an application which is listening (a.k.a. waiting to receive traffic, as far as the application is concerned).

It's like you were sitting in your house and announced everybody that you're waiting for guests.

However if your door is locked (Windows firewall) or the door of your building is locked (a third party firewall) or perhaps even the gate of your fence is locked (the firewall in your router and/or the un-configured NAT of your router) nobody will ever be able to get to you.

[MrYumYum]

sorry it took so long, been very busy

thanks for your answer, im pretty certain now that my ports are open

as for this bug

to make it simpler ive made it in 3 steps

1. chose a random listening port, checked to see whether its conducting any transfers (=port checked pre-error, call it port A)

2. changed the listening port while bitcomet was running which indicated the error, then checked to see whether the new port is conducting any transfers (=port checked post-error, call it port B)

3. changed the listening port again (for the second time), closed and reopened bitcomet to check whether this new port (port C) was conducting any transfers

port list of the first test:

A-50025

B-50029

C-50041

heres what i tried today:

1. same as above

2. same as above (had to do it twice as cmd wont post any output for the "netstat" command the first time i tried it-check the .txt file)

3. restarted bitcomet to check whether transfers were conducting through port B (and they were)

is this because of the trackers still using my old port number?

port list of the second test:

A-50041

B-50033(first time - no output from cmd), 50037 (second time - output from cmd is shown in the .txt file)

ive attached the results of both tests, ive also attached a screen shot with the tooltip message mentioned above

First test.txt

Second Test.txt

Edited February 11, 2011 by MrYumYum (see edit history)

[The UnUsual Suspect]

Keeps saying that can not listen to port plz HELP iv tryed everything email me at djpricei@hotmail.com THANKS

No one can help you if you aren't willing to read the rules and provide the required info.

Also, this topic belongs to another member so I'm going to close it to prevent it from becoming cluttered with unrelated posts. If the original author wants the topic reopened, you can message any staff member and we'll be glad to open it.

*topic closed*

[kluelos]

1. Do NOT jump into the middle of someone else's discussion like this. It's extremely rude, like walking up to a group of people discussing something, and immediately changing the subject to something else.

2. Read the sticky post titled "READ BEFORE POSTING" before you post, and when you post your new topic, include the information that it tells you to include..