#3 closed enhancement (fixed)

File transfer support

Reported by: anonymous Owned by:
Priority: wishlist Milestone:
Component: BitlBee Version:
Keywords: Cc:
IRC client+version: Client-independent Operating System: Public server
OS version/distro:


When will BitlBee convert incoming filetransfers to DCC and vice versa?

Attachments (0)

Change History (29)

comment:1 Changed at 2005-11-08T01:28:48Z by admin

Priority: majorwishlist

comment:2 Changed at 2005-11-08T11:08:00Z by wilmer

Component: ircbitlbee

comment:3 Changed at 2005-11-17T23:42:49Z by wilmer

Milestone: 2.0?

comment:4 Changed at 2006-06-08T14:32:15Z by IcE^

I think this is a really neet feature that would be usefull.

comment:6 Changed at 2007-11-19T23:41:05Z by toxik

And now also - same but I merge in latest bitlbee from time to time.

comment:7 in reply to:  description ; Changed at 2007-11-28T23:20:59Z by ulim

Jabber file transfer(currently only receiving):

comment:8 in reply to:  7 Changed at 2008-02-20T21:08:56Z by anonymous

Replying to ulim:

Jabber file transfer(currently only receiving):

now also sending, even with proxies.

comment:9 Changed at 2008-06-08T17:30:26Z by anonymous

Will this be ever included in the main-code? I think it's a quite useful feature.

comment:10 Changed at 2008-06-12T15:05:44Z by anonymous

Can I use a Jabber transport for file transfers using the add-on?

comment:11 Changed at 2008-06-12T15:08:00Z by anonymous

Sorry, for posting again here. I forgot to say that I was talking of sending/receiving files from ICQ/AIM users using a Jabber transport.

comment:12 Changed at 2008-06-25T23:51:38Z by ws

up !

I know this feature should be included in v2.0.

Is it possible to merge this to the main branch ? I can't test those versions of bitlbee. But i'm waiting since so many time...

Some friends are using amsn & psi because bitlbee do not provide file transferts. Thank you in advance.

comment:13 Changed at 2008-08-13T16:37:47Z by anonymous

Yep. It would be great if it gets included in v2.0. If the main developers do not like this feature, they can create a ./configure-option that disables it when it is not wished.

comment:14 Changed at 2009-02-03T10:09:24Z by Lee Williams <…>

Subscribing. People now keep sending me big files via e-mail.

I'd personally be satified with receiving as a first step, maybe not even bouncing via dcc, just saving the file somewhere on my server.

comment:15 Changed at 2009-05-03T13:58:46Z by anonymous

i would like to bump this first i wasn't using bitlbee because of otr, know it's the file-transfer. oscar transfer to dcc would be awesome

comment:16 Changed at 2010-03-21T16:13:21Z by wilmer


My work in merging this in is finally working out! My apologies to ulim and others for waiting for two years before doing this.

The next step is to merge in libpurple into this branch and add the glue required to make file transfers go there. I hope to add ft support to a few other native IM protocol modules too, in the meantime libpurple will do.

comment:17 Changed at 2010-04-14T12:25:55Z by dante@…


People are receiving messages saying that my msn version is too old to accept files transfer. Your made changes in the msn protocol, is it supposed to be fully implemented ? Or is it what you are saying concerning libpurple ? I tried to activate debug mode on bitlbee but i dont have messages related to this failure.

comment:18 Changed at 2010-04-14T12:29:59Z by wilmer

Yeah, it's related to libpurple. The MSN ft code in this branch is so old I actually disabled it in one of my branches already. You can try the current libpurple branch. It should work better although sending via MSN was still buggy for me.

comment:19 Changed at 2010-04-14T13:00:43Z by anonymous

Ok thanks. Have you some documentation about it. Transfers are stalled in my case. Do I need to open ports for bitlbee to allows transfers ? It is on a server with direct access to internet but I have iptables closing most of the ports.

comment:20 Changed at 2010-04-14T13:08:36Z by wilmer

Oh yes, right now you have to put some IP info in bitlbee.conf. One of the things I want to polish before merging and releasing it.

You can try setting adding sometihng like

ft_listen = internal_ip;external_ip


ft_listen = internal_ip:port;external_ip:port

Assuming you connect to BitlBee from an internal IP address. If it's a colocated box then just external_ip should be okay. To deal with port restrictions you probably have to use the second format. It doesn't support ranges yet.

comment:21 Changed at 2010-04-14T13:38:07Z by anonymous

Ok thanks. Actually, it doesnt seem to work. I tried several way to write it but the transfers stall in the best case, make bitlbee restart in worth ones.

would it be something like

ft_listen = external_ip:port
ft_listen = ; external_ip:port


does it mean I have to setup a dcc port on my irc client or something ? I am talking about receiving file (I didnt try sending them yet)

comment:22 Changed at 2010-04-14T19:33:58Z by wilmer

Eww, restart's not good. :-(

For receving file transfers, settings on the IRC client should not be important.

And it's the sytnax without the semicolon, yes. Did it crash with it? That may be a bug in the parser then. I'm looking at rewriting that stuff a little bit anyway..

comment:23 Changed at 2010-04-14T22:39:53Z by anonymous

Yes it does crash with it. Do you want me to open another ticket ? I finally found a way to have some logs so I can send them with all the information (ubuntu 32bit, gnutls, compiled from last purple branch, configured as said, crash when someone send a file or idle sometimes when I do /dcc get, client is irssi from ubuntu repository).

comment:24 Changed at 2010-04-15T14:27:44Z by anonymous

Here is the log of the segfault: First the file is idling after a /dcc get and when it timeout, bitlbee segfault. and I put ft_listen ip:port in my config file.

comment:25 Changed at 2010-05-18T00:11:26Z by wilmer

So I gave up on making the file transfer frankenstein work. This API is fairly recent, it didn't even compile against libpurple <2.6.0 and mostly just didn't work with newer versions (depending on the protocol module).

That code was really designed for just local file transfers, so what it does now is store the file locally and send stuff to the user as it gets written to the file. It's utterly dumb but better that than something that hardly/rarely works.

If you feel like testing, please do. I trust this code more than the old stuff. Sending will come soon (it'll suck more because I'm not sure if the ft can be started before the whole file is sent by the IRC client).

comment:26 Changed at 2010-05-21T00:12:00Z by wilmer

This should be fairly stable as of changeset:wilmer-libpurple,535

comment:27 Changed at 2010-06-15T11:39:21Z by wilmer

Milestone: 2.01.4

comment:28 Changed at 2010-07-24T21:29:08Z by wilmer

Resolution: fixed
Status: newclosed

I just merged ui-fix into mainline.

This closes one of the oldest BitlBee feature requests (and the oldest bug in this BTS) ever. :-D

comment:29 Changed at 2016-07-07T20:51:01Z by dx

Milestone: 1.4

Modify Ticket

as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.