1.14 Change listen port muddled behaviour

[snmememe]

BitComet 1.14 ADSL2 Billion 7404VNPX UPnP WinXP AVGFree 8.5

I have the boxes ticked for Enable UPnP port mapping and Remove port on NAT/Firewall when exiting.

After altering the Listen Port number, the bottom of window status information indicates an attempt to map the new port number, however after repeated attempts, failure remains the indicated result.

A more sinister and less visable nuisance, is that the original port number remains mapped as shown by the router status information.

Even after exiting the process normally, by using the toolbar button, the original port number has still not been taken down and remains mapped in the router, allowing the potential to propagate huge volumes of unwanted traffic and a router reset is needed to remove the open port.

[kluelos]

Using UPnP is strongly discommended. It requires that all routers function in a certain way, but no software can enforce that. UPnP in practice has been a frequent disappointment and a support nightmare. When something goes wrong, as it frequently does, errors are incomprehensible, diagnostics are unavailable and repairs are impossible.

All that BitComet or any other software can do is send the router a command message. If the router does not comply, BitComet or any other software cannot do anything about it. When BitComet sends the router a "close the port" message via UPnP, then the router must comply. If it does not, BitComet can't force it to.

Configuring your router manually is the best way to assure that it is configured the way you want it. If your router will not close the port on command whether via the control IF or UPnP, short of a reset, then you need a new router that does not behave so.

A forwarded router port does not "propagate huge volumes of unwanted traffic". When you leave the swarm, traffic continues until news of your departure has spread to all of the members. This can take upwards of an hour. Meanwhile some of those peers will continue to try to contact you. This can't be changed, and having a port open or closed doesn't affect it.

[snmememe]

Perhaps my descriptions hasn't been understood well.

I am using a recently purchased Billion router which was a relatively expensive new 2009 SOHO model and firmware updates have been applied.

Is it suggested that I ask Billion to provide a button to close ports listed in their UPnP Portmap status page? I wonder if they would agree that such would be a useful addition.

As an aside, that Billion does have a provision to forward a port for a particular span of time, but perhaps I haven't persevered sufficently to witness success with that idea yet, perhaps due to conflicting UPnP activity when I tried it.

In other forums it's been suggested to use UPnP rather than static port forward.

That way the port should be dynamically mapped only when required, and the mapping torn down when not required, and unwanted traffic not propagated.

Setting that aside; in the spirit of reporting observable program behaviour...

The close port request can and does succeed.

I believe that BitComet does achieve reliable unmapping of the UPnP ports that it has established in this Billion, when it is closed normally.

However, if the Listen port value is changed during the session, the ports always did not get unmapped.

Also, if the process isn't closed normally using the toolbar exit button, the ports have always remain mapped in the router.

Very occasionaly BitComet at startup tells me that it has failed to map and open a port.

I expect to have more to offer, in a separate thread, regarding dubious high volume traffic related to BitComet after further testing, when hopefully I can be more specific about causual circumstances.

[kluelos]

You seem to believe that if a router's port is forwarded, then it will "propagate unwanted traffic". This does not occur. When BitComet starts, it exclusively registers its listen port with your winsock. (If it can't do so, then it quits and dies.) While it is running, nothing else can register for that port - it will be refused by the winsock. After BitComet terminates, your winsock has nobody registered for that open port, so it discards any traffic received for that port. There is no effective difference to the net or your system, between blocking the traffic with a firewall on the one hand, and throwing it out because it's bound to a port nothing is registered for, on the other. Nor does this latter situation somehow create additional traffic. Do you have some evidence or reasoning to suggest that it does, or why it would be important in the first place?

If this is of great concern to you and you still think something happens anyway, then I suggest that you also use the Windows built-in firewall and activate ICF in the BitComet options/preferences/whatever. This will open and close the listen port on the windows firewall, whether the router is responding properly to UPnP commands or not. That will not stop traffic aimed at that port, nothing will. That's beyond your control. But inbound traffic for it will be blocked by the Windows firewall. Using two firewalls will double your management burden, but it will do what you want.

The situation with UPnP is that it appears to be unreliable, and the errors, if any, that it throws are inconsistent. If you use it at all, then you subject yourself to this behaviour. BitComet does not include functionality to stop on UPnP errors or failures. UPnP performance has never been consistent enough or reliable enough to make that tolerable. Yet that is all that BitComet could do in response to either failure or incomprehensible response. Consider:

If you left your machine running all night, thinking that a download would be finished in the morning but instead find a dialogue that BitComet has stopped all transfers seven hours ago because the router said something it didn't understand, in response to a command, so should BitComet continue or stop? and has been sitting there waiting for a response from you all night. You'd be annoyed.

BitComet cannot babysit everybody else's router. If there were some consistent and enforceable way to apply UPnP -- some sort of certifying authority for its behaviour, that all routers had to conform to, perhaps UPnP would be more reliable. But as it is, it's left up to each of the many router manufacturers how they're going to implement UPnP and how consistent with each other they're going to be about it.

You use UPnP at your own peril. If it works for you on your hardware, great. If it doesn't, BitComet's not responsible for that and can't fix it or control it. So if you wish to affirmatively control the situation, then you should do it manually.

If there were an unambiguous UPnP standard (there isn't) and a governing body (there isn't) which propounded certification (no such thing) tests (no such thing) that a router had to pass in order to be certified (no such thing) as UPnP-compatible (ditto), and that board somehow had the power to say, "Billion, you router model XXyy, firmware revision 12.345 does not meet standards. You cannot sell that router as UPnP-certified." and somehow enforce this, then perhaps the standard would mean something. Among many other things, you, the customer, would have to understand and care about UPnP certification, ask about and choose not to buy a router because it lacks that certification. This is unlikely to happen.

Without that economic incentive, consistency is unlikely to happen.