I was aware of MTU, I just didn't realize VPNs were testy about them. (enough to make VNC choke)
I found the following information on Netgears website, but it pertains to all networks.
Setting MTU size is a process of trial-and-error: start with the maximum value of 1500, then reduce the size until the problem goes away. Using one of these values is likely to solve problems caused by MTU size:
1500. The largest Ethernet packet size; it is also the default value. This is the typical setting for non-PPPoE, non-VPN connections. The default value for NETGEAR routers, adapters and switches.
1492. The size PPPoE prefers.
1472. Maximum size to use for pinging. (Bigger packets are fragmented.)
1468. The size DHCP prefers.
1460. Usable by AOL if you don't have large email attachments, etc.
1430. The size VPN and PPTP prefer. <= My answer! woohoo :)
1400. Maximum size for AOL DSL.
576. Typical value to connect to dial-up ISPs.
David
Junk wrote:
Simon Hobson wrote:
I can telnet to these ports. (I get the RGB xxx.yyy when I telnet to port 5900) If I try to make this connection on a local lan. (brought the PC to this location) There are no problems connecting at all. I just don't understand. I can telnet to all the ports without problem. I read that ICS could be a problem on Windows2000 and XP, but it was already disabled.Junk wrote:
I have 2 Netgear FVS328 VPN routers connected over 2 DSL lines. Their is a VPN up and running. I can ping/telnet etc from one network to the other.
The problem is. When I attempt to use VNC or PCAnywhere for that matter, it connects, then stalls. It ask for the username and password then opens the application window and then fails to render anything. (black screen) It just sits there then after a couple of minutes it just disconnects.
I ran Etheral and I didn't see anything wrong that I could tell. Each PC was talking back and forth in what seem to be a normal TCP connection.
If anyone has any ideas would could be causing this it would be greatly appreciated.
Assuming that traffic is able to pass freely on the required ports (580x or 590x) then the other issue may be your colour depth. I use VNC to access the office systems from home, and it can take quite a while to download the windows wallpaper if you haven't turned it off and/or reduced the bit depth that VNC is transferring. I don't know if there is anything in the protocol that might time out if a screen update takes too long.
What I've found (using Chicken of the VNC on OS X) is that the initial screen draw is not drawn on screen until the entire screen is downloaded - so you get a long pause and black screen. If I switch between normal and full-screen modes, it draws what it has downloaded so far and so it is easy to see that the delay is due to downloading the initial window (ie wallpaper).
I would suggest turning off the wallpaper and connecting at a lower bit depth and see if that helps things.
Hmm.. The system doesn't have any wallpaper. (just a black background) Generally, the POS software is open and cannot be minimized by the user without an administrative password.
Simon
_______________________________________________ VNC-List mailing list [EMAIL PROTECTED] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
_______________________________________________ VNC-List mailing list [EMAIL PROTECTED] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
