I believe that the answer you received in your PMR is the authoritative
one. As I uderstand it, the current web client will attempt to use
additonal ports whenever it sees the need and will not honor your attempt
to restrict it to just a few, though you may specify the primary or
original one. It is unfortunate that it was not designed to allow
communication across a firewall in this manner. I expect that to be
addressed in a future release. But until then I think that your client
will have to get access to a box behind that firewall and run the web
client on that box, just as we in IBM do here.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
Uwe.Richter@synthesis.de@tkg.com on 01/29/2001 12:06:12 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: nv-l@tkg.com
cc:
Subject: [NV-L] NetView Webclient through Firewall
We have severe problems connecting the NVWC through a firewall with the
NV server. We have opened ports 80, 8080 and 8892, 8893 on the firewall
and
forced NV to use port 8893 as secondary port (with the option
"-DportToUse=8893" in the "maptreeserver.reg" file ). Only one map is
open.
However a trace on the NVWC-Computer and the firewall shows that the
NetView Server
opens another arbitrary port to communicate with the Web Client.
We have open a PMR. Here the answer:
The process invoked is as follows:-
1. client connects to advertised server port (8893)
2. server breaks out of accept() & creates new thread w/
returnedport number to service requests for client (The Mainline
Thread/Client Thread connection is still on 8893)
3. client creates thread/port to service async events, sits in
accept() & informs server's new client thread of this new port
number (Client creates a port for the NV Event Thread/OVw Thread
connection and listens on it. It sends this port number to the
server via the Mainline Thread/Client Thread connection.)
4. server connects to this clients async port (The server then
connects to this port, and thus establishes the NV Event
Thread/OVw Thread connection.)
5. client break out of accept() and starts listening for new async
events (NV Event Thread/OVw Thread connection is established
and functional.)
So although the web client connects on port 8893, it will eventually
drop port 8893 and listen on a randomly created port x Currently port x
can't be restircted in netview, and netview is working as designed.
If possible, the customer should configure their firewall to allow these
connections to be made for the web client to work. Otherwise they can
raise an enhancement request through their csam.
I thing, this isn't a solution for our customer.
Now the question: Who knows a way to get the NVWC through the
firewall or to force NetView to use a certain port ?
Thanks for any help
Uwe
|