[afnog] VNC Problem

[Brian Candler]

On Mon, Jul 17, 2006 at 05:41:11PM +0300, byaruhj at mtn.co.ug wrote:
>    I have got 2 PCs that have connectivity(Ping) btn them but are unable
>    to connect to each other thru VNC. I have tried Remote Desktop and the
>    results are also "fatal"
>    Below is the my logical set up:-)
>     PC 1<->CE1<-> WiMAX Base Station <->MVRFCE Router<-> PE1 <->PE2<->
>    CE2<->PC2
>    when i attempt to connect, the screen starts to open up but stops half
>    way, more less quater way!

Does it stop at that point forever, or does it eventually fill the screen?

The best way to diagnose this problem is to perform a full packet capture at
both sides, PC1 and PC2, using a tool like ethereal (Windows) or tcpdump
(Linux/Unix)

Note that VNC runs over a TCP connection. Therefore, if the odd packet is
lost, it's not a problem: TCP will retransmit.

If the session is freezing completely, this probably means that one side is
sending a particular packet, but the other side is not receiving it. The
sender keeps retransmitting the same packet, but the other side keeps not
getting it. Using ethereal/tcpdump, you can show exactly what these problem
packets are, and identify what is different about them to the preceding
packets which got through successfully.

The best guess I can provide at this stage is that it's an MTU problem. For
example, you may find that the first packets in the VNC session are small,
and send without problems, but as soon as a full-sized packet is sent, it
isn't getting through. IP networks ought to be able to cope with this, but
they may fail, especially if you are filtering out ICMP (which is exactly
why I told another poster not to filter ICMP)

Are the links from PC1 to CE1 both ethernet? This means they have an MTU of
1500, unless you are also running a PPPoE client, in which case the MTU on
the PPPoE interface will be 1492. As for the intermediate links, you'll have
to analyse them for yourselves.

If you have a Unix machine as one of your endpoints, you can send ping
packets of an arbitary size like this:

--- send 1500-byte packets ---
# ping -s 1472 x.x.x.x

(1472 bytes of data, plus 20 bytes of IP header and 8 bytes of ICMP header,
makes a 1500-byte IP datagram in total)

If you get no response from these pings, experiment with different sizes,
e.g. ping -s 1300, ping -s 1400, ping -s 1450 ... until you find out what
MTU you achieve.

If you can demonstrate that this is the problem, then we can move on to
discussing how to solve it.

HTH,

Brian.