TightVNC trouble on Mandrake 10.1
 

I have been using TightVNC server on earlier versions of Mandrake with great success, but since I installed 10.1 official, when I try to connect from a Windows machine with the TightVNC viewer, it makes the connections but all I see is a blue background & the hourglass. This is the log file for the session.

07/11/04 18:48:20 Got connection from client 192.168.1.151
07/11/04 18:48:20 Protocol version 3.3
07/11/04 18:48:24 Full-control authentication passed by 192.168.1.151
07/11/04 18:48:24 Pixel format for client 192.168.1.151:
07/11/04 18:48:24 8 bpp, depth 8
07/11/04 18:48:24 true colour: max r 3 g 3 b 3, shift r 4 g 2 b 0
07/11/04 18:48:24 Enabling full-color cursor updates for client 192.168.1.151
07/11/04 18:48:24 rfbProcessClientNormalMessage: ignoring unknown encoding -223
07/11/04 18:48:24 rfbProcessClientNormalMessage: ignoring unknown encoding 16
07/11/04 18:48:24 Using hextile encoding for client 192.168.1.151
07/11/04 18:48:24 Pixel format for client 192.168.1.151:
07/11/04 18:48:24 32 bpp, depth 24, little endian
07/11/04 18:48:24 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
07/11/04 18:48:24 no translation needed
07/11/04 18:48:24 Enabling full-color cursor updates for client 192.168.1.151
07/11/04 18:48:24 rfbProcessClientNormalMessage: ignoring unknown encoding -223
07/11/04 18:48:24 Using hextile encoding for client 192.168.1.151
07/11/04 18:48:24 rfbProcessClientNormalMessage: ignoring unknown encoding 16
07/11/04 18:50:25 Client 192.168.1.151 gone
07/11/04 18:50:25 Statistics:
07/11/04 18:50:25 key events received 0, pointer events 242
07/11/04 18:50:25 framebuffer updates 2, rectangles 4, bytes 7541
07/11/04 18:50:25 cursor shape updates 2, bytes 1368
07/11/04 18:50:25 hextile rectangles 2, bytes 6173
07/11/04 18:50:25 raw bytes equivalent 3932184, compression ratio 636.997246



Any suggestions would be appreciated.

Start with the obvious first.

1) Did you install any firewall with the installation? e.g. shorewall, iptrables?

2) Can you log in locally via tightVNC?

If you can, see question One again!

3) Did you make all of the required changes to make tightvnc function?

(BTW: check out LinuxTS client! It's trivial to turn this on in Mandrake... merely edit the kdmrc file and enable xdmcp in the line which reads something like

xdmcp=off

then restart the X manager).

Thanks for the heads up on remote login. It was super simple to setup & is EXACTLY what I had been wanting to do, just never new where to look. Thanka again.

Great!

No problem.

The LinuxTSC is working great on a wired connection, however, when I try to run it over a wireless connection, the Cygwin opens but does not make the connection to the linux server. I can ping both ways. Any ideas what might be blocking the xdmcp request over the wireless connection? I have looked through the configuration on the AP & can't find any filtering going on.

Usually things like this occur because the wireless client is using the router as a gateway to the local subnet.

On a standard wired connection the ethernet port on the client is ITSELF the gateway to the local network, so point to point connections occur fine.

On a wireless network this changes as usually your machine must contact the WiFi router and let it act as a gateway to the same local network.

If the router doesn't make this totally transparent to the client (and I've seen occasions where you merely need to cold boot the router to fix this!) then the client doesn't know that it's supposed to use the ROUTER as a gateway to the network.

That is for a wired network where you have an ethernet hard wired client at 192.168.0.9 and a router at 192.168.0.1, the GATEWAY to the 192.168.0.0 network is the eth0 interface at 192.168.0.9

Now let's say that your WiFi interface has an IP of 192.168.0.10, however to reach the 192.168.0.0 network it must use 192.168.0.1 as a gateway.

This SHOULD be transparent to the client, but I've seen cases where it was not or where, probably due to a bug in the firmware, the router lost the ability to make this transparent.

In the latter case a reboot usually clears this up.

I have rebooted & upgraded my firmware since it was 1.5 yrs old. It still is not working. My AP is a Linksys BEFW11S4 if that rings any bells. Would setting a static route make any difference? I will try to diagram my network.

