nc command not working properly, and dispatch needs to be dispatch_now

[vesper8]

Am running this on Laravel 5.8 on Ubuntu 18.04 (works fine on my dev environment on OSX)

Few things I noticed, this is true of both my prod and osx environments, when I run php artisan tunnel:activate it always returns $this->warn('I have no idea how this happened. Let me know if you figure it out.');

If I dd the content of $result it prints:

Illuminate\Foundation\Bus\PendingDispatch^ {#25
  #job: STS\Tunneler\Jobs\CreateTunnel^ {#2783
    #ncCommand: "/usr/bin/nc -z 127.0.0.1 13306  > /dev/null 2>&1"
    #sshCommand: "/usr/bin/ssh -o StrictHostKeyChecking=no  -N -i /Users/vesperknight/.ssh/id_rsa -L 13306:127.0.0.1:3306 -p 22 forge@188.166.81.133"
    #output: []
    +"bashCommand": "timeout 1 /usr/local/bin/bash -c 'cat < /dev/null > /dev/tcp/127.0.0.1/13306' > /dev/null 2>&1"
  }
}

If you change dispatch to dispatch_now ($result = dispatch_now(new CreateTunnel());) in TunnelerCommand.php then it works as intended and returns an integer if the tunnel is detected

This resolution is also mentioned in #16 (comment)

Furthermore, on Ubuntu 18.04, every time I try either tunnel:activate or dispatch(new \STS\Tunneler\Jobs\CreateTunnel()); or dispatch_now(new \STS\Tunneler\Jobs\CreateTunnel());

I always get an error

Could Not Create SSH Tunnel with command:
  	/usr/bin/ssh -o StrictHostKeyChecking=no  -N -i /home/web/.ssh/id_rsa -L 13306:127.0.0.1:3306 -p 22 forge@188.166.81.133
  Check your configuration.

This is a false-positive however, because the tunnel IS created, the failure is due to the NC command not being able to properly verify that the tunnel is already created

The command /bin/nc -z 127.0.0.1 13306 (/bin/nc is my nc path on Ubuntu 18.04) simply returns nothing. On OSX /usr/bin/nc -z 127.0.0.1 13306 does correctly detect the tunnel

On Ubuntu, this command does show that the tunnel is active and listening lsof -i -n | egrep '\<ssh\>'

But the NC command does not.. so it throws the error every time because it can't verify that it's active. That means that having dispatch_now(new \STS\Tunneler\Jobs\CreateTunnel()); in your script prior to an occasional use of the tunnel will always fail because the error is thrown and uncaught in this scenario. But scheduling the 'tunnel:activate' command will work out, although it will pollute your log files with false errors

After a little digging around, I found this thread that describes what seems to be a bug with the newer version of netcat.. where using -z alone does not return any output, but using it with -v does.. but then it also provides output in case of a failure

So I've adjusted the script so that it works with old and new netcat like this:

/usr/bin/nc -vz 127.0.0.1 13306 2>&1 | grep succeeded -> ok
/usr/bin/nc -vz 127.0.0.1 10000 2>&1 | grep succeeded -> not ok

I'm going to make these changes in a fork, and if things seem to work ok I will submit a PR, unless you want to beat me to it :)

Thanks!

[vesper8]

I've added a PR that fixes all issues #32

[bubba-h57]

Per merged and new release .. well, released! Thanks for the PR!