BItcomet upsetting Speedtouch 546 modem and connection

[EricJH]

I am a first time user here but not new to peer to peer clients and managing their settings to keep them from hogging the connection.

One of my new housemates brought in Bitcomet and by cross referencing modem logs and her laptop's Windows logs I could find out that Bitcomet is the source of intermittent blocks of the internet connection. The modem is upset so much I cannot access the web interface of the modem either The modem is a Speedtouch 546 with software version 6.1.0.5 which is capable of managing 2046 simultaneous connections. The connection is an ADSL 2+ wide open connection with 15,3Mb/s up and 1Mb/s down.

The blocks appear to be happening when the client starts and sometimes when starting a download by torrent. This has never happened before with other p2p clients.

I downloaded and installed Bitcomet v1.27 on my own system and it reproduces the blocks of the connection similar to my housemate's computer. I have set Bitcomet's global upload limit to 10 kB/s and also the minimum and maximum upload rate per task to 10 kB/s. That does not make the problem go away.

I went looking for a global limit of maximum simultaneous connections, which I always set to a conservative number of 50, but cannot seem to find such parameter.

I would like to know what is going on and what parameters can be changed to tame Bitcomet to prevent it from intermittent overloading the modem?

Edit: the traffic happening gets seen by the modem as possible intrusions. There are usually 4 IDS warnings. Let me know if you want to see the logs.

Edited May 15, 2011 by EricJH (see edit history)

[greywizard]

Well, at times BitComet can exceed the 2000 "connections" limit due to UDP traffic. When this happens, obviously other applications on any computer into the LAN won't be able to "reach out" into the Internet because the NAT table of the router is full so they have to wait for it to time out some entries and then again hope BitComet doesn't fill them up before they can grab them.

The limit for TCP connections is to be found into Options-->Advanced under the name of network.max_connections. But my guess, as I said, is that it isn't TCP who is filling up the NAT table but UDP (however you can limit the said TCP parameter to a couple of hundred connections for testing sake).

