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 authentification DEBUG: CONNECTproxy sentthat'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).
Description: Binary data
_______________________________________________ Gajim-devel mailing list Gajimfirstname.lastname@example.org https://lists.gajim.org/cgi-bin/listinfo/gajim-devel