Internet
|
|
ClarkConnect Home 2.1 - 192.168.1.1 - running : firewall, dhcp, squid, dansgaurdian, samba
|
|
Linksys BEFW11S4 - 192.168.1.2
| |
| |
Linux PC - dhcp wireless laptop - dhcp

Thanks

Yeah you have a rather strange configuration

Your Linux box running Clarkconnect is your boundry device, instead of the Linksys which is the usual way of doing things.

With your current configuration you are indeed going to have problems as the Linksys will want to continue to function as a firewall system.

I'd either make it my boundry device OR place it on a seperate subnet.

Then tell Linux how to get to the subnet.

That is, connect the SECOND NIC on your Clarkconnect box to the Linksys's WAN port (A crossover cable may be required).

Make Clarkconnect use a different subnet, say 192.168.100.1, etc.

Then leave the Linksys operating as a router to the 192.168.1.0 subnet from the 192.168.100.0 subnet.

Another option is to set up the Linksys as an Ad-hoc access point. In effect this your wireless link becomes a WiFi extension cable to your wired network.

The latter would probably be easier. The Linux PC would then pull an IP via DHCP from the Clarkconnect box instead of from the Linksys.

The WiFi machine would be "on" the 192.168.1.x subnet but the wifi link itself is nothing more than a conduit with NO firewall or other services on the Linksys in the way.

Note that often you loose the ability to talk to the WiFi router since it MAY loose it's IP assignments altogether when in ad-hoc mode.

Furthermore you must establish a point to point connection from the Linux PC device to the Linksys. I have my Xbox doing this (since it's pretty stupid) and the connected WiFi box acts as client.

I had to remove it from the Xbox, connect it directly to a PC temporarily to set it up and then specify the MAC address (not the IP!!!) of the Ad-hoc device it was to connect to.

It may seem a bit convoluted, but this is what ad-hoc mode was designed for.

You'll probably find complete directions on this on the Linksys site.

My diagram got kind of squeezed together. The ClarkConnect box is serving DHCP to all the clients. I have dhcp server turned off on the Linksys with a static ip of 192.168.1.2 on the router. The second nic from the CC box plugs in to one of the normal switch ports on the linksys just like the other wired clients, so I am not using the router function of it. My understanding is it is just operating as a switch with a wireless AP attatched. I am not sure what you mean by AD-Hoc, the only reference I have heard to AD-Hoc, is wireless devices communicating directly without an AP involved. This is the only reference I have found on Linksys site also.

From the looks of it, you estabilished an initial "control" connection but then as far as the ClarkConnect box goes, your WiFi link dropped the data connection which occurs on incrementing ports (depending upon which session the client is launching on the server...)

Client 192.168.1.151 gone

I still suspect a routing problem though.

With the Linksys configured as you have it, the Linksys may not be purposely passing some packets.

Do other services work wirelessly?

E.G. can you surf the net w/o problems.

Can you bring up web pages on the ClarkConnect box?

TSclients put a heavy load on the network especially at startup, when bitmaps and backgrounds are exchanged. Once this data is cached the load drops off dramatically... yet you are looking the connection quickly on.

There is always the chance that this is a security issue on the Clackconnect box as well, but the fact that a wired connection works makes this less likely.

The clarkconnect box is not the one serving up the xdmcp sessions, it is another wired linux client. And yes I can do anything else I want from the wireless client. I server the web, connect to a vpn server @ work, run TS client through that vpn tunnel to several MS servers at work. The wireless client & the wired linux client which is the app-server can ping each other fine over the wireless, it is just this xdmcp connection which is not being made.

Where (or how) is the other wired machine which you want to connect to, located in your diagram?

All of my wired clients are plugged into the switch ports of the Linksys.

So you have at this point narrowed things down to the Linksys itself.

It does not seem to be passing packets transparently to the local subnet.

It's either filtering them purposely or not routing them correctly.

You may want to check UDP settings as well, but I bet the problem will boil down to be the fact that the Linksys is still not operating in point to point mode, and instead it's still trying to act as an AP.

Why not set it up for Ad-hoc mode instead and see if this resolves the problem?

What should I check in regards to UDP? I can't find where it is doing any filtering. I have not been able to figure out how to put the router in AD-Hoc mode, my understanding is that AD-Hoc is where wireless clients communicate directly without an ap at all.