If the PC running BC uses XP you might want to also raise its number of max half-open TCP connections above the default 10 (let's say to 15 or 20) and then set the BC parameter network.max_connecting_connections to something lower (say 10 since this is the lower limit). This should offer room for other apps to create embryonic TCP connections along with BitComet (at times when BC is in a frenzy of opening new connections, such as that of starting a new torrent). Later OS-es don't have this limitation therefore this paragraph doesn't apply to them.

Now, coming back to UDP, we've been nagging the developing team a while back to introduce some option to limit the number of different UDP sockets which the program uses per minute, in order to alleviate this very issue you mention, which appears with certain router models. Obviously that would take some work so for the time being they went with introducing an option which can limit the raw number of UDP packets which the program can send per second.

It's not exactly the most elegant solution but at least it offers you an instrument to contain the "damage" and as far as I know is the only BT client so far to have introduced at least some form of containing this. The downside could be that it may cripple more or less the traffic running on UDP but on the bright side it could offer you some relief.

The option is to be found in the same place under the name network.max_udp_pkt_per_sec.

What you should do is set the option to a conservative value (such as 5 or 10) and leave it running for a couple of days. If the issue doesn't surface anymore then you can try increasing it by 5 (and again leave it running for a while) until you find a value which does affect your router and then try staying under that threshold by a good distance (5 or 10) so that other apps are left with enough free entries in the NAT table.

This should help you address the problem.

However if you still see this issue occurring then set the bittorrent.connection.ltseed_protocol_selection to the value 0 (which will force LT-Seeding to use only TCP as transport protocol) and then disable DHT altogether, for the sake of testing and see what results you get.

[kluelos]

This is not a modem, though it is often called that by providers. It is actually a router, though it only supports one physical connection.

I used to have one of these, provided by AT&T. I soon discovered that AT&T knew little about their own product, and that much of what their agents were told about it, wasn't so. I solved the problems I was having with it by ignoring what AT&T told me, and going with what made sense. This worked.

A modem has no business involving itself in connections. It's there to encode and decode data period, while remaining oblivious to the content of that data. Now if the Speedtouch is getting overwhelmed by BitComet's connections (which never happened to me), then the obvious answer is to set the Speedtouch into "Bridge" mode, that is, to disable its internal router so that it only acts as a modem and passes the information through.

BitComet does nothing that other P2P clients don't do, in this regard. However, it appears that BitComet is a little more efficient, dropping unproductive connections more quickly than other clients. Some hardware can't keep up.

[EricJH]

Thank you both for your very informative and to the point replies.

At Kluelos. The Speedtouch 546 I am using is a ADSL modem and router in one box. I should have said that in my topic start. Bridging is not a solution as I would need to buy a router. I dont think I can sell that idea to my housemates.

After following the clues from Greywizard I found two familiar parameters to play with network.max_connections and network.max_connecting_connections. I will play around with them. I had overlooked them; I was expecting those parameters in the GUI part and not in the "command line looking" part. They are both set to 0 does that mean they are set to automatic? That is not totally clear to me from the description in the UI. Out of curiosity: what does it mean when it is set to auto? Are there typical numbers of connections that BC will use?

I will also check out the network.max_udp_pkt_per_sec setting as a means of throttling UDP traffic and preventing the hiccups.

The computers I was talking about have both Win 7; mine is x86 Ultimate and the house mate's is Win 7 Home x64. I am aware of the limitations of the TCP/IP stack of IP and the way how to patch it.

In case you are interested. This is what a typical hiccup looks like in the logs of the Speedtouch 546;

May 11 17:59:12 FIREWALL icmp check (1 of 2): Protocol: ICMP Src ip: 142.163.169.37 Dst ip: 86.94.2.105 Type: Destination Unreachable Code: Host Unreacheable

May 11 17:59:09 FIREWALL replay check (1 of 122): Protocol: ICMP Src ip: 109.87.57.180 Dst ip: 86.94.2.105 Type: Redirect Code: Redirect Datagram for the Host

May 11 17:57:47 IDS proto parser : udp null port (1 of 4) : 192.168.1.70 72.81.20.87 0126 UDP 7911->0

May 11 17:57:27 IDS scan parser : tcp syn scan: 77.46.2.58 scanned at least 20 ports at 86.94.2.105. (1 of 1) : 77.46.2.58 86.94.2.105 0052 TCP 59221->55688 [s.....] seq 3072061372 win 8192

Again thank you for providing me with this abundance of useful information. It saves me a hard struggle investigating.

If you you ever need guidance with the Comodo firewall at the Comodo forums please send me a pm, moderator with the same user name as used here, and I will happily return the favor you just did me.

[greywizard]

I hope you can make good use of the info.

Yes, 0 means that the option is set to auto.

Depending on the option that could mean different things; e.g. for the total number of connections it means "unlimited" (however BC automatically establishes a dynamic limit per running task anyway, so that will depend on the number of running tasks).

For the half-open connections as far as I remember (on my system is set since forever to a fixed value) it will be managed dynamically by BC.

Anyway, the general idea is that the 0 value will let BC manage the option as best as it knows and can given all the variables of which it is aware (e.g. global upload/download bandwidth, number of running tasks, number of unchoking/unchoked peers for each task, number of upload slots, etc.).

As for hiding all these options into the Advanced area, well, I think you'll agree that the average user who has no notion of networking whatsoever and just downloaded BC for the first time because s/he wants to download something, wouldn't know what to do with them (you have to at least know what a TCP connection is in order to being managing them manually).

Many users probably would misinterpret their meaning and by setting wrong values for them would make their clients go haywire, which in turn would be a lot of fun for us on the forum, with a storm of complaints. :)

I mean, for some people it's already a tremendous ordeal to open a port for BC, by setting up a NAT forwarding rule for incoming connections, on the router. Therefore the authors tried to make it as user-friendly as possible.

I've been happily using Comodo for a good 4 years or so, and never been disappointed by it; it's my all time favorite firewall. So, I'm glad to see someone from their forum staff here. :)

Actually, it was in Comodo's interface that I've been watching, a while back, all the connections that BC opens. Since on my BC client TCP connections were limited to a max of 500, when I saw it exceeding 1600+ I knew the rest were UDP "connections".

In fact I was thinking lately of going on the Comodo forums and asking the devs if they would consider introducing a feature in the firewall, which would allow a user to limit the number of connections per time unit (say per minute); both TCP connections and UDP sockets, on a global level (i.e. created/received by all the running applications, just as they are counted on the Summary page of Comodo).

While browsing on different forums, a while ago, I've seen quite a lot of network admins complaining and asking for ways to contain UDP traffic generated by different BitTorrent clients, but no easy solution from anyone (the issue was the same overload of the NAT table, not the actual bandwidth occupation).

I'm not sure if the developers of Comodo would be interested to implement this, but in my opinion this would make for a very cool feature, giving users with routers like yours a powerful instrument to manage their network traffic flow.

