[Gajim-devel] Gajim-svn and problem with SOCKS5 proxy
mszpak at wp.pl
Thu Jul 3 00:27:27 CEST 2008
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:
> 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.
> On Sat, Jun 28, 2008 at 11:41 PM, Marcin Zajączkowski <mszpak at wp.pl>
>> 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
>>>> get SOCKS5 proxy) and it was fine. I have also checked it with
>>>> 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
>> 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
>> At gajim side it looks like (gajim.py -v):
>> DEBUG: CONNECTproxy start Plugging
>> <common.xmpp.transports_nb.NBSOCKS5PROXYsocket instance at
>> <common.xmpp.client_nb.NonBlockingClient instance at 0x904e08c>
>> DEBUG: CONNECTproxy start Proxy server contacted, performing
>> 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
>> 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.
More information about the Gajim-devel