rTorrent and Transmission don't seem to work well

[claytonl]

Downloading any torrent regardless of seeders and leechers seems to give me the same result. Either it doesn't download at all and finds no peers or it will find one or two peers and will download up to say 10k.

Using the same machine on a different operating system or using a different machine (mac) on the same network I am able to download fine. I have tried tweaking settings in both rTorrent and Transmission but no to avail. Any ideas?

[shep]

I did not have any trouble with transmission but found I needed to have the default rtorrent configuration file in my home directory.

cp /usr/local/share/examples/rtorrent/rtorrent.rc ~/.rtorrent.rc

I did not have to uncomment anything in .rtorrent.rc.

Also in rtorrent the downloads do not start automatically. You need to select the torrent and ^S. See man rtorrent. Lastly, there is a warning about hash checking for the BSD's. I just have it disabled.

[claytonl]

Strange. Transmission was working fine yesterday but now its doing the same thing. The only thing that seems to have any effect is having firefox closed. Thats probably coincidence though. I have lots of peers but its downloading at 0k. Sometimes 5k for a second or two.

[claytonl]

Ok so it appears theres a problem with the wireless usb device I was using, Ralink RT2573 (rum). I've tried it on two seperate OpenBSD laptops with the same result with torrents. I'm now wired in through a 3Com 3C905C (xl) and it works perfectly. I went from 22 peers to having 60 (the default limit in Transmission) and speeds are much faster and not intermittent.

[jggimi]

Glad you got your problem circumvented.

Did you want it solved? You don't say if you are running OpenBSD 5.0 or -current, or perhaps something even older, nor do we know which Ralink chipset is in the device.


If you're running 5.0-release or -stable, there's been one change to if_rum.c in -current that has not been backported. It fixes a problem with 11g beacon frames. See http://www.openbsd.org/cgi-bin/cvswe...v/usb/if_rum.c

[claytonl]

I'm running 5.0-release. I thought that RT2573 was my chipset but I also see RT2528 listed below that in dmesg. Is that my chipset? I would definitely like to solve my problem.

[jggimi]

Unfortunately, @claytonl, you're the only person who has seen your dmesg.

[claytonl]

This is the specific section I'm talking about:

rum0 at uhub0 port 1 "Ralink Technology RT2573" rev 2.00/0.01 addr 2
rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528, address xx:xx:xx:xx:xx:xx

[jggimi]

There's more about your situation we don't know than we do, due to your strong reluctance to share information. You want to keep the details hidden, including going to the effort of redacting your Ethernet MAC address from what little info you elected to share.

RT2573 is the NIC, RT2528 is the radio. You could deduce this by reading the rum(4) man page:

     The RT2501USB chipset is the second generation of 802.11a/b/g adapters
     from Ralink.  It consists of two integrated chips, an RT2571W MAC/BBP and
     an RT2528 or RT5226 radio transceiver.

     The RT2601USB chipset consists of two integrated chips, an RT2671 MAC/BBP
     and an RT2527 or RT5225 radio transceiver.  This chipset uses the MIMO
     (multiple-input multiple-output) technology with multiple antennas to
     extend the operating range of the adapter and to achieve higher
     throughput.

And further down, your NIC requires firmware. That firmware hasn't changed since 2006:

FILES
     The following firmware file is loaded when an interface is brought up:

           /etc/firmware/rum-rt2573

Since 5.0-release, there have been no changes to sys/dev/microcode/rum, which manages the rt2573.

----

I've done all I can with what little I've been able to pry out of you. If you want further review of this problem, you're going to have to divulge more about the problem and your configuration than you've been willing to.

Some examples of information that may help:

• An actual dmesg. You can continue to redact MAC addresses, though there's little value in hiding those. The dmesg shows much more than your NIC, it shows the architecture of your machine, what kernel you are running (and by who, where, and when it was built) and your complete hardware configuration from your mainbus outward.
• The outputs from netstat -in and netstat -ss while the problem is ongoing. One will show errors, the other, statistics.
• The output of ifconfig -A. You should redact any publicly facing IP addresses, encryption keys, SSID names, or anything else personal or confidential.
• A copy of your hostname.rum0 file, again redacting confidential information such as keys.

There's no guarantee I or anyone else can assist with debugging this, but without anything else, we certainly can't.

[shep]

The thread drifted into wireless configuration but I have noticed there is some odd behavior with rtorrent in OpenBSD 5.0.
I try to be a good netizen and conserve server resources when downloading *iso files and just used rtorrent successfully for NetBSD 5.1.2, FreeBSD and Arch linux. Rtorrent on the same box does not work for either the OpenBSD, PC-BSD, or Debian torrent sites. My best guess is that the non-working sites use multiple trackers while NetBSD uses a solitary tracker. Possibly the OpenBSD site may not be working although it does have up to date current torrents (he is looking for a new host). The Debian site does work in other torrent clients (transmission).

My rtorrent.rc configuration file is not anything exotic, just min and max peers are un-commented.

I also tried disabling packet filtration, I have the default installation configuration, but still was unable to get peers from the OpenBSD,PC-BSD or Debian site.

                 Trackers: [Key: 2f92c8d7]
Peer list       0: http://bttracker.debian.org:6969/announce
                   Id:  Focus:  no Enabled: yes Open:  no S/L: 0/1
Info            1: dht://
                   Id:  Focus:  no Enabled: yes Open:  no S/L: 0/0

                                                                           
                      *** OpenBSD ***
                 Trackers: [Key: 12a601d8]
Peer list       0: http://OpenBSD.somedomain.net/announce.php
                   Id: 2 Focus:  no Enabled: yes Open:  no S/L: 0/0

Anyone have any insight into this?

[shep]

I upgraded to current and the problem went away. Permission for usb devices have also been fixed in current.