On 2008-07-02 23:20, Yann Leboulanger wrote:
Marcin Zajączkowski wrote:
Today I was debugging the problem at the privoxy side and it seems that
gajim hangs at the beginning of the conversation, before sending any
"real" data.

At gajim side it looks like (gajim.py -v):
DEBUG: CONNECTproxy start Plugging
<common.xmpp.transports_nb.NBSOCKS5PROXYsocket instance at 0x98015cc>
into <common.xmpp.client_nb.NonBlockingClient instance at 0x904e08c>
DEBUG: CONNECTproxy start Proxy server contacted, performing
DEBUG: CONNECTproxy sent

that's strange that nothing is sent here. re-reading the code, here
connector is suppose dto be sent. It's a base64 encoded string, and then
we wait for the answer.

tcpdump shows following traffic on lo (szpak is a hostname):


In the communication with pure Tor there is one more packet PSH,ACK from
Tor, which is confirmed by Gajim and next Gajim sends its request.
I'm not a TCP expert, but do you thing the lack of that one PSH packet
can cause that ACK is not push to Gajim and it waits for ACK forever (or
at least until a timeout)?

I have more detailed dump from Wireshark if someone is interested.

Maybe full sent/reveiced chars could help

I sent a message a few days ago, but it got lost in a moderation process. The problem is probably that Privoxy is only a web proxy, not SOCKS5 proxy and doesn't "understand" Gajim.
Is it a probable reason in your opinion?

I have also attached a dump. It stops after 5 packets (packet 6 in a dump was triggered by closing Gajim).


Attachment: gajim-privoxy.ws
Description: Binary data

Gajim-devel mailing list

Reply via email to