Ever since we upgraded to Vine Server 3.1 (from 3.0) on our MBP’s running 10.5.6, the default ‘vncview’ on RHEL5 has ceased to function with Vine Server. Here’s more detail:
Symptom:
when connecting from EL5 (vnc 4.1.2-14.el5_3.1) to OSX (Vine Server), user gets prompted for a passwd, a black window the size of the OSX desktop shows up and then vncviewer exists.
Settings: no settings were modified on either the EL5, OSX or Vine Server. The only item that changed was that Vine Server was upgraded from 3.0 to 3.1.
Connection from either EL5 or Windows XP to OSX with Vine Server 3.1 works fine with TightVNC 1.3.9 (on both Windows and same EL5 machine).
Is there anything that changed in Vine Server 3.1 that now makes vnc-4.1.2 exit? Any ideas? Is there anything that can be configured to make 3.1 more compatible or should I just downgrade to 3.0?
When you check Vine Server on OSX, do you find that it has crashed (and possibly been auto-restarted)?
Yes, it auto-restarted… I can see from the system log that it died
Does RHEL5 vncviewer have options to change the encoding to something like Zlib+hex, Zlib+XOR, Hextile, RRE, CoRRE, … If so, do those encodings work?
If so, it might be the same problem.
Yes, sure looks like it. Thanks for the tip.
vncviewer under RHEL5 has three encoding choices:
ZRLE (default), hextile and ‘raw’.
I can confirm that Vine Server 3.1 crashes with ZRLE but not with the two others (hextile and raw).
That’s definitely a regression, how can we help the developpers debug this? I’m not very familiar with debugging apps on OSX but I’m willing to try to help…
Thank you for your help (with your workaround, I don’t need to deploy tightvnc on our EL5 boxes).
Actually you’ve already done plenty to help track this issue down. Knowing that ZRLE is the culprit was a huge help and we’ve been able to duplicate it here. Hopefully we’ll have a fix for this problem shortly.
