Closed firebird-automations closed 7 years ago
Commented by: Alice F. Bird (firebirds)
Date: 2003-06-28 17:25 Sender: omarrosa Logged In: YES user_id=531816
In IB 6.01 this occur: When an event is registered, the client open a new connection in a port number defined by self. If the server can??t connect with this port ( firewall dropping ) it??s hung.
Commented by: Alice F. Bird (firebirds)
Date: 2002-09-12 16:02 Sender: nobody Logged In: NO
I have the next configuration: 2 ethernets(only one up) Linux Red Hat 7.3, runnig: samba firebird
when i try from of a win98(delphi5, IBX, gds32.dll(of firebird for windows)), the server an the clients crash, the message of exception is: " Unable complete netwotk request to host "192.168.1.2". Failed to estabilish a secondary connection for event processig. uknown Win32 error 10061....."
Please,how fix this.
Commented by: Alice F. Bird (firebirds)
Date: 2002-01-14 19:02 Sender: nobody Logged In: NO
The identical situation can be reproduced if server has 2 NIC's. If Primary NIC is used for Internet and all local requests come from LAN (Secondary NIC)- Server will crash as soon as client will try to register event. Resolusion - in Bindings Page make LAN NIC primary.
Saulius
Commented by: Alice F. Bird (firebirds)
Date: 2001-08-31 11:32 Sender: prenosil Logged In: YES user_id=89535
Reproducing this bug is easy. Just connect through firewall that has disabled all ports but 3050.
Commented by: Alice F. Bird (firebirds)
Date: 2001-08-30 22:23 Sender: nobody Logged In: NO
Was having the same exact problem on a computer with different configuration (Win2K Pro).
Commented by: Alice F. Bird (firebirds)
Date: 2000-12-06 02:46 Sender: robocop This seems related to bug 117514 gds32.dll raises intermittent exceptions because the user couldn't isolate the problem, but the same application would run fine or bad, depending on network settings.
C.
Submitted by: hipgnosis (hipgnosis)
SFID: 213460# Submitted By: hipgnosis
Overview
With a certain server network configuration, registering an event will lock up the client and lockup the server (requiring a reboot if it runs as a service, or a process kill if it runs as an application (the guardian does not detect it's lockup)) *if* the client is accessing the server through the internet (if it comes through the local lan, then it's fine).
System Discovered On
Dell Precision 610 dual 550 Xeon III's w/512 megs of memory. Windows NT 4 Workstation Service Pack 6 Interbase 6 (normal release) 3Com Fast EtherLink XL 10/100Mb TX Ethernet NIC (3C905B-TX) No firewalls, or other devices that might interfere with network traffic (for purposes of this test). All IP's are manually assigned (no DNS or DHCP server), and TCP/IP is the only network protocol installed on this system.
Configuration Description To Cause Bug
The above system has only one nic card in it. This card was assigned two IP's, the first being a 192.168.0.x (local network), and the second being it's internet address. A gateway for the NIC card was also set, in addition to IP Forwarding (which was removed later).
This configuration, while not considered the best, is perfectly legal, and works effectively with all the different servers run on it (MS SQL Server, ftp and web servers, etc.), both accessed from the internet and the local intranet.
It is only when a client attempts to register events when connected through the internet to the server system that the lockups occur. Otherwise, if the system is on the intranet, the access runs fine.
Fix
By setting the internet IP first, then having the intranet ip set in the advanced screen (under the internet IP), the problem is resolved (a reboot will be required after changing the configuration).
Comments
This was a strange bug to hunt down, and stems from the fact that the register events connection to the server through the internet is somehow 'different' enough to cause the crashes (the client will come back to life if the server is shutdown (in NT the server process has to be manually terminated).
While the problem requires a certain network configuration to occur (which tends to be common for small internal networks with a dsl or cablemodem connection to the internet), but given the anticipated spreading of InterBase with new applications, it becomes possible that some of our customers may receive this frustrating error. This is made even more dangerous by the fact that their network configurations may have been set by a third party consultant, or department IT person.
At the minimum, I would recommend that the IB server at have an exception written into it to handle this type of error gracefully, and return an exception to the connecting client indicating the network incompatibility.