gitso 0.6 - Not working between Windows and Ubuntu

[GoogleCodeExporter]

Test with Gitso 0.6 for Windows and Ubuntu:
-Windows should be the client (Get help)
-Ubuntu should be the server (Give support)
-Portmapping to the ubuntu computer was activated (TCP&UDP 5500,5900)

If the remote windows user attempt to connect, a window with the desktop
content of the Windows computer opens on the Ubuntu computer BUT CLOSES
IMMEDIATELY. On the Windows computer following message appears: "Could not
connect."


Following the output of the Ubuntu computer:
$ gitso
vncviewer -listen: Listening on port 5500
vncviewer -listen: Command line errors are not reported until a connection
comes in.
GitsoThread.run(pid: 16391) running...
Connected to RFB server, using protocol version 3.8
Enabling TightVNC protocol extensions
No authentication needed
Authentication successful
Desktop name "arbeitszimmer"
VNC server default format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor.  Pixel format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using shared memory PutImage
vncviewer: read: Connection reset by peer
ShmCleanup called

Original issue reported on code.google.com by daniel.f...@gmail.com on 28 Feb 2010 at 4:10

[GoogleCodeExporter]

What version of Windows are you using?

Can you give support to other clients (different versions of windows, linux or 
OS X)
successfully?

Original comment by gerbe...@gmail.com on 28 Feb 2010 at 11:35

• Changed state: Accepted

[GoogleCodeExporter]

Windows XP Home
Ubuntu 9.10
No other clients available.

Original comment by daniel.f...@gmail.com on 1 Mar 2010 at 8:07

[GoogleCodeExporter]

My guess is that Gitso is not properly identifying if the connection has been 
made.
It checks to see if the VNC process is going, thinks that it isn't and cleans 
up....

If there is anything odd with your system that might help, please mention it.
Otherwise, we'll probably have to wait for other bug reports to come in to see 
if we
can find a common thread. There was also an issue that a user was having between
Windows XP and 2003. Which I'll add to this thread...

That doesn't immediately help your issue, but thanks for the info!

Original comment by gerbe...@gmail.com on 2 Mar 2010 at 4:14

[GoogleCodeExporter]

Issue 40 has been merged into this issue.

Original comment by gerbe...@gmail.com on 2 Mar 2010 at 4:16

[GoogleCodeExporter]

I am the one that reported #40 and I observed a similar behaviour for Ubuntu 
9.10 and
WinXP. I remember that once the connection worked but gitso claimed that it 
failed.
Unfortunately I don't have the time to dig deeper.

Original comment by nik...@gmail.com on 2 Mar 2010 at 8:26

[GoogleCodeExporter]

Windows XP Pro w/SP2 (Get help) and Ubuntu 9.10 Live CD (Give support) worked 
great for me after selecting 
"Unblock" when prompted by Windows Firewall.

BTW, getting Gitso installed in Ubuntu required an extra step for me:

1. Double clicked gitso_0.6_all.deb, which opened in Package Installer with the 
following message: 
"Dependency is not satisfiable: x11vnc"

2. Had to enable universe repository:
System > Administration > Software Sources > check all > Close > Reload

3. Now double clicking gitso_0.6_all.deb and then clicking "Install Package" 
worked just fine.

Original comment by tinya...@gmail.com on 4 Mar 2010 at 7:09

[GoogleCodeExporter]

P.S. Launched Gitso in Ubuntu via:

$ sudo gitso

Attempting to launch with just

$ gitso

returned an error.

Original comment by tinya...@gmail.com on 4 Mar 2010 at 7:11

[GoogleCodeExporter]

Great Thanks! Regarding tips for getting Gitso to run on Linux and Windows. I've
added FAQ items for both of these on the HOW-TO page.

http://code.google.com/p/gitso/wiki/Howto

Original comment by gerbe...@gmail.com on 4 Mar 2010 at 9:32

[GoogleCodeExporter]

Regarding launching gitso with sudo on Ubuntu, you shouldn't have to do this. 
Is the
error any more specific that it is returning when you try to run gitso without 
sudo?

Thanks!

Original comment by gerbe...@gmail.com on 4 Mar 2010 at 9:33

[GoogleCodeExporter]

"Regarding launching gitso with sudo on Ubuntu, you shouldn't have to do this. 
Is the error any more specific 
that it is returning when you try to run gitso without sudo?"

Sorry I didn't give a more specific error message.

After installing Gitso in Ubuntu 9.10 Live CD and attempting to launch like so:

$ gitso

the following error appeared:

Title bar: Python Error
Text: ICO: Invalid icon index.

Clicking "Details" revealed:

can't open file '/usr/bin/../share/gitso/icon.ico (error 13: Permission denied)
ICO: Invalid icon index.

When launching as sudo:

$ sudo gitso

the error did not appear.

Original comment by tinya...@gmail.com on 5 Mar 2010 at 2:33

[GoogleCodeExporter]

Indeed, it looks like it installed it with ownership of the person installing 
and
permissions of 600. It should be owned by root with permission of 644. Thanks 
for the
bug report. I'll fix this in the build script.

The temporary solution would be the following three commands:
sudo chown -R root:root /usr/share/gitso/
sudo chmod 755 /usr/share/gitso/
sudo chmod 644 /usr/share/gitso/*

Thanks again.

Original comment by gerbe...@gmail.com on 5 Mar 2010 at 4:10

[GoogleCodeExporter]

Issue 50 has been merged into this issue.

Original comment by gerbe...@gmail.com on 16 Mar 2010 at 4:10

[GoogleCodeExporter]

OK, Aaron's message in the merged issue thread was:
"I'm guessing this is the same issue as the main issue from 42. There was some 
other
dialog for a couple comments, but the core issue, I believe is the same.  I 
don't
know if Gitso is incorrectly identifying the VNC process as not running, or the 
VNC
client really isn't running. If someone could run the VNC process manually,
by-passing Gitso, that would tell where the issue lies... If I can put together 
more
specific directions, I will do so."

I tried the following:
- "Give support" on Ubuntu
- run WinVnc.exe manually on Windows (Vista64 Business), placed itself in the 
systray immediately
- run Gitso "Get help" on the same Windows

-> WinVNC will complain that another instance is already running (this appears 
when 
clicking "Start" on Windows)
-> nevertheless, after confirming that dialog with "OK", on Ubuntu the Windows 
screen shows up
-> However, Gitso still reports as "Could not connect."
-> Furthermore, when clicking "Start" on Windows Gitso (Get Help) again, it 
endlessly stays "Connecting..." (Neither "Stop" nor the X nor "File,Quit" will 
work, 
and you have to kill the process)

Original comment by harr...@gmail.com on 16 Mar 2010 at 7:53

[GoogleCodeExporter]

I have the same problem on ubuntu / windows 7.
With starting winvnc.exe (find the .exe @ trunk/arch/win32), the Connection 
stands.

Ole

Original comment by olaf.vo...@googlemail.com on 19 Mar 2010 at 4:52

Attachments:

• WinVNC.exe

[GoogleCodeExporter]

So there seems to be a number of issues with Gitso/VNC on Windows. To help 
determine
exactly where the issue is, please review the following commands. I have given 
the
commands that Gitso is running behind the scenes. Running the commands manually 
at
the command prompt will determine if it's an issue with VNC or if it's an issue 
with
how Gitso calls them. If clarification is needed on these, please let me know!

Knowing whether or not you get different results between running Gitso and the
commands manually will be a great help! Additionally, the results from the
appropriate 'netstat' commands (below) will also be a great help!

+++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++

Windows Get Support:
- Replace [Support IP] With the IP from the machine giving support.
- Both of these commands need to be run separately in this order.
     C:\Program Files\Gitso>WinVNC.exe
     C:\Program Files\Gitso>WinVNC.exe -connect [Support IP]


Windows Give Support:
     C:\Program Files\Gitso>vncviewer.exe -listen

+++++++++++++++++++++++++++++++++++++++++

Linux Get Support
     x11vnc -nopw -connect [Support IP]


Linux Give Support:
- Confirm that it is listening on 5500.
- I upgraded to Lucid, and for some reason by default it is listening on 5501. 
You
can override that by 'vncviewer -listen 0'. Then it'll listen on 5500. Probably 
an
entirely separate issue though...
     vncviewer -listen

+++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++

If everything is running fine manually, then lets see what Gitso is doing to 
check to
see if it's running. Specifically, Gitso starts the above processes and then 
checks
on them periodically to see if everything is cool. Use the following commands 
to see
if the processes look fine. The desired result is one line that reflects the 
fact
that the VNC process is running.

+++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++

Windows Get Support:
     netstat -a | find "ESTABLISHED" | find "5500"


Windows Give Support:
     netstat -a | find "LISTEN" | find "5500"

+++++++++++++++++++++++++++++++++++++++++

Linux Get Support:
     LANG=C netstat -an | grep 5500 | grep ESTABLISHED


Linux Give Support:
     LANG=C netstat -an | grep 5500 | grep LISTEN

+++++++++++++++++++++++++++++++++++++++++

Cheers!

Aaron-

Original comment by gerbe...@gmail.com on 22 Mar 2010 at 5:16

[GoogleCodeExporter]

Well,
gerberad: "My guess is that Gitso is not properly identifying if the connection 
has 
been made. It checks to see if the VNC process is going, thinks that it isn't 
and 
cleans up....
If there is anything odd with your system that might help, please mention it."

and if it does that by calling exactly this
gerberad: "Windows Get Support:
     netstat -a | find "ESTABLISHED" | find "5500" "

then the case is clear to me:

As soon as you have a localized Windows, the output of netstat is localized: 
e.g. in 
my German netstat, established is "HERGESTELLT" - and as I take from the bug 
reporters name "Daniel Friedrich", sounds German, as well.

Running the commands manually (starting WinVNC on Windows to Get Support) does 
work 
just fine.

That means you cannot use netstat to determine whether a VNC connection has 
been 
established - as least not in this matter. It would only work for an English 
Windows.

Original comment by harr...@gmail.com on 22 Mar 2010 at 7:29

[GoogleCodeExporter]

Nice! Good catch! You're absolutely correct. In Unix/Linux/OS X systems, you 
prepend the command with "LANG=C" to normalize it.  I don't know enough about 
Windows and locales to know the correct command. Another option would be to 
manage process ID's. In the case of "windows get support", we would need to 
keep 
track of both of the PID's. Gitso used to manage PID's, but when I wrote the 
process 
management to use threads, this changed. If there's not an equivalent of 
"LANG=C" 
for windows systems, maybe that's what we'll have to do...

Can other folks who are having this issue confirm that you are on a system with 
the 
Language set to something other than English?

Original comment by gerbe...@gmail.com on 22 Mar 2010 at 3:09

[GoogleCodeExporter]

Yes, I can confirm that. I had the problem with a german windows, too.

Original comment by nik...@gmail.com on 22 Mar 2010 at 10:31

[GoogleCodeExporter]

For me the same netstat thing.

Running the commands manually (starting WinVNC on Windows to Get Support) does 
work 
just fine.

Starting vnxviewer manually to Give Support runs better with the new 
vncviewer.exe
2.0 beta.

Original comment by olaf.vo...@googlemail.com on 26 Mar 2010 at 9:19

[GoogleCodeExporter]

Same issue here! Starting WinVNC works, but the Gitso window freezes and you 
have to 
manage the connection through the WinVNC client.

Original comment by ballkomi...@gmail.com on 29 Mar 2010 at 12:25

[GoogleCodeExporter]

I worked around this issue with localized Windows in the following way:
I downloaded the english service pack for Windows XP, extracted the files with 
an archiver and expanded netstat.ex_ to netstat.exe, afterwards I copied this 
file to the Gitso program folder.

Original comment by thinp...@gmail.com on 16 Jun 2010 at 5:42

[GoogleCodeExporter]

Re thinpete: That's awesome! I'm still hoping to have a solution implemented 
similar to how it works on OS X / Linux systems. But as a work-around, that's 
sweet!

Original comment by gerbe...@gmail.com on 16 Jun 2010 at 3:57

[GoogleCodeExporter]

another (rude!) workaround is to "overload" the netstat-exe with a netstat.cmd 
batch-file in your gitso directory. german version could look like:

@echo off
%systemroot%\system32\netstat.exe %1 | sed s/HERGESTELLT/ESTABLISHED/ | sed 
s/ABH.*/LISTEN/

(one line from %system... to /LISTEN/ !)
you have to include a sed.exe in your gitso-directory then. you can get one from
http://sourceforge.net/projects/unxutils/

Original comment by jo.berla...@gmail.com on 11 Nov 2010 at 8:46

[GoogleCodeExporter]

I had the same problem, but with Linux (Mandriva 2010.2) in portuguese.
The LANG=C did nothing at all...
As a WorkArround, I manually changed my GitsoThread.py to look for "OUÇA" and 
then it worked just fine! 

Original comment by andre.gu...@gmail.com on 1 Apr 2011 at 5:15

[GoogleCodeExporter]

Workaround described in Comment 23 works fine for me.

Original comment by daniel.f...@gmail.com on 26 Dec 2012 at 12:54

[GoogleCodeExporter]

Perhaps we can use python sockets to get socket information. Otherwise let's 
translate non-English netstat.exe stuff to English inside our code.

Original comment by herr.bi...@gmail.com on 28 Dec 2012 at 4:06

[GoogleCodeExporter]

I had the same problem that gitso appeared to
give up too soon and the connection could not
be completed. I tried the manual way (manually
start helper side listener and manually start
"get help" side). It worked fine.

My solution was to increase timeouts in gitso.
So in "def run(self)" I increased time.sleep(.5)
to time.sleep(2) after the line "self.pid =
self.process.getSupport(self.host)". I did the
same after line "while(self.running and self.checkStatus()):"

Maybe my Thinkpad T40 is so old/slow and the
connection too slow, mut after those increases
gitso has been working fine for me (at least for
the connection part).

"get help" side:
Xubuntu 12.04
IBM Thinkpad T40
Gitso 0.6

"Give support" side:
Windows server 2012
Intel Dual-Core 2.4Ghz
Gitso 0.6

Cheers!

Original comment by saikka...@gmail.com on 10 Jan 2013 at 10:20

[GoogleCodeExporter]

Perhaps we should abandon hard coded parameters and move them to a ~/.gitsorc 
file (or similar).

Original comment by herr.bi...@gmail.com on 14 Jan 2013 at 8:09