You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This error occerrence depends on the 'services' file content on the client side computer.
For example in case of Windows 7 operating system there is unable to connect to database via local port 25602 (e.g. localhost/25602:myalias) because of string
hmmp-ind 612/tcp #HMMP Indication
in 'services' file.
25602 = 6402h
612 = 0264h
Commenting out or deleting of the 612/tcp service resolves this problem. It useful in case of single static database connection.
But if the Firebird SQL traffic to the multiple Firebird SQL servers is packed and crypted using zebedee (or with other tunneling tools) with different and unique local port numbers this error can raise up more and more often.
The more unique local port numbers used on the client side the more chanses to get unestablished database connection because of this inconsistency of service name-port number resolution.
The reason is the not obvious (and not documented) behavior of getservbyname() routine in WIndows.
When "name" parameter represents a number, getservbyname() sometime returns NULL and sometime returns not-NULL.
In the later case service entry, returned by getservbyname(), represents service with port number equal to the input
parameter. But servent::s_port field is in network byte order, which is different than that is used in i86 architecture.
For example, 3050 = 0x0BEA. Let etc\services file contains valid record for port gds_db (3050).
One can connect to the Firebird using port 59915 (it is 0xEA0B), but there is no Firebird listener on port 59915 !
On Linux getservbyname() returns NULL for the all names '1' .. '65535', unless there is record in etc/services with
numeric service name.