From: Chris G. <wol...@ch...> - 2003-08-22 17:03:09
|
I have an interested problem on my LAN. I have 2 physically separated networks, which are joined by a machine running iptables. When I use rdesktop in 16-bit mode from one side to the other, it is very slow.=20 The screen refreshes like I am trying to view a 1600x1200 image on a 14.4k modem. Using it on the local subnet is blazing fast. Here's a quick hack up to illustrate: eth0 -> 192.168.0.x eth1 -> 192.168.1.x I have clients on both 192.168.0.x and 192.168.1.x, each connected to their respective interface. The problem is not quite as bad using only 8-bit color, but it is still very noticeable, rather than being unusable when going across links. What seems to be the problem here? I am also having this same problem with the most recent CVS version on a different (much larger) network with 5 VLANS. The WTS is on one VLAN and the clients are on the other 4. Each VLAN is on its own subnet. If you put a client onto the server VLAN, it is fast and works flawlessly, on the client VLANS, it does not. This was not apparent in release 1.2.0, but only in the most recent CVS snapshots. Perhaps something has changed which has caused this breakage? |
From: Harold H. <ha...@he...> - 2003-08-23 02:50:06
|
What rules are your firewall? Perhaps it is blocking needed ports causing resends. Or, perhaps the speed of the machine running iptables? On Friday 22 August 2003 11:17 am, Chris Gianelloni wrote: > I have an interested problem on my LAN. I have 2 physically separated > networks, which are joined by a machine running iptables. When I use > rdesktop in 16-bit mode from one side to the other, it is very slow. > The screen refreshes like I am trying to view a 1600x1200 image on a > 14.4k modem. Using it on the local subnet is blazing fast. > > Here's a quick hack up to illustrate: > > eth0 -> 192.168.0.x > eth1 -> 192.168.1.x > > I have clients on both 192.168.0.x and 192.168.1.x, each connected to > their respective interface. The problem is not quite as bad using only > 8-bit color, but it is still very noticeable, rather than being unusable > when going across links. What seems to be the problem here? > > I am also having this same problem with the most recent CVS version on a > different (much larger) network with 5 VLANS. The WTS is on one VLAN > and the clients are on the other 4. Each VLAN is on its own subnet. If > you put a client onto the server VLAN, it is fast and works flawlessly, > on the client VLANS, it does not. > > This was not apparent in release 1.2.0, but only in the most recent CVS > snapshots. Perhaps something has changed which has caused this > breakage? |
From: Chris G. <wol...@ch...> - 2003-08-23 15:35:46
|
All traffic from eth0 to eth1 is forwarded, with no filtering done. The same thing happens on a network separated by Cisco routers. This *only* happens with the latest CVS version of rdesktop. On Fri, 2003-08-22 at 14:56, Harold Helmich wrote: > What rules are your firewall? Perhaps it is blocking needed ports causin= g=20 > resends. Or, perhaps the speed of the machine running iptables? >=20 > On Friday 22 August 2003 11:17 am, Chris Gianelloni wrote: > > I have an interested problem on my LAN. I have 2 physically separated > > networks, which are joined by a machine running iptables. When I use > > rdesktop in 16-bit mode from one side to the other, it is very slow. > > The screen refreshes like I am trying to view a 1600x1200 image on a > > 14.4k modem. Using it on the local subnet is blazing fast. > > > > Here's a quick hack up to illustrate: > > > > eth0 -> 192.168.0.x > > eth1 -> 192.168.1.x > > > > I have clients on both 192.168.0.x and 192.168.1.x, each connected to > > their respective interface. The problem is not quite as bad using only > > 8-bit color, but it is still very noticeable, rather than being unusabl= e > > when going across links. What seems to be the problem here? > > > > I am also having this same problem with the most recent CVS version on = a > > different (much larger) network with 5 VLANS. The WTS is on one VLAN > > and the clients are on the other 4. Each VLAN is on its own subnet. I= f > > you put a client onto the server VLAN, it is fast and works flawlessly, > > on the client VLANS, it does not. > > > > This was not apparent in release 1.2.0, but only in the most recent CVS > > snapshots. Perhaps something has changed which has caused this > > breakage? |