P.S. Something I've forgot to mention is that if you're downloading public torrents and you've installed the eMule plugin, you'll have to watch for it separately since I think the number of connections managed by BitComet's options do not apply to the ones opened/received by eMule (I haven't checked this yet).

[EricJH]

I hope you can make good use of the info.

I did some testing with BC on my own computer and first set network.max_connecting_connections and network.max_connections to conservative settings. That did not fix the overload like you expected. I found like you expected that the network.max_udp_pkt_per_sec setting was the one that matters when it comes to getting rid off the overload phenomenon. The modem still logs intrusions but does no longer get hung up.

I can now deploy these finding on my housemate's computer. I now know where to regulate.

Yes, 0 means that the option is set to auto.

Depending on the option that could mean different things; e.g. for the total number of connections it means "unlimited" (however BC automatically establishes a dynamic limit per running task anyway, so that will depend on the number of running tasks).

For the half-open connections as far as I remember (on my system is set since forever to a fixed value) it will be managed dynamically by BC.

Anyway, the general idea is that the 0 value will let BC manage the option as best as it knows and can given all the variables of which it is aware (e.g. global upload/download bandwidth, number of running tasks, number of unchoking/unchoked peers for each task, number of upload slots, etc.).

Thank you that was very informative.

As for hiding all these options into the Advanced area, well, I think you'll agree that the average user who has no notion of networking whatsoever and just downloaded BC for the first time because s/he wants to download something, wouldn't know what to do with them (you have to at least know what a TCP connection is in order to being managing them manually).

Many users probably would misinterpret their meaning and by setting wrong values for them would make their clients go haywire, which in turn would be a lot of fun for us on the forum, with a storm of complaints. :)

I can see why the decision was made that way. I am just used to e Mule, Azureus and uTorrent and there these settings are more visible. It only show we are creates of habit. And to but take a variation of the quote in your signature; I am afraid habits are not transient of nature.... ;)

I mean, for some people it's already a tremendous ordeal to open a port for BC, by setting up a NAT forwarding rule for incoming connections, on the router. Therefore the authors tried to make it as user-friendly as possible.

NAT and port forwarding surely are a big hurdle for the novice p2p users and gamers. Let alone fine tuning a complex create like a torrent client. Luckily Universal Plug and Play makes things easier these days when it comes to opening ports on the router. That leaves opening ports at the firewall the next big step.

I've been happily using Comodo for a good 4 years or so, and never been disappointed by it; it's my all time favorite firewall. So, I'm glad to see someone from their forum staff here. :)

I am not a staff member of Comodo.I am just a moderator; a volunteer with no other affiliation to Comodo then liking the products. It is a cool firewall that does a d*** fine job keeping the bad guys out.But it has a bit of a learning curve like all HIPS based firewall creatures. Lucky for novice users default settings give few alerts these days.

Actually, it was in Comodo's interface that I've been watching, a while back, all the connections that BC opens. Since on my BC client TCP connections were limited to a max of 500, when I saw it exceeding 1600+ I knew the rest were UDP "connections".

:)

In fact I was thinking lately of going on the Comodo forums and asking the devs if they would consider introducing a feature in the firewall, which would allow a user to limit the number of connections per time unit (say per minute); both TCP connections and UDP sockets, on a global level (i.e. created/received by all the running applications, just as they are counted on the Summary page of Comodo).

While browsing on different forums, a while ago, I've seen quite a lot of network admins complaining and asking for ways to contain UDP traffic generated by different BitTorrent clients, but no easy solution from anyone (the issue was the same overload of the NAT table, not the actual bandwidth occupation).

NAT overload is the usual suspect for me when a connection blocks with a p2p client running. Back in the days starting with a Speedtouch 510 with only an NAT table with 256 entries I learned the hard way; e Mule is set by default to a higher number for max simultaneous connections.

I'm not sure if the developers of Comodo would be interested to implement this, but in my opinion this would make for a very cool feature, giving users with routers like yours a powerful instrument to manage their network traffic flow.

That would surely be an interesting feature for more demanding users. You can add your wish in the Wishlist - CIS board.

P.S. Something I've forgot to mention is that if you're downloading public torrents and you've installed the eMule plugin, you'll have to watch for it separately since I think the number of connections managed by BitComet's options do not apply to the ones opened/received by eMule (I haven't checked this yet).

Thanks for pointing me to this.

[greywizard]

I'm glad you could find a working solution for the issue.