Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
firebird-automations opened this issue Apr 16, 2012 · 8 comments

Comments

@firebird-automations
Copy link
Collaborator

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
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

QA Status: No test => Cannot be tested

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment