[Gajim-devel] Gajim-svn and problem with SOCKS5 proxy

[Marcin Zajączkowski]

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 at 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