Bug 112603 - Xserver don't accepts remote programs
Xserver don't accepts remote programs
Product: Fedora
Classification: Fedora
Component: XFree86 (Show other bugs)
athlon Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-12-24 06:58 EST by fv3358
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-12-24 10:23:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description fv3358 2003-12-24 06:58:31 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4.1)

Description of problem:
When executing a graphic progran in another box, with the DISPLAY
variable pointing my Fedora box, the remote program can't use the X
(gftp-gtk:22754): Gtk-WARNING **: cannot open display:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.xhost +
2.telnet otherlinux
3.gftp &

Actual Results:  (gftp-gtk:22754): Gtk-WARNING **: cannot open display:

Expected Results:  the window of the executed program appears in my

Additional info:
Comment 1 Mike A. Harris 2003-12-24 10:23:26 EST
Remote X applications work just fine, however you do have to make
sure that you are configuring your system properly, and that there
is no firewall blocking things in the middle in either direction.

If you have trouble configuring things, you may wish to seek
technical support help on one of the Red Hat and/or XFree86 mailing
lists, where someone may be able to provide specific detailed help
to the problem you are having.

Closing as 'WORKSFORME'
Comment 2 fv3358 2003-12-24 17:31:56 EST
I'm in a LAN without internal proxy or firewall. The same
configuration was working between two RedHat9 boxes. Now, I changed
one of them by a Fedora 1. The other one is www.cyberfenix.net, you
can see.
When the client (The Redhat 9 box) sends syn packets to the Xserver
(The Fedora box), this answers only with
TCP ZeroWindows packets, with the ACK and --->>> RST<<<--- flags set.
Then the client tryes with syn packets again, several times and,
finally, stops with error.
Do you think that this is due a configuration problem? I dont think so.

Comment 3 Mike A. Harris 2003-12-24 21:47:14 EST
>Do you think that this is due a configuration problem? I dont
>think so.

I realize, that in your frustration trying to get your particular
problem solved, that you may personally believe that this is not
a configuration issue, however I can assure you with 110% certainty
that it very much is a configuration issue.

Red Hat does not provide technical support via bugzilla, however
you may contact your Red Hat technical account manager for support
assistance if you have a technical support contract with Red Hat,
and they may or may not be able to provide direct one on one
technical support to help you configure your systems depending on
the level of support that you have purchased.  If you do not have
a technical support contract with Red Hat, then other options you
can explore include the Red Hat and XFree86 mailing lists as
described above in my last comment.  You may also wish to try
searching the web on www.google.com or some other search engine.
You can also search existing bug reports for users with similar
problems, and see what their solutions were (if any).

Nonetheless, this definitely is a technical support issue with
respect to the configuration with your system, which may include
firewall related problems, xdm/kdm/gdm display manager related
problems, or options passed to (or not passed to) the X server at
startup.  It may also include other problems.  Either way, we
do not provide technical support in bugzilla, so I am unable
to help you directly, other than what I've shared here.

Note You need to log in before you can comment on or make changes to this bug.