[#CORE-3819] Wrong service name to port address resolution in database connectiong string

Firebird Core

Wrong service name to port address resolution in database connectiong string

Created: 16/Apr/12 07:12 AM Updated: 23/Apr/13 01:49 PM

Component/s:

API / Client Library

Affects Version/s:

2.1.0, 2.1.1, 2.0.5, 2.1.2, 2.1.3, 3.0 Initial, 2.0.6, 2.5.0, 2.1.4, 2.5.1, 2.0.7

Fix Version/s:

2.5.2, 3.0 Alpha 1

Time Tracking:

Not Specified

Environment:

Windows 7 with the default "\windows\system32\drivers\etc\services" file content

Planning Status:

Unspecified

Description

« Hide

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

Somethihg wrong.
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.

All

Comments

Work Log

Change History

Version Control

Subversion Commits

Sort Order:

[ Permalink | « Hide ]

Vlad Khorsun added a comment - 16/Apr/12 01:10 PM

It is sooner of all Windows-only bug and it is here for a very long time.
It is very hard to meet it in practice so i lower its priority.

[ Permalink | « Hide ]

Vlad Khorsun added a comment - 16/Apr/12 01:30 PM

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.