[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference varese::basestar_open

Title:BASEstar Open Multiplatform Application Framework
Notice:Kit pointers: see topic 3
Moderator:VARESE::CORBETTA
Created:Tue Oct 02 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:607
Total number of notes:1971

593.0. "Cannot lock com_srv_table-4.0 ?" by QUAKKS::BICKFORD () Wed Apr 23 1997 21:40

	Hi, 

	I'm trying to set up a somewhat unusual BASEstar configuration
	for a trade show and am having some trouble with the COM server.

	The configuration is an isolated LAN of two nodes, and one of the nodes 
	makes a dial-up PPP connection to Digital's network with NT 
	Remote Access Service.
	
	hostname: bollux		hostname: jceebe
	16.33.32.2			16.33.32.28                NT  
	Windows NT 3.51			Windows NT 4.0       <---> RAS connect
	BASEstar Client T3.1  <--->	BASEstar Server T3.1       to Digital's 
								   network 	


	I start up the BASEstar Server and Client and they communicate 
	with no problems. I then make the dial-up network connection to 
	Digital with NT RAS. The connection is made fine and 16.33.32.28
	is now visible on Digital's network. 

	Communications between the BASEstar client and server continue to 
	work fine. 

	If I then hang up or lose the RAS connection, the BASEstar server
	continues to function normally, BUT the the B* client 
	can longer reach the B* server -even though it worked fine before 
	the RAS connection was made.  								   

	A Connectivity Check from the BASEstar Open Manager - Client reports...
	

Cannot get LNS object com_srv_table-4.0 (ns BSTR; realm PDAS; class com_srv)from
LNS server 16.33.32.28(6101); error E-BSTR_S_TIMEOUT: Timeout expired(112693338)

Connection not established; error E-BSTR_S_COM_PC_CANNOT_CONNECT: Process cannot
connect to Communication Server(112696066)

				
	I've also noticed that as soon as the RAS connection is dropped, the 
	realm log on the BASEstar Server reports...


0000182	97/04/23 13:46:45  0xbc@jceebe COM_SERVER  :  I-BSTR_S_COM_SYSFAIL:
System call failed: send(LNS Host Manager) - errno: 0
0000183 97/04/23 13:46:45  0xbc@jceebe COM_SERVER  : th 78; Cannot lock lns obj
com_srv_table-4.0, class com_srv; error 112695746 	 	

	Any ideas? Should it be possible to do this?

	Thanks,
		Carlton
T.RTitleUserPersonal
Name
DateLines
593.1Does RAS remap the hostname ?VARESE::ZOCCOLADeprimitElatosLevatAlexandriaStratosThu Apr 24 1997 13:1819

What we suppose is that RAS has the nice "feature" of manipulating the IP
addresses of the host to map its own IP address to the hostname.

When the RAS connection goes up, it forces the mapping of the hostname to its
IP address (static or DHCP-obtained); when the RAS goes down, the hostname is
re-mapped to the original IP address (the one you configured via
Control Panel -> Network).

Clearly, during these IP addresses swapping, B* goes lost.

We will continue our investigation.

If someone can spread some knowledge about RAS behaviour, he/she is welcome.



		< Aldo >
593.2More on the RAS issue.QUAKKS::BICKFORDThu Apr 24 1997 22:5326
    
    Yes, RAS does seem to manipulate the mapping of adresses. You can 
    see this by doing a Tools -> LNS Server/s check... from the BASEstar
    Open Server Manager.
    
    Before a RAS connection, the LNS reply comes from one address, and
    after the RAS connection is made, the LNS reply comes from a different
    address!
    
    That is why I decided to use only one address on the B* server node.
    This is the scenario I described in 593.0   The B* server node has only
    one IP address; the one configured in Control Panel -> Network is the
    same as the requested (statically assigned) address for the RAS
    connection.
    
    So I'm not really using the RAS connection as an IP router. It's just a 
    simplistic scheme that I thought should be sufficient for the demo, but
    apparently not.
    
    Anyway, the worst case is that we lose the RAS connection at the show,
    and simply have to re-dial and then stop and restart the B* client
    apps. It will be nice to know what's really going on here, but it is
    not urgent. Thanks for the help
    
    	Carlton