Opened 12 years ago

Closed 12 years ago

#3538 closed Bug (invalid)

Transmission freaking out Ambit cable modems

Reported by: offworld Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.04
Severity: Normal Keywords:


Over the past few weeks my Ambit cable modem has started locking up multiple times a day and not recovering. It requires logging into the modem and resetting, or if the modem config webserver is not responding, manually power cycling it. I contacted my ISP (Time Warner Roadrunner) and they couldn't find anything wrong on their end so they suggested I check the cables and splitter and as the last resort swap modems. None of that solved the problem.

This past weekend I stayed at a friend's house in the same area and Transmission started freaking out their cable modem as well. They have the same service and cable modem as I do and they hadn't experienced this behavior before. That rules out hardware as a cause. So the cause is either the ISP enacting some new draconian policy (nobody on dslreports has mentioned such) or a change to Transmission over the last couple of weeks. I am using the Mac client, svn version r11189.

Change History (8)

comment:1 Changed 12 years ago by livings124

Sounds like you're overloading your router/network. Try limiting number of peers, number of active downloads, and lowering bandwidth limits.

comment:2 Changed 12 years ago by offworld

I had only one active torrent which had 7 peers. I already limit the upload bandwidth. The behavior also manifest when the router is taken out of the loop and the computer is wired directly into the cable modem. This just started within the past few weeks and has occurred on two different networks/internet connections.

comment:3 Changed 12 years ago by User294

As for me, this appears to be a modem defect, not a Transmission bug. Is your modem running as router and NAT? I.e. does it maintains connection to ISP on it's own and then shares it to several devices?

Most common cause for such lockups and weird behavior are simple. Firmware authors are often a bunch of stupid monkeys who're stupid enough to be unable to set up connection tracking table size and connection tracking times reasonably (to match available RAM in their device). And vendor is greedy enough to use too small RAM ICs in their device. Then if there is too many connections and device keeps tracking them for a while(short tracking timeout haves it's own downsides), problem can occur. Torrent does large number of connections for sure. If conntrack table size configured properly, you could be just unable to make some new connection sometimes, which is indication that there is too many connections exceeding device's abilities. But looks like your devices even worse and have improper configuration. In this case conntrack table consumes all device's RAM. leaving no RAM for other tasks and then many weird things could happen because system on modem runs in out of memory condition and can't gracefully recover since most of memory consumed by kernel itself in it's connection tracking table, so even OOM killer can't deal with it. Sure, device will behave in unpredictable manner in this case. Some of programs (like http daemon) could eventually fail, etc and you will see a numerous strange effects/deadlocks/whatever else. And even if you can see 7 alive peers, this gives a little idea on how many connection has been made.

You can try:
0) Use a better modem or router with a bigger RAM and smarter dev's. If your ISP uses PPP connections, you can try to turn modem into "stupid" bridge (which does not tracks TCP connections and does not shares internet access at all) and then set up PPP connection and perform connection sharing from more powerful device which is able to cope with such load. As a good test case you can try to perform PPP conneciion from PC and to see if problem persists.

1) Reduce number of peers allowed and connections allowed.

2) As a last resort, try to disable DHT as it issues quite many UDP packets to various IPs so if router with bad firmware and too small RAM attempts to track them all for a while, see above what could happen. The downside of this step is that you will have less peers found and if tracker goes down for any reason, you will have problem starting your download(s) at all.

P.S. I can remember there was ticket to make "connections per second allowed" parameter adjustable. Tweaking this parameter to make only a very few connections per second probably can help in such cases in more reliable and predictable way than limiting number of connections. But right now this value still hardcoded in sources and the only way to change it is to recompile client.

Last edited 12 years ago by User294 (previous) (diff)

comment:4 Changed 12 years ago by offworld

User294, if you read the details of my bug and response, you'll see that your response, however detailed, does not address the issue. As I said, the bug exhibited even when the router was taken out of the loop. There very well might be a bug in the modem firmware, but since it only recently exhibited itself on two different modems, I'm assuming it was a recent change in Transmission as the modem firmwares were not updated.

comment:5 Changed 12 years ago by charles

offworld: as you might imagine, I don't have the hardware or time to try to reproduce the issue you're seeing. Since your theory is that a recent change in Transmission caused this error, could you try walking backwards through the releases to see which change it was?

comment:6 Changed 12 years ago by charles

offworld: ping

comment:7 Changed 12 years ago by charles

offworld: ping

comment:8 Changed 12 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

I'm closing this bug report because it lacks information to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. Thanks again!

Note: See TracTickets for help on using tickets.