That message was sent a few days ago, but got lost in a moderation process... I'm sending it again via another channel.
On 2008-06-30 08:10, lilliput Fab wrote:
Marcin,
You should save your capture
tshark -n -i interface port XXX -w gajim-sockv5.pcap -S
and send the gajim-sockv5.pcap into an email, so people could see what's really happening and determine whether it's an issue with gajim or not.
It seems that I have found a reason. As I have been told Privoxy is only a "web proxy" not "SOCKS5 proxy" and doesn't "understand" SOCKS5 protocol. I don't know why I stubbornly wanted to use it despite of pure Tor works as a SOCKS5 proxy very well...
Sorry for inconvenience and thanks for your support.
Regards Marcin
On Sat, Jun 28, 2008 at 11:41 PM, Marcin Zajączkowski mszpak@wp.pl
wrote:
On 2008-06-15 09:12, Yann Leboulanger wrote:
Marcin Zajączkowski wrote:
Thank you for your answer Yann.
I checked my Gajim with ssh -D (I didn't even know about that
option to
get SOCKS5 proxy) and it was fine. I have also checked it with
pure Tor
and it worked either. It seems to be an issue with privoxy itself. I'm a little bit astonish, because a few other apps work with privoxy without any problem. I will try to debug it on the privoxy side.
Ok, thanks for trying to make it work ! Please keep us informed of your progress.
Hello again,
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 sent
tcpdump shows following traffic on lo (szpak is a hostname): 23:55:35.994463 IP szpak.45365 > szpak.privoxy: S 580179035:580179035(0) win 32792 <mss 16396,sackOK,timestamp 12080872 0,nop,wscale 6> 23:55:35.994519 IP szpak.privoxy > szpak.45365: S 580266575:580266575(0) ack 580179036 win 32768 <mss 16396,sackOK,timestamp 12080872 12080872,nop,wscale 6> 23:55:35.994553 IP szpak.45365 > szpak.privoxy: . ack 1 win 513 <nop,nop,timestamp 12080872 12080872> 23:55:35.996639 IP szpak.45365 > szpak.privoxy: P 1:5(4) ack 1 win 513 <nop,nop,timestamp 12080874 12080872> 23:55:35.996714 IP szpak.privoxy > szpak.45365: . ack 5 win 512 <nop,nop,timestamp 12080874 12080874>
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.
Regards Marcin