Hello,
I'm unable to use SOCKS5 proxy (tested with privoxy & tor and Gajim-svn - 20080604 night build). Every time I try to connect I see on my console (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
and nothing more happens. I tried with using HTTP_PROXY environment variable and manual proxy definition as well. I haven't find any similar tickets in trac.
Maybe you know what can be wrong? Is it possible to increase a logging level to see more details about that?
Regards Marcin
Marcin Zajączkowski a écrit :
Hello,
I'm unable to use SOCKS5 proxy (tested with privoxy & tor and Gajim-svn
- 20080604 night build). Every time I try to connect I see on my console
(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
and nothing more happens. I tried with using HTTP_PROXY environment variable and manual proxy definition as well. I haven't find any similar tickets in trac.
Maybe you know what can be wrong? Is it possible to increase a logging level to see more details about that?
Regards Marcin
I haven't tested with tor + privoxy, but with ssh -D, and it works nicely:
DEBUG: CONNECTproxy start Plugging <common.xmpp.transports_nb.NBSOCKS5PROXYsocket instance at 0x1852758> into <common.xmpp.client_nb.NonBlockingClient instance at 0x179e6c8> DEBUG: CONNECTproxy start Proxy server contacted, performing authentification DEBUG: CONNECTproxy sent DEBUG: CONNECTproxy got DEBUG: CONNECTproxy ok Authentification successfull. Jabber server contacted. DEBUG: CONNECTproxy sent jabber.lagaule.orgf DEBUG: CONNECTproxy got
On 2008-06-10 16:01, Yann Leboulanger wrote:
Marcin Zajączkowski a écrit :
(...)
I'm unable to use SOCKS5 proxy (tested with privoxy & tor and Gajim-svn - 20080604 night build). Every time I try to connect I see on my console (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
and nothing more happens. I tried with using HTTP_PROXY environment variable and manual proxy definition as well. I haven't find any similar tickets in trac.
Maybe you know what can be wrong? Is it possible to increase a logging level to see more details about that?
I haven't tested with tor + privoxy, but with ssh -D, and it works nicely:
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.
Regards Marcin
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.
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
Marcin Zajączkowski 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
that'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
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 sent
that'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).
Regards Marcin
On 03.07.2008 00:35, Marcin Zajączkowski wrote:
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 sent
that'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?
With a Yann's help I was also (apart pure Tor) able to use Prixovy as "HTTP Connect" proxy type with Gajim.
Best Marcin
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
-
Marcin Zajączkowski -
Yann Leboulanger