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

Add Firebird Event fails with error "While isc_que_events - Failed to establish a secondary connection for event processing." [CORE5902] #6160

Closed
firebird-issue-importer opened this issue Aug 24, 2018 · 26 comments

Comments

@firebird-issue-importer

Submitted by: Marcio Reis (mreis1)

Is duplicated by CORE5967

Attachments:
2019-11-14_09-35-04.png

I think this problem is related to an old issue reported in here: CORE5498
In my tests I tried:

- client app running in mac os (where FB 3.0.3 is installed) establish a connection to remote DBMS (KO - fails with the above error)
- client app running in windows (where FB 3.0.3 is installed) os establish a connection to remote DBMS (OK)
- client app running in windows connects to a DBMS running locally. (OK)
- client app running in mac os connects to a DBMS running locally (OK)

Same was happening in Firebird 3.0.2.

What do you think?

Commits: 21cdc0a c8a8ad6 e5bbfad 5af5f6a

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Aug 25, 2018

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Aug 27, 2018

Commented by: @hvlad

Should be fixed now

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Aug 27, 2018

Commented by: Marcio Reis (mreis1)

Awesome. Thank you Vlad.
I'll need to wait for version 3.0.4 to try it, right?

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Aug 27, 2018

Commented by: @hvlad

Unfortunately, we have no snapshot builds for MacOS, so you have to wait for the next official release of 3.0.4
for MacOS (it could be RC or final release), or to build it yourself, sorry

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 20, 2018

Modified by: @hvlad

Link: This issue is duplicated by CORE5967 [ CORE5967 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 20, 2018

Commented by: @hvlad

Could you test with both client and server version 3.0.4 ?

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 22, 2018

Commented by: Marcio Reis (mreis1)

Server (Windows 10) has firebird 3.0.4 installed.
The same applies to my client (Mac OS 10.13.6) .

If there are any additional tests I can perform to help detecting the cause of this issue, please let me know.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 22, 2018

Commented by: @hvlad

Any messages in firebird.log ? Check at both sides - client and server.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 28, 2018

Commented by: Marcio Reis (mreis1)

Just checked both, server and clients logs and there's nothing on them.
But I get the error when the app runs:

"While isc_que_events - Unable to complete network request to host "192.168.0.195".
Failed to establish a secondary connection for event processing.
Can't assign requested address"

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 28, 2018

Modified by: Marcio Reis (mreis1)

Version: 3.0.4 [ 10863 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 29, 2018

Commented by: Sean Leyne (seanleyne)

Marcio,

The error suggests that your latest problem could be MacOS internal firewall settings? (Event processing uses a different TCP port from the database connection)

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 30, 2018

Commented by: Marcio Reis (mreis1)

Both server and client are running with no firewalls on. Same for antivirus.
UAC and other restrictions are also disabled.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Mar 26, 2019

Commented by: Marcio Reis (mreis1)

Hello guys, is there any news on in issue?
Developing on mac is a pain since I can't attach db events. :(

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Mar 28, 2019

Commented by: @hvlad

I'm afraid i can do nothing - i have no Mac to build and debug Firebird and you can't build Firebird (on Mac) by yourself to try some tracing...

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 6, 2019

Commented by: @asfernandes

Accordingly to https://gist.github.com/cyberroadie/3490843, MacOS definition for sockaddr is:
struct sockaddr {
__uint8_t sa_len; /* total length */
sa_family_t sa_family; /* [XSI] address family */
char sa_data[14]; /* [XSI] addr value (actually larger) */
};

And in Linux https://github.com/torvalds/linux/blob/master/include/linux/socket.h and probably the same in Windows as they work with each other:
struct sockaddr {
sa_family_t sa_family; /* address family, AF_xxx */
char sa_data[14]; /* 14 bytes of protocol address */
};

Of course this cause errors when MacOS client/server is different than server/client and we use sa_data struct to transfer the address from server to client.
union sa_data {
struct sockaddr sock;
struct sockaddr_in inet;
struct sockaddr_in6 inet6;
} data;

I believe the server should send to client only the port number and the client should use the same original address information (more the port) to reconnect to server. Opinions?

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 6, 2019

Commented by: @hvlad

Server send full address (family, port and IP address) to the client so the client behind the NAT could know real IP of server endpoint.

Probably, client should analyze length of server response to distinguish MacOS from Windows\Linux ?

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 6, 2019

Commented by: @asfernandes

> Server send full address (family, port and IP address) to the client so the client behind the NAT could know real IP of server endpoint.

IMO this causes more issues than benefits. If server is behind NAT, it probably can't listen directly to client.

To locate the server the client should use the same host/address originally used for the main connection, and of course the NAT should redirect to the same machine.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 6, 2019

Commented by: @hvlad

Hmm, it seems it is even worse:

MacOS:

#⁠ifndef _SA_FAMILY_T
#⁠define _SA_FAMILY_T
typedef __uint8_t sa_family_t;
#⁠endif

...
struct sockaddr {
__uint8_t sa_len; /* total length */
sa_family_t sa_family; /* [XSI] address family */
char sa_data[14]; /* [XSI] addr value (actually larger) */
};

Windows:

typedef USHORT ADDRESS_FAMILY;

typedef struct sockaddr {

#⁠if (_WIN32_WINNT < 0x0600)
u_short sa_family;
#⁠else
ADDRESS_FAMILY sa_family; // Address family.
#⁠endif //(_WIN32_WINNT < 0x0600)

CHAR sa\_data\[14\];                   // Up to 14 bytes of direct address\.

} SOCKADDR, *PSOCKADDR, FAR *LPSOCKADDR;

I.e. sizeof(sockaddr) will be equal on MacOS and Windows, but MacOS keep family value at second byte, while Windows - at first one

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 6, 2019

Commented by: @hvlad

> If server is behind NAT, it probably can't listen directly to client.
Server alread accept database attachment from client, so - it can listen ;)

> To locate the server the client should use the same host/address originally used for the main connection, and of course the NAT should redirect to the same machine.
Probably it will work, I just try to remember why things works this way for a many years already.
Probably there is another reason.

If send port only - how do you offer to preserve compatibility of old (new) client with new (old) server ?

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 6, 2019

Commented by: @asfernandes

For compatibility, we should anyway decode sockaddr knowing it could be from a different OS.

> Server alread accept database attachment from client, so - it can listen ;)

No, in case of NAT, it will be redirected from the public IP to the private one. The private one could not listen directly.

It's the same as used in web. Client (browser) should only use the public host while in most cases there is a load balancer redirecting to internal IPs.

The difference for Firebird is that there is not a load balancer redirecting to multiple IPs, but possibily to a single one.

I don't see any reason to try to use the address sent by the server.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 6, 2019

Commented by: @hvlad

You right, client uses only port from server response (see aux_connect()).
But i still not see how do you going to preserve compatibility.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 7, 2019

Commented by: @asfernandes

> But i still not see how do you going to preserve compatibility.

I'm preparing a pull request for review.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 13, 2019

Commented by: @asfernandes

Márcio, please test this using the next Windows snapshot in the server. No need to update MacOS client.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 13, 2019

Modified by: @asfernandes

assignee: Vlad Khorsun [ hvlad ] => Adriano dos Santos Fernandes [ asfernandes ]

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

resolution: Fixed [ 1 ]

Fix Version: 3.0.5 [ 10885 ]

Fix Version: 4.0 Beta 2 [ 10888 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 14, 2019

Commented by: Marcio Reis (mreis1)

Adriano, I can confirm... latest windows snapshot fixes this issue! I'm so happy for this. Thank you :)

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 14, 2019

Modified by: Marcio Reis (mreis1)

Attachment: 2019-11-14_09-35-04.png [ 13401 ]

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

No branches or pull requests

2 participants