-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
issues with localnet #12
Comments
does other stuff such as telnet, wget, netcat work correctly ? |
I just tried a simple python client and server and they seem to work okay. so, something is special about transmission. |
I ran transmission in the foreground with proxychains in DEBUG mode. I don't see any mention of connections to or from localhost/127.0.0.1 when I attempt to connect to it's web interface. I'm wondering if transmission is even receiving my connection requests. netstat shows that it is listening on the ports on all interfaces. Here is a snippet of the output with ip addresses X'ed out (there may be some extra debug print statements I added when debugging the hb_fill() issue): DEBUG:pid[17932]:chain_step |
i just tried proxychains 4.4 on an ARM machine using both glibc and musl libc, no problem at all with hdb_fill locking up. can you provide versions of glibc you are using ? |
you are aware that server programs do not work at all with proxychains ? how do you expect a connection that is made from someone else to go through a proxy. |
understood. but the web interface for transmission is only available on the local network, and I don't want any incoming connections to it from the proxy. thus having local connections bypassed in the localnet setting. I'm using libuClibc-0.9.28.so |
so, let me try to understand the issue btw, whats your setting here ? https://github.com/rofl0r/proxychains/blob/master/src/proxychains.conf#L51 |
yes, transmission is run via proxychains, outgoing connections not destined for 127.0.0.1 are to go through the proxy. the servers sockets should work per normal, but apparently aren't. As i said, I verified with a simply python server script that proxychains is not hindering server sockets or local connections, so it's something that transmission is doing. i am simply using a browser (or wget/curl) to access the server sockets without proxychains. the setting for remote_dns_subnet is 224. |
how do you start transmission ? please provide the used command line (including configuration needed to get the web interface up) so i can do some tests. |
i tested on ubuntu as well and received the same result. you'll need to install transmission-daemon and transmission-cli. to run it put the settings.json file in /tmp: proxychains4 transmission-daemon -f -g /tmp/.transmission-daemon -e /tmp/transmission-daemon.log --log-error --log-info --log-debug Then go to the web interface at http://127.0.0.1:9091 or using the remote interface "transmission-remote -l" Here is what my settings.json file looks like: { |
I have compiled rofl0 proxychains 4.4 for linux on an ARM processor.
First it would get stuck during the hb_fill() call, so I basically commented out the contents (much like is done for BSD). Subsequently the application runs seemingly correctly, however, even with localhost allowed as a localnet in my configuration file, I cannot access that application (transmission) on the same host.
Transmission has both a web interface and a local interface accessed via RPC. Neither work, both hang until a long timeout occurs. This leads me to believe that proxychains is not sending responses back to localhost.
Can someone provide some debugging tips such that I can try to offer the maintainers more details that might track down the problem? I turned on DEBUG, but I quickly lose the output as the program backgrounds as a daemon and all output disappears.
Thanks.
The text was updated successfully, but these errors were encountered: