VMWare Server 2.0.2 Web Interface Inaccessible

RESOLVED INVALID

Status

--
major
RESOLVED INVALID
9 years ago
9 years ago

People

(Reporter: swu98, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4

Attempt to connect to VMWare Server 2.0.2 Web Interface always results in either a blank page or "The connection was reset

      

      
      
      

      
        
        

          

The connection to the server was reset while the page was loading.

        


        
        


    *   The site could be temporarily unavailable or too busy. Try again in a few
          moments.

    *   If you are unable to load any pages, check your computer's network
          connection.

    *   If your computer or network is protected by a firewall or proxy, make sure
          that Firefox is permitted to access the Web."



Reproducible: Always

Steps to Reproduce:
1. attempt to connect to VMWare Server 2.0.2 web interface https://<IP>:8333/ui
2. Accept the self signed cert and continue
3. 
Actual Results:  
blank page or connection is reset error appears

Expected Results:  
Web interface should load as expected.
(Reporter)

Updated

9 years ago
Component: Security → General
Hardware: x86 → x86_64
QA Contact: firefox → general

Comment 1

9 years ago
Created attachment 422525 [details]
FF3.6 RC2 after loading VMware Server 2.0.2 webinterface

Comment 2

9 years ago
Created attachment 422527 [details]
FF3.6 RC2 after re-loading VMware Server 2.0.2 webinterface with shift-reload

Comment 3

9 years ago
This is blocking bug. What is this all about? I asked in the german FF forums and on VMware community site forums for VMware Server but noone could help with the suggestions made there.

Seems that I am really not the only one experiencing this problem. As long as this persists, we can't switch to FF3.6.

We would be very glad if somebody could check this.

Michael

Comment 4

9 years ago
Same error also with Firefox 3.6 and OpenSuSE 10.3.
There seem to be a lot of people which cannot use Firefox 3.6 and VMWare
together.

Comment 5

9 years ago
Same error with Firefox 3.6 Final and Windows XP. In the same machine I'm able to open the Console Plugin using IE8.

Comment 6

9 years ago
There are also other plugins that stoped working with FF 3.6. Net iD from secmaker also stoped working with FF 3.6. This is a system for secure login to servers on the web.
(Reporter)

Comment 7

9 years ago
For clarification, the bug I filed is regarding not being able to access the web interface, which should be a simple webpage served by VMWare 2.0.2.  This bug is not related to any web plugins.   

If anyone wants to repro this issue,  install VMWare Server 2.0.2 on your computer.  On the computer it is installed on, you can go to https://localhost:8333 with Firefox 3.6 final and you will see either a blank web page or a connection was reset error.

Comment 8

9 years ago
I'm running into this same issue. The relevant VMWare Forums thread is here:

http://communities.vmware.com/message/1462604#1462604

The workaround to enable SSL2 does allow access to the admin page, but the VMWare console plugin fails.  I have verified that I can login fine via both Internet Explorer and earlier Firefox versions. This affects both Linux and Windows versions (tested on FF3.6 on CentOS 5.4 and Win7).

Comment 9

9 years ago
OK, so if this is only about accessing https://localhost:8333/ I would say it is not a bug. Only that you have to activate some setting changed in FF 3.6. There is a bugzilla report about the plugin.

https://bugzilla.mozilla.org/show_bug.cgi?id=529686
>Only that you have to activate some setting changed in FF 3.6.

That doesn't make sense. SSLv2 support was removed in Firefox 2.0.

Anyways, confirmed (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2)
Gecko/20100115 Firefox/3.6).

-> NSS for investigation. I'm still trying to get some meaningful logs...
Assignee: nobody → nobody
Status: UNCONFIRMED → NEW
Component: General → Libraries
Ever confirmed: true
OS: Windows 7 → All
Product: Firefox → NSS
QA Contact: general → libraries
Hardware: x86_64 → All

Comment 11

9 years ago
It's not only that it is not loading the management page, it is also not possible to run the console!

It is now 6 months after the first report and Firefox is still not running VMware 2.0, the most common virtulation software. How long will it take untill "Firefox" repaired that problem?!

The internet forums are full of people not knowing what to do. I install everywhere the old 3.5 versions, they are running without the problems.

Chaning settings in 3.6 do NOT help, I tried everything I could find in the internet and also other administrators I know are angry about this problem and have no solution than using other browsers or the old Firefox versions.
Your server is unhappy.  It's not sending complete pages, and often 
abruptly disconnecting its connection to the client. Only your server 
knows why.  Dig into it.  Find out what it's unhappy about.  
If you have server logs, start there.

Comment 13

9 years ago
"Your server is unhappy.  It's not sending complete pages, and often 
abruptly disconnecting its connection to the client. Only your server 
knows why.  Dig into it.  Find out what it's unhappy about.  
If you have server logs, start there."

I gues, not sure, you want to answer to my posting. Correct?

I do not believe that it is the VMware-Server. There is no console for the Firefox 3.6. versions. All servers are running fine for a long time now.

If you look through the internet, everybody using VMware-Server 2.0, have these problems with the new Firefox-versions. It worked fine untill Firefox came with new versions of Firefox.

If you have more information I would be happy to check it.

I also tried to check and change the SSL2 in Firefox, like mentioned above, but it did not help. Just using the version 3.5.8 (maybe 9 too) works fine with VMware.
Ralf,  I'll spell it out in a little more detail to you.
Your https server on port 8333 is unhappy.  

There's no evidence in your report (including the screen shots) of any 
problem with SSL anywhere.  The evidence shows 
- problems with https content over an apparently successful SSL connection
- problems with TCP connection being reset by the https server.  

No indication of any SSL problems whatsoever are shown here. 
Firefox is not unhappy.  It's not reporting any problems with SSL at all.
It's showing a successful SSL connection.  The https server is having the
problem, dropping the connection.  If you want to see the problem be 
corrected, you must look at your https server logs to find out what it's 
unhappy about.  Firefox developers will not do that for you.
I looked at the thread cited in comment 8.  The only meaningful factual 
report there is that the server logs are full of error that say:
    SSL Exception, session id context uninitialized
Session ID contexts are data structures created and maintained solely by 
the server.  The server is complaining that it has discovered that it is 
trying to use a structure that it previously created but failed to initialize.

Server bug, not browser bug.  One possible explanation is that firefox offers 
to use some feature of the TLS protocol that the server has incompletely or incorrectly implemented, and the server trips over its own implementation, 
instead of simply ignoring the offer.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
(Reporter)

Comment 16

9 years ago
If you say that this bug is a server side error,  what changed in Firefox 3.6.x?  Firefox 3.5.x works fine with the existing server.  VMWare 2.0.2 server also works fine with that other browser made by the Redmond company.

Comment 17

9 years ago
The main question is - why did it work in 3.5.8 but doesn't work in 3.6? What changed? If you figure that out, you'll have your answer.
You need to log in before you can comment on or make changes to this bug.