If auth is used, it hangs after a couple of page loads in browser.

[ss-17]

Hi.

Thanks for this nifty tool. For testing I am using FoxyProxy with Firefox.

./microsocks -p 7659 => keeps working.

./microsocks -p 7659 -u me -P 12345678 => hangs after loading 2-3 websites in browser. nothing loads thereafter.

Any idea what could be causing this?

Regards.

[rofl0r]

no ideas what could causing it. but here are some ideas to find out what's happening

• start wireshark an sniff on the lo device (responsible for localhost communications)
• press ctrl-shift-q in firefox to go into the network monitor, then select the preferences icon there and "disable HTTP caching" and stay in the network view while testing if you cant make sense of the wireshark diags you can export a pcap and share it here with me to help analysis.

[ss-17]

Will get you the capture you have asked for. If possible, can you give me the tcpdump command to run on server/client? But before that I have come across possible/related issue. When the socks server is running as:

root@s5server:~/microsocks-master# ./microsocks -u me -P 12345678

Every other connection is getting rejected with: "curl: (7) User was rejected by the SOCKS5 server (1 2)." :

root@s5client:~# while true; do curl -U 'me:12345678' --socks5 xx.xx.xx.xx http://icanhazip.com; done
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).
xx.xx.xx.xx
curl: (7) User was rejected by the SOCKS5 server (1 2).

But if the server is running with auth disabled:

root@s5server:~/microsocks-master# ./microsocks

Its working as expected:

root@s5client:~# while true; do curl --socks5 xx.xx.xx.xx http://icanhazip.com; done
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx
xx.xx.xx.xx

There tests are done using 2 fresh VPSes with a freshly compiled microsocks. Gladly it just requires a "make" :)

[rofl0r]

try $ curl --socks5 user:pass@localhost:1080 google.com

tcpdump -w file.cap -i lo should do if you access the proxy via localhost

[ss-17]

try $ curl --socks5 user:pass@localhost:1080 google.com

same result. every other attempt fails:

root@s5server:~# while true; do curl --socks5 me:12345678@127.0.0.1:1080 http://google.com; done
curl: (7) User was rejected by the SOCKS5 server (1 2).
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
curl: (7) User was rejected by the SOCKS5 server (1 2).
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
curl: (7) User was rejected by the SOCKS5 server (1 2).
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
curl: (7) User was rejected by the SOCKS5 server (1 2).
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
curl: (7) User was rejected by the SOCKS5 server (1 2).
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
curl: (7) User was rejected by the SOCKS5 server (1 2).
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
curl: (7) User was rejected by the SOCKS5 server (1 2).
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
curl: (7) User was rejected by the SOCKS5 server (1 2).
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>

In the attached zip file, the pcap file when curl produces <HTML> ... </HTML> is present as good.pcap and on subsequent attempt when it fails with curl: (7) User was rejected by the SOCKS5 server (1 2). is present as bad.pcap

[ss-17]

I figured that when every subsequent curl fetch is failing, the error is occurring inside the function check_credentials because if I make the function return EC_SUCCESS unconditionally no error occurs. So in order to debug I put this line:

dolog("auth_user: %s user: %s auth_pass: %s pass: %s\n", auth_user, user, auth_pass, pass);

just before:

if(!strcmp(user, auth_user) && !strcmp(pass, auth_pass)) return EC_SUCCESS;

and the output is:

auth_user: me user: me auth_pass: 12345678 pass: 1234567R¦6
auth_user: me user: me auth_pass: 12345678 pass: 12345678
auth_user: me user: me auth_pass: 12345678 pass: 12345678@
auth_user: me user: me auth_pass: 12345678 pass: 12345678
auth_user: me user: me auth_pass: 12345678 pass: 12345678@
auth_user: me user: me auth_pass: 12345678 pass: 12345678
auth_user: me user: me auth_pass: 12345678 pass: 12345678@
auth_user: me user: me auth_pass: 12345678 pass: 12345678
auth_user: me user: me auth_pass: 12345678 pass: 12345678@
auth_user: me user: me auth_pass: 12345678 pass: 12345678
auth_user: me user: me auth_pass: 12345678 pass: 12345678@
auth_user: me user: me auth_pass: 12345678 pass: 12345678
...

again:

auth_user: me user: me auth_pass: 12345678 pass: 1234567eza 
auth_user: me user: me auth_pass: 12345678 pass: 12345678
auth_user: me user: me auth_pass: 12345678 pass: 12345678@
auth_user: me user: me auth_pass: 12345678 pass: 12345678
auth_user: me user: me auth_pass: 12345678 pass: 12345678@
auth_user: me user: me auth_pass: 12345678 pass: 12345678
auth_user: me user: me auth_pass: 12345678 pass: 12345678@
auth_user: me user: me auth_pass: 12345678 pass: 12345678
auth_user: me user: me auth_pass: 12345678 pass: 12345678@
auth_user: me user: me auth_pass: 12345678 pass: 12345678
auth_user: me user: me auth_pass: 12345678 pass: 12345678@
auth_user: me user: me auth_pass: 12345678 pass: 12345678
auth_user: me user: me auth_pass: 12345678 pass: 12345678@
....

The above outputs also show that after microsocks invocation, the first connect is always failing and then every even numbered attempt is a success and every odd one is a failure.

[rofl0r]

good find. it was a stupid bug... it was obvious when i saw your log output with the bogus passwords. let me know if it works now

[ss-17]

Working perfectly fine now. :+1: Bye bye Dante :)

[ss-17]

One more thing. Can this code snippet from sblist.c:

#ifndef PAGE_SIZE
#warning "your C library sucks."
#define PAGE_SIZE 4096
#endif

be replaced with:

#include <unistd.h>
#ifndef PAGE_SIZE
#define PAGE_SIZE sysconf(_SC_PAGESIZE)
#endif

compiled fine for me but does this have any side-effects?

[rofl0r]

the effect of that change is that constant propagation doesn't kick in which the compiler can use to heavily optimize the spots where the value is used. like it can use shifts instead of mul/div because it knows it's a power of 2

if you don't want the warning just remove the warning line...

btw may i ask what OS and arch you're testing on ? i've not experienced the bug on any of my testsystems.

[ss-17]

Debian 8 64-bit