Skip to content
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

Confused and unable to get this to work #5

Open
solkennedy opened this issue Oct 28, 2010 · 12 comments
Open

Confused and unable to get this to work #5

solkennedy opened this issue Oct 28, 2010 · 12 comments

Comments

@solkennedy
Copy link

First, Nick, thanks for building this tool and for your rapid iteration. Love that 0.20 is already out with usability improvements.

I'll admit that I'm a bit out of my comfort zone here, but I can't seem to get this to work on my machine. No doubt I'm doing something naive, but perhaps we can help improve the docs if so.

Installed gem, ran the CLI installer - everything seems set up with the new "untrusted" connection, firefox switched to using the proxy immediately, etc. However, I'm getting "The proxy server is refusing connections" from firefox whenever I'm connecting using the "untrusted" location.

  1. The growl notification seemed to be working in 0.1, but I don't get any new notifications when I switch networks in 0.2.
  2. I've tried two VPS machines, and a dreamhost account with ssh. I'm not entirely sure if I need to do anything special like set up a socks proxy on the server. From the docs I assumed this was not required.
  3. I'm on 10.6.4, and have Little Snitch installed
  4. Firefox is set to use the System Proxy.
  5. I've tried uninstalling and reinstalling, and have updated to 0.20
@nicksieger
Copy link
Owner

Hi, thanks for the report.

Error reporting is a little bit scant at the moment. A couple thoughts:

  1. Check ~/.sheepsafe.log and see if it clues you into anything fishy.
  2. Check "ps" to see if the ssh client proxy is running. There should be a process with command "ssh -ND 9999 user@host".

What I've seen today is that sometimes Sheepsafe is triggered a little too early, before the network connection is made, to successfully start ssh. If that's the case, ssh exits and Sheepsafe doesn't start a new one. Maybe you're seeing that?

@solkennedy
Copy link
Author

Nick,
Interesting. I think I'm getting closer to figuring out what's up. A restart may have helped, because now I can connect to untrusted locations (yay!). It would seem there is something funky with the Network location auto-switching though.

  1. When I'm not connected and I connect to an untrusted network, sheepsafe switches my network location to Untrusted as expected. The connection works after only a 5-10 second delay.
  2. When I'm connected to an Untrusted connection and I switch to a trusted connection, I would expect that my network location would switch back to my default location, but maybe this is not supposed to happen (feature request?). It remains on Untrusted, and my connection no longer works. If I switch manually, I'm good to go.
  3. Additionally, it would seem that there is a bug in trusted connection detection in this (long-tail) flow: Connect to untrusted network -> sheepsafe switches Location to Untrusted -> Switch location to Default -> Location stays on Default (this is ok) -> Switch to a trusted connection -> sheepsafe switches Location to Untrusted (unexpected) . Here's an example log entry from the final step:
    I, [2010-10-27T19:35:31.455066 #695] INFO -- : Switching to Untrusted location
    CurrentSet updated to 10A3EB7E-58F6-44E4-AF8F-1652E788F010 (Untrusted)

Here is an example from my logs, in case there is anything interesting in there:

I, [2010-10-27T19:34:38.003188 #659] INFO -- : Sheepsafe starting
I, [2010-10-27T19:34:38.003334 #659] INFO -- : Switching to Untrusted location
CurrentSet updated to 10A3EB7E-58F6-44E4-AF8F-1652E788F010 (Untrusted)
I, [2010-10-27T19:34:38.042533 #659] INFO -- : Sheepsafe finished
I, [2010-10-27T19:34:48.130701 #674] INFO -- : Sheepsafe starting
I, [2010-10-27T19:34:48.130830 #674] INFO -- : Sheepsafe finished
I, [2010-10-27T19:34:59.742528 #678] INFO -- : Sheepsafe starting
I, [2010-10-27T19:34:59.742658 #678] INFO -- : Sheepsafe finished
I, [2010-10-27T19:35:10.466875 #690] INFO -- : Sheepsafe starting
I, [2010-10-27T19:35:10.467007 #690] INFO -- : Sheepsafe finished
I, [2010-10-27T19:35:31.454924 #695] INFO -- : Sheepsafe starting
I, [2010-10-27T19:35:31.455066 #695] INFO -- : Switching to Untrusted location
CurrentSet updated to 10A3EB7E-58F6-44E4-AF8F-1652E788F010 (Untrusted)
I, [2010-10-27T19:35:31.476567 #695] INFO -- : Sheepsafe finished
I, [2010-10-27T19:35:42.215155 #701] INFO -- : Sheepsafe starting
I, [2010-10-27T19:35:42.215301 #701] INFO -- : Sheepsafe finished
I, [2010-10-27T19:35:52.539182 #709] INFO -- : Sheepsafe starting
I, [2010-10-27T19:35:52.539311 #709] INFO -- : Sheepsafe finished
I, [2010-10-27T19:36:03.207203 #715] INFO -- : Sheepsafe starting
I, [2010-10-27T19:36:03.207332 #715] INFO -- : Sheepsafe finished
I, [2010-10-27T19:37:01.856163 #721] INFO -- : Sheepsafe starting
I, [2010-10-27T19:37:01.856295 #721] INFO -- : Sheepsafe finished

Hope this is helpful!

@nicksieger
Copy link
Owner

Can you try the following to get v0.2.1:

  sheepsafe uninstall
  sudo gem update sheepsafe
  sheepsafe install

I think the way sheepsafe gets triggered from watching /Library/Preferences/SystemConfiguration is a little wonky. It usually gets triggered multiple times and something might not quite be right.

If things don't get better after 0.2.1, can you post your ~/.sheepsafe.yml here too? (Feel free to filter names, MAC addresses or other sensitive info in it.)

@digitalhobbit
Copy link

I'm seeing similar issues. The network detection actually works fine, the growl messages show up, and the network location is changed appropriately. But it looks like the daemon code inside bring_socks_proxy is never triggered. At least the ssh command is not run and I don't see the "Starting ssh..." line in the sheepsafe log.

I'll try to do some more debugging tomorrow.

@nicksieger
Copy link
Owner

Ok, let me know what you find.

I've been thinking I need to convert the ssh daemon into a full-fledged Ruby script that retries the ssh connection a number of times, and logs when things go wrong.

@digitalhobbit
Copy link

I did a whole bunch of debugging, but unfortunately didn't get very far.

Contrary to what I thought at first, the daemon code itself is actually triggered fine. But it's the exec call that doesn't seem to work. When I try replacing exec with system, it returns false, so somehow the ssh command seems to fail (yet, it works fine when I run it manually). When I replace exec or system with backticks to capture the output, I get nothing.

Out of curiosity, have you considered using Net::SSH rather than shelling out to the ssh command?

@soycamo
Copy link

soycamo commented Nov 3, 2010

I am seeing similar problems - once I have it running I can connect to irc and jabber, but Firefox throws the proxy error. Additionally, I noticed a bug in the program related to the LaunchAgents folder. I fixed it but from your cloned branch... so.. uh

@nicksieger
Copy link
Owner

Can you guys try again with 0.2.2? I added code to keep trying to restart ssh.

@nicksieger
Copy link
Owner

@digitalhobbit: I haven't thought of using Net::SSH. What would the benefits of that be?

@soycamo
Copy link

soycamo commented Nov 4, 2010

@nicksieger I was using 0.2.2 when the problem occurred. I wonder if Net::SSH would help keep the connection alive.

btw you'll want to add something like Dir.mkdir PLIST_PATH unless File.exists? PLIST_PATH at line 108 in installer.rb because the LaunchAgents folder doesn't exist.

@digitalhobbit
Copy link

@nicksieger Sorry for the late response! I finally had a chance to try your updated version. It works a little better but I still run into some issues.

sheepsafe now properly starts the ssh connection. However, it doesn't stop it when I switch back to a trusted network. So after switching back and forth, I end up with two concurrent ssh connections.

One thing I noticed when watching "ps|grep ssh" right after switching networks is that the ssh command is always run twice, i.e. the pid changes. The first process is active for a few seconds, and then gets replaced with another one. Perhaps the daemon is somehow still holding on to the original pid and therefore unable to properly kill the process? Unfortunately I'm not sure how the Daemons lib, fork, and trap interfere with local variables. Perhaps just write the pid to a file? Actually, shouldn't Daemons.run_proc already take care of that? I definitely don't see any pid files in my home dir...

@nicksieger
Copy link
Owner

Bump. For any of you still reading, try 0.2.6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants