| Commit message (Collapse) | Author | Age | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This segfault happened when none of the available streamhosts can be
connected to - or if at least one of them fails to connect.
Before this commit, it can be reproduced reliably by setting the "proxy"
setting of the account to nonsense, for example, this is what i used:
proxy.example.org,1.2.3.4,7777;proxy.example.com,173.194.42.65,80
jabber_bs_recv_handshake_abort() calls jabber_bs_recv_handshake(), which
is supposed to restart the handshake with the next streamhost. And it
replaced bt->tf->watch_out, which held an event ID, with a newer event
ID. So the replaced event ID doesn't get removed, and it gets called
again when its socket is closed by the timeout - and by the time that
happens, the memory is free()'d already. Boom.
The patch is simple - created jabber_bs_remove_events() to cleanup those
events, and use it before any code that expects to restart the cycle.
So basically the same as doing b_event_remove(bt->tf->watch_out).
I hope there aren't more bugs like this in this code.
|
| |
|
|
|
|
|
|
|
| |
- get_ft_by_sid()
- generate_pseudoaddr() (also uses g_compute_checksum_for_string() to
make the code shorter)
- jabber_streamhost_new()
Behavior should be the same.
|
| |
|
|
|
|
|
| |
Used uncrustify, with the configuration file in ./doc/uncrustify.cfg
Commit author set to "Indent <please@skip.me>" so that it's easier to
skip while doing git blame.
|
| |
|
|
|
| |
- http_incoming_data calling itself
- jabber_bs_free_transfer calling jabber_si_free_transfer
|
| |
|
|
|
| |
servers.
|
| |
|
|
|
| |
socket for file transfers.
|
| | |
|
| |\ |
|
| | |\
| | |
| | |
| | |
| | |
| | | |
Debian packaging is now properly separated. This also picks up a load of
stuff from mainline it seems.
|
| | | | |
|
| |\| | |
|
| | |/
| |
| |
| |
| | |
and my rewrite of the bs_peek function.
|
| |/
|
|
|
|
|
| |
Some hooks are missing so sending files doesn't work yet. Receiving also
still seems to have some issues. On the plus side, at least the MSN/Jabber
modules work again.
|
| | |
|
| |
|
|
|
| |
"transfer" since all root commands are singular so far.
|
| | |
|
| |
|
|
|
| |
anywhere, and reworked string handling in ft_listen() a little bit.
|
| |
|
|
|
|
|
|
|
|
| |
ft_listen = <IP-A>:<Port-A>;<IP-B>:<Port-B> to specify listening addresses for
the bitlbee<->client connection and the bitlbee<->IM peer connection,
respectively.
ft_max_size should be obvious. ft_max_kbps should limit the kilobits per second
per transfer (not implemented yet).
|
| |
|
|
|
|
| |
* both ends (proto&dcc) need to finish a transfer now for it to be finished
* moved throughput calc. and some messages to dcc (no need to implement in protocols)
|
| |
|
|
|
|
|
|
|
|
| |
Note that this is only used for sending. The default <local>;<auto> means let
the receiver try a direct connection first and then the proxy discovered from
the server (if any). If you know you're firewalled you can remove the <local>.
If you want to provide your own proxy try something like
"<local>;JID,HOST,PORT". E.g.
"<local>;proxy.somewhere.org,123.123.123.123,7777".
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* allow the SOCKS5 server to not include the pseudo address in its reply(including it is an rfc-style SHOULD in XEP-0065)
* ignore if the SOCKS5 server's reply is too short (as is the one from the jabber.cz proxy [apparently using the proxy65 code])
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
only one buffer of 2k per transfer now.
|
|
|
* move from out_of_data to is_writable, eliminate buffers
* implement "transfers reject [id]"
* documentation in commands.xml
* implement throughput and cummulative throughput boundaries
* feature discovery before sending
* implement sending over a proxy
(proxy discovery, socks5 client handshake for sending, activate message)
* integrate toxik-mek-ft
|
