Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4374153

Some graphics don't get drawn when forwarding X11 over ssh (secure shell)


    • Subcomponent:
    • Resolved In Build:
    • CPU:
      generic, sparc
    • OS:
      generic, solaris_7, solaris_8


      The ssh (secure shell) program establishes an encrypted connection between hosts, and establishes an interactive shell session much like the classic
      rsh or rlogin programs. In addition, it can forward other TCP/IP traffic
      between the connected hosts. In particular, it can easily forward X11
      protocal requests, making it appear that the local display actually belongs
      to the remote machine. For example, a session might look something like:

      A> ssh B
      Welcome to host B...
      B> echo $DISPLAY
      B> xterm
      (xterm pops up on A:0.0 -- B:10.0 is forwarded to A:0.0)

      Suppose boths hosts may live behind firewalls that only allow ssh traffic.
      Setting DISPLAY on B to A:0.0 would not work since X11 would attempt to
      establish a direct connection to A, which would be blocked by the firewall.
      Thus, in many security-concious environments, all X11 traffic is transported
      over ssh connections.

      When a JFC application is run, the main window appears but large portions
      of its contents are not drawn at all. Dragging other windows on top of the
      window to attempt to force a refresh does not work. Running the same
      program using a normal DISPLAY setting works fine. The SwingSet2 demo
      from JDK1.3 is a good test case as very little ends up being drawn.

      One possibility is that Java2D is arriving at the incorrect conclusion
      that the display B:10.0 is local to host B, and attempting to draw without
      issuing X commands. If this is the case, some additional tests must be done
      to determine if the display is truly local.

      Once this problem is resolved, an ssh test case should be incorporated into
      the AWT/Java2D test suites.

      The problem was pointed out by Scott Schwartz at Penn State, who has been
      unable to work around the problem.

      daniel.rice@Eng 2000-09-27

      An additional note from Scott:

      Here's some more information, which might be useful.

      In one xterm:
      A% ssh B

      In another:
      A% ssh C
      C% setenv DISPLAY B:9
      C% java ...

      In other words, get machine C to display via plain tcp to B, and from
      there via the ssh tunnel to A. The idea is to make sure that C doesn't
      think the X server is local, while still going through an ssh tunnel.
      And it works. This suggests that ssh itself isn't buggy with respect
      to X11 tunneling, but that java is buggy as it wrongly thinks that
      the display is local.


          Issue Links



              • Assignee:
                tdv Dmitri Trembovetski (Inactive)
                dricesunw Daniel Rice (Inactive)
              • Votes:
                0 Vote for this issue
                0 Start watching this issue


                • Created: