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 <[EMAIL PROTECTED]> 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




_______________________________________________
Gajim-devel mailing list
Gajim-devel@gajim.org
https://lists.gajim.org/cgi-bin/listinfo/gajim-devel

Reply via email to