Opened 8 years ago

Last modified 8 years ago

#5658 new Bug

Global bandwith capped very low

Reported by: yereto Owned by:
Priority: Normal Milestone: None Set
Component: Daemon Version: 2.82
Severity: Normal Keywords:


Torrents are capped as if the global bandwidth was set very low (~100kB/s). It's not one of the usual network suspects, I've got several torrents from multiple trackers running on a hard-wired 100/80 connection, and with identical network configuration settings I would get much better speeds. I disabled uTP, which seemed to fix the problem for the length of that session, but after a daemon restart the capping came back, and persisted after I reverted the changes I made while the daemon was down.

Afterwards, I let transmission generate a new settings.json file and edited it only to disable uTP, and the problem persisted. Right now I'm playing around with settings in an attempt to re-create what I did earlier to fix the issue.

Change History (3)

comment:1 Changed 8 years ago by yereto

I got sidetracked trying to figure out a fix, which I was hoping would lend to reproducibility, so instead I'll try to post some extra info. This is running on x86 gentoo, pulled straight from the package manager, reported version in emerge is 2.82r3. I'm using DHCP to configure the network, but again, I'm fairly certain it's not an issue with the network/system (aside from maybe some issue with the package) since I did see normal speeds for a little bit. I've tried altering issues through the web UI, transmission-remote, and by editing the settings file (making sure to stop the daemon when I do so).

comment:2 Changed 8 years ago by Gsmiley

I've noticed this behavior (global cap dips to about 100 kbps) on the OSX client (v 2.82 (14160)) as well.

It seems to only occur when an unknown peer type, with a client name like -IL500%FF- connects. All sharing prior to this connection seems normal. I've isolated this in situations with very few peers, and it has been reliably reproducible. There are several variations on the suspect client name, but all with hex-like character strings and percent signs in them.

While I can only speculate as to the form of attack this client may be performing, I suspect this is the cause of the issue. I hope that helps in some way.

comment:3 Changed 8 years ago by yereto

I've done more troubleshooting, and no solid way to reproduce yet, but I've crossed more things off the list. I tried building from trunk, but since I'm on private trackers I wasn't able to open connections to test, but when I built from source, there was no immediate effect, but after a while the torrents sped up to reasonable speeds. I can't think of anything significant I did right before then, so unfortunately that was no help. When I went to bed several hours later, the total download rate was pretty low, but it was still a bit higher than what I normally saw, and pretty constant, so I believe that as just normal operation with few peers. This morning, the behavior was back, so I think it's safe to rule out any specific option, as well as gentoo's package. I checked all my peers, and there's nothing there as far as unknown peer types, but I'll keep a look out in the future.

Digging through logs, I noticed that automated port forwarding failed (not that I'm surprised, I'm on a school network) so I've included a paste, in the event that it's important. (Also with regards to the school network, I'm trying to talk to someone to figure out if it's some network weirdness on their end, but until then, I'm going to assume it's not, since other clients work fine, and I have seen normal speeds on transmission).

Edit: Forgot the paste,

Last edited 8 years ago by yereto (previous) (diff)
Note: See TracTickets for help on using tickets.