Wrong service name to port address resolution in database connectiong string [CORE3819]

[firebird-automations]

Submitted by: Vasily Ovchinnikov (ova)

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.

Commits: f432739 f4c4f79

[firebird-automations]

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

[firebird-automations]

Commented by: @hvlad

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.

[firebird-automations]

Modified by: @hvlad

priority: Major [ 3 ] => Minor [ 4 ]

Version: 2.0.7 [ 10390 ]

Version: 2.5.1 [ 10333 ]

Version: 2.1.4 [ 10361 ]

Version: 2.5.0 [ 10221 ]

Version: 2.0.6 [ 10303 ]

Version: 3.0 Initial [ 10301 ]

Version: 2.1.3 [ 10302 ]

Version: 2.1.2 [ 10270 ]

Version: 2.0.5 [ 10222 ]

Version: 2.1.1 [ 10223 ]

Version: 2.1.0 [ 10041 ]

security: Developers [ 10012 ] =>

[firebird-automations]

Commented by: @hvlad

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.

[firebird-automations]

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5.2 [ 10450 ]

Fix Version: 3.0 Alpha 1 [ 10331 ]

[firebird-automations]

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

[firebird-automations]

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: No test

[firebird-automations]

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: No test => Cannot be tested