File transfer support

[anonymous]

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

[IcE^]

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

[wilmer]

See  http://code.bitlbee.org/contrib/mek-ft/

[toxik]

And now also  http://b.lericson.se/~toxik/bitlbee-mek-ft/ - same but I merge in latest bitlbee from time to time.

[ulim]

Jabber file transfer(currently only receiving):

 https://code.launchpad.net/~meis/bitlbee/ulim-ft

[anonymous]

Replying to ulim:

Jabber file transfer(currently only receiving):  https://code.launchpad.net/~meis/bitlbee/ulim-ft

now also sending, even with proxies.

[anonymous]

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

[anonymous]

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

[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.

[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.

[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.

[Lee Williams <bitlbee.org@…>]

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.

[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

[wilmer]

changeset:killerbee,525

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.

[dante@…]

Hi,

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.

[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.

[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.

[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

or

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.

[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
or 
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)

[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..

[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).

[anonymous]

Here is the log of the segfault:  http://dante.kollok.org/tmp/bitlbee_ft_segfault.log 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.

[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).

[wilmer]

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

[wilmer